Re: Fwd: Default time for unmarked history lines

2016-01-19 Thread Reuben Thomas
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

Re: combine and ..

2016-01-19 Thread John McKown
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

Re: read Built-in Parameter Behavior -- Null Byte Delimiter

2016-01-19 Thread Adam Danischewski
> > 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

Re: read Built-in Parameter Behavior -- Null Byte Delimiter

2016-01-19 Thread Greg Wooledge
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

Re: read Built-in Parameter Behavior -- Null Byte Delimiter

2016-01-19 Thread Adam Danischewski
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

Re: read Built-in Parameter Behavior -- Null Byte Delimiter

2016-01-19 Thread Greg Wooledge
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