On Tue, Jan 19, 2016 at 12:09:54PM -0500, Adam Danischewski wrote:
> In the case for read -d'' very probably the user has attempted to supply
> the null delimiter, but read quietly takes the next argument. I think it
> makes sense to bump empty strings away from the option when they occur
> after o
Right, the programs don't see those empty strings because the shell is
stripping them when it parses the line. But for options, for the shell
parser to strip away the empty string presumes that the user made a mistake
and has needlessly/erroneously provided a useless empty string.
In the case for
On Tue, Jan 19, 2016 at 11:39:07AM -0500, Adam Danischewski wrote:
> Bash also removes the single quotes before it hits read when the single
> quotes are attached to the delimiter option (-d'').
And in EVERY OTHER COMMAND. This is how quotes work. This is utterly
fundamental to bash and the enti
> > Other shells must go out of their way to suppress it, then.
>
> Most of the other shells remove NUL bytes from `read's input. They
> probably do this before checking the delimiter.
Bash also removes the single quotes before it hits read when the single
quotes are attached to the delimiter op
If you want a "pure BASH" solution, I don't have one off hand. Stuff like
what you mentioned, I generally use a data base for. In this particular,
I'd use SQLite. A shell script using sqlite3 & awk would look something
like:
#!/bin/sh
rm files.db3
{
cat < 1 {print "INSERT INTO file1 VALUES(\"" $1
On 18 January 2016 at 22:21, Chet Ramey wrote:
> On 1/18/16 11:53 AM, Reuben Thomas wrote:
>
> > So, how about instead interpreting a missing/0 date as a NaD (Not A
> Date),
> > rather as readline does anyway with time 0, and providing a slightly more
> > meaningful message than the current "??".
