Here strings appends a newline

I noticed that here strings (<<< word) doesn't quite follow the documented behavior: "The result is supplied as a single string to the command on its standard input." Instead, or in addition, a newline is appended to the string. I therefore propose to clarify this in the man page, see below for pro

Re: Here strings appends a newline

On 2/22/15 1:30 PM, Håkon Hallingstad wrote: > I noticed that here strings (<<< word) doesn't quite follow the documented > behavior: "The result is supplied as a single string to the command on its > standard input." Instead, or in addition, a newline is appended to the > string. I therefore propo

Re: history EINTR bug

On Feb 13, 2015 7:38 AM, "Chet Ramey" wrote: > On 2/12/15 9:06 AM, gregrwm wrote: > > i now suspect bash does not properly handle EINTR while handling history. > > Maybe. There's not enough information here to say. > > > this just happened: > > bash: history: write error: Interrupted system call

Re: Here strings appends a newline

For the record, I beleive the <<< feature was introduced by the Unix port of rc (the plan9 shell) that did *not* add the trailing newline. zsh is the shell that brought that construct to the Bourne world and it did add the extra newline character. All of zsh, ksh, bash, yash add that newline. --

Re: history EINTR bug

On 2/22/15 5:57 PM, gregrwm wrote: > On Feb 13, 2015 7:38 AM, "Chet Ramey" > wrote: >> On 2/12/15 9:06 AM, gregrwm wrote: >> > i now suspect bash does not properly handle EINTR while handling history. >> >> Maybe. There's not enough information here to say. >> >> > thi

Re: history EINTR bug

On Feb 22, 2015 7:57 PM, "Chet Ramey" wrote: > On 2/22/15 5:57 PM, gregrwm wrote: > > On Feb 13, 2015 7:38 AM, "Chet Ramey" > > wrote: > >> On 2/12/15 9:06 AM, gregrwm wrote: > >> > i now suspect bash does not properly handle EINTR while handling history. > >> > >> May