Here strings appends a newline

[Håkon Hallingstad]

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
proposal.

I tried to make -C doc, but even on a clean clone it produces a diff.
Therefore, it may be best if you guys apply the below patch and run make.

Håkon Hallingstad


diff --git a/doc/bash.1 b/doc/bash.1
index ec41462..5d9bf30 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -3801,8 +3801,8 @@ The \fIword\fP undergoes
brace expansion, tilde expansion, parameter and variable expansion,
command substitution, arithmetic expansion, and quote removal.
Pathname expansion and word splitting are not performed.
-The result is supplied as a single string to the command on its
-standard input.
+The result is supplied as a single string, with a newline appended,
+to the command on its standard input.
.SS "Duplicating File Descriptors"
.PP
The redirection operator

Re: Here strings appends a newline

[Chet Ramey]

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 propose to clarify this in the man page, see below for
> proposal.

Thanks for the report.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: history EINTR bug

[gregrwm]

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
>
> What command did you use?

history|&less

on seeing less than the full history, with that error instead, it got me to
thinking it's quite likely something quite similar sometimes happens to
cause failure to write out all the history at shutdown, followed by further
attempts to write the history again.

> Writing the history to stdout is different
> from writing to a pipe, which is different from using history -a or
> history -w to write to a file.
>
> It's difficult to say more without knowing which signal interrupted
> the command.

Re: Here strings appends a newline

[Stephane Chazelas]

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.

-- 
Stephane

Re: history EINTR bug

[Chet Ramey]

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.
>>
>> > this just happened:
>> > bash: history: write error: Interrupted system call
>>
>> What command did you use?
> 
> history|&less

The most likely possibility is that you quit out of less before `history'
wrote enough data to cause stdio to flush its output buffer and the SIGPIPE
interrupted the write(2) when it did.  I'm not sure why write would return
-1/EINTR instead of -1/EPIPE, but behavior is not consistent across
platforms.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: history EINTR bug

[gregrwm]

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.
> >>
> >> Maybe.  There's not enough information here to say.
> >>
> >> > this just happened:
> >> > bash: history: write error: Interrupted system call
> >>
> >> What command did you use?
> >
> > history|&less
>
> The most likely possibility is that you quit out of less before `history'
> wrote enough data to cause stdio to flush its output buffer and the
SIGPIPE
> interrupted the write(2) when it did.  I'm not sure why write would return
> -1/EINTR instead of -1/EPIPE, but behavior is not consistent across
> platforms.

since i'd never seen that error before, i left that less process up for
days, musing over it until i had a moment to write you.

i'm thinking that when the system is rather busy, such for example as when
numerous processes are all told to shutdown at once, EINTR occurs, and, in
the case of the pipe, the history command never got the remainder of the
history, but, in the case of writing out to the history file at shutdown,
bash handles it by reattempting to write the history starting over again
from the beginning of the history.  that would explain the behavior
captured in the bug report in the OP of this thread.