Defect in manual section "Here Strings"

[dietmar.schindler]

In the section https://www.gnu.org/software/bash/manual/bash.html#Here-Strings 
there is no mention (as far as I can see, it doesn't follow from the documented 
expansions etc.) that the result is terminated with a newline (see e. g. od 
<<<''). This puzzles users and leads to speculation - see e. g. 
http://stackoverflow.com/questions/33245568/why-does-bash-always-add-a-newline-when-expanding-here-strings
 - on correctness, dependability and intent of the behavior. To clarify it, I 
suggest to change the last sentence from

The result is supplied as a single string to the command on its 
standard input.

to

The result with a newline appended is supplied as a single string to 
the command on its standard input.
--
Best regards,
Dietmar Schindler


manroland web systems GmbH -- Managing Director: Joern Gosse
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- 
VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient, you are hereby notified that any use or 
dissemination of this communication is strictly prohibited. If you have 
received this eMail in error, then please delete this eMail.

! Please consider your environmental responsibility before printing this eMail !

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Andreas Schwab]

Keith Thompson  writes:

> On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab 
> wrote:
>
>> Chet Ramey  writes:
>>
>> > I can make bash blow away the original signal dispositions and pretend
>> they
>> > were SIG_DFL when an interactive shell starts, if there is no
>> alternative.
>>
>> Given that login(1) has the same behaviour there is probably no
>> alternative.
>>
>> Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and
> Ctrl-Z works correctly.
> I verified that the shell's parent process was "login".
> Perhaps (at least the Debian version of) login(1) *doesn't* do that.

FreeBSD's login does it too.



Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Defect in manual section "Here Strings"

[Greg Wooledge]

On Wed, Nov 11, 2015 at 08:00:28AM +, dietmar.schind...@manroland-web.com 
wrote:
> The result with a newline appended is supplied as a single string to 
> the command on its standard input.

That wording is a bit clumsy.  I would suggest:

The result is suppled as a single string, with a newline appended,
to the command on its standard input.

Re: Defect in manual section "Here Strings"

[Chet Ramey]

On 11/11/15 3:00 AM, dietmar.schind...@manroland-web.com wrote:
> In the section 
> https://www.gnu.org/software/bash/manual/bash.html#Here-Strings there is no 
> mention (as far as I can see, it doesn't follow from the documented 
> expansions etc.) that the result is terminated with a newline (see e. g. od 
> <<<''). This puzzles users and leads to speculation - see e. g. 
> http://stackoverflow.com/questions/33245568/why-does-bash-always-add-a-newline-when-expanding-here-strings
>  - on correctness, dependability and intent of the behavior.

I'll add something to that effect.
-- 
``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/

AW: Defect in manual section "Here Strings"

[dietmar.schindler]

> Von: Greg Wooledge [mailto:wool...@eeg.ccf.org]
> Gesendet: Mittwoch, 11. November 2015 14:11
>
> ...
>
> That wording is a bit clumsy.  I would suggest:
>
>   The result is suppled as a single string, with a newline appended,
>   to the command on its standard input.

I have no objection to that, apart from supplying "suppled" with an "i" at the 
appropriate place. ;-)
--
Regards,
Dietmar Schindler

manroland web systems GmbH -- Managing Director: Joern Gosse
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- 
VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient, you are hereby notified that any use or 
dissemination of this communication is strictly prohibited. If you have 
received this eMail in error, then please delete this eMail.

! Please consider your environmental responsibility before printing this eMail !

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Chet Ramey]

On 11/10/15 10:03 PM, Keith Thompson wrote:
> On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson  > wrote:
> 
> On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab  > wrote:
> 
> Chet Ramey mailto:chet.ra...@case.edu>> writes:
> 
> > I can make bash blow away the original signal dispositions and 
> pretend they
> > were SIG_DFL when an interactive shell starts, if there is no 
> alternative.
> 
> Given that login(1) has the same behaviour there is probably no
> alternative.
> 
> Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and
> Ctrl-Z works correctly.
> I verified that the shell's parent process was "login".
> Perhaps (at least the Debian version of) login(1) *doesn't* do that.
> 
> I'm going to hold off on contacting the rxvt and urxvt developers
> for now.  If you decide to modify bash to blow away the original signal
> dispositions, there's no point in reporting this as a bug in rxvt.
> 
> Does that make sense?

Yeah, that's fine.  I will modify bash to set the original signal
dispositions to SIG_DFL in interactive shells.

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: Bug in bash 4.4-beta: suspending and restarting "man" program

[Keith Thompson]

On Wed, Nov 11, 2015 at 11:55 AM, Chet Ramey  wrote:

> On 11/10/15 10:03 PM, Keith Thompson wrote:
> > On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson <
> keithsthomp...@gmail.com
> > > wrote:
> >
> > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab <
> sch...@linux-m68k.org
> > > wrote:
> >
> > Chet Ramey mailto:chet.ra...@case.edu>>
> writes:
> >
> > > I can make bash blow away the original signal dispositions and
> pretend they
> > > were SIG_DFL when an interactive shell starts, if there is no
> alternative.
> >
> > Given that login(1) has the same behaviour there is probably no
> > alternative.
> >
> > Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and
> > Ctrl-Z works correctly.
> > I verified that the shell's parent process was "login".
> > Perhaps (at least the Debian version of) login(1) *doesn't* do that.
> >
> > I'm going to hold off on contacting the rxvt and urxvt developers
> > for now.  If you decide to modify bash to blow away the original signal
> > dispositions, there's no point in reporting this as a bug in rxvt.
> >
> > Does that make sense?
>
> Yeah, that's fine.  I will modify bash to set the original signal
> dispositions to SIG_DFL in interactive shells.
>

Does that mean reverting default_tty_job_signals() in jobs.h to the
version in bash 4.3.30:

  set_signal_handler (SIGTSTP, SIG_DFL);
  set_signal_handler (SIGTTIN, SIG_DFL);
  set_signal_handler (SIGTTOU, SIG_DFL);

or is there more to it than that?  (I'd like to try out the change myself.)

-- 
Keith Thompson 

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Keith Thompson]

On Wed, Nov 11, 2015 at 3:16 PM, Keith Thompson 
wrote:

> On Wed, Nov 11, 2015 at 11:55 AM, Chet Ramey  wrote:
>
>> On 11/10/15 10:03 PM, Keith Thompson wrote:
>> > On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson <
>> keithsthomp...@gmail.com
>> > > wrote:
>> >
>> > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab <
>> sch...@linux-m68k.org
>> > > wrote:
>> >
>> > Chet Ramey mailto:chet.ra...@case.edu>>
>> writes:
>> >
>> > > I can make bash blow away the original signal dispositions
>> and pretend they
>> > > were SIG_DFL when an interactive shell starts, if there is no
>> alternative.
>> >
>> > Given that login(1) has the same behaviour there is probably no
>> > alternative.
>> >
>> > Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1),
>> and
>> > Ctrl-Z works correctly.
>> > I verified that the shell's parent process was "login".
>> > Perhaps (at least the Debian version of) login(1) *doesn't* do that.
>> >
>> > I'm going to hold off on contacting the rxvt and urxvt developers
>> > for now.  If you decide to modify bash to blow away the original signal
>> > dispositions, there's no point in reporting this as a bug in rxvt.
>> >
>> > Does that make sense?
>>
>> Yeah, that's fine.  I will modify bash to set the original signal
>> dispositions to SIG_DFL in interactive shells.
>>
>
> Does that mean reverting default_tty_job_signals() in jobs.h to the
> version in bash 4.3.30:
>
>   set_signal_handler (SIGTSTP, SIG_DFL);
>   set_signal_handler (SIGTTIN, SIG_DFL);
>   set_signal_handler (SIGTTOU, SIG_DFL);
>
> or is there more to it than that?  (I'd like to try out the change myself.)
>
>
To answer my own question, I changed default_tty_job_signals()
as described in jobs.c and nojobs.c, and commented out
default_tty_job_signals() and all calls to it. It seems to work
(Ctrl-Z works when I run the shell under rxvt).

-- 
Keith Thompson