Subject: bug#12580: closed (Re: bug#12580: yes ignores POSIXLY_CORRECT and cannot be stopped (coreutils 8.15))

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 05 Oct 2012 16:34:03 +0000

Your bug report

#12580: yes ignores POSIXLY_CORRECT and cannot be stopped (coreutils 8.15)

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
12580: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12580
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#12580: yes ignores POSIXLY_CORRECT and cannot be stopped (coreutils 8.15)
From: Eric Blake <[email-masked]>
To: Marius Spix <[email-masked]>
Cc: [email-masked]
Date: Fri, 05 Oct 2012 10:32:56 -0600
List-Id: <debbugs-submit.debbugs.gnu.org>

tag 12580 notabug
thanks

On 10/05/2012 09:47 AM, Marius Spix wrote:
> Hello (sorry for my bad English),
> 
> I am using coreutils 8.15 and have noted that `yes' ignores the
> environment variable `POSIXLY_CORRECT'.

Thanks for the report.  That's because POSIX does not specify 'yes'.
POSIXLY_CORRECT exists to cause applications specified by POSIX to
behave in the manner specified by POSIX, but since yes is not specified
by POSIX, there's nothing we need to change.

> 
> So the command `env POSIXLY_CORRECT yes --help' does print the help
> instead of printing `--help' until killed.

If you want to print "--help" until killed, use:

yes -- --help

POSIX mandates the use of '--' as a delimiter for end-of-options for any
POSIX application not explicitly specified otherwise[1], if you want to
treat a subsequent argument with leading dash as a non-option.
Coreutils has taken that POSIX mandate and applied it to all of its
apps, even those not specified by POSIX, for consistency of use.

[1]echo is one of those POSIX-specified apps that is an exception to the
rule, where 'echo --help' is explicitly specified otherwise to output
'--help' instead of treating it as an option.  Hence, in coreutils,
'echo' obeys POSIXLY_CORRECT.  But we're talking about 'yes', not 'echo'.

> In addition `yes' cannot be killed with CTRL+C (SIGINT) or CTRL+Z
> (SIGTSTP) if you call it with another program using the `&' operator of
> sh.

That's true for ANY backgrounded application under sh.  To kill a
background application, you must either use kill(1), (often a shell
builtin, so that you can type something like 'kill %1' instead of having
to do 'kill $(determine the pid of yes)'), or else use 'fg' to bring it
into the foreground at which point you can once again send it keyboard
input including 'ctrl-c' to cause sigint.

> This causes that `yes & <insert_random_program_name_here>' can only
> be stopped with CTRL+D which causes a logoff. `yes & yes'
> however can only stopped if killed from another terminal ...
> 
> Is this wanted or are these bugs?

There are no bugs in what you have reported, just a misunderstanding of
what POSIX specified and how shell backgrounding works.  As such, I'm
closing this bug report, but feel free to continue to reply on this
thread if you have more concerns.

-- 
Eric Blake   [email-masked]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Subject: yes ignores POSIXLY_CORRECT and cannot be stopped (coreutils 8.15)
From: Marius Spix <[email-masked]>
To: [email-masked]
Date: Fri, 5 Oct 2012 17:47:35 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello (sorry for my bad English),

I am using coreutils 8.15 and have noted that `yes' ignores the
environment variable `POSIXLY_CORRECT'.

So the command `env POSIXLY_CORRECT yes --help' does print the help
instead of printing `--help' until killed.

In addition `yes' cannot be killed with CTRL+C (SIGINT) or CTRL+Z
(SIGTSTP) if you call it with another program using the `&' operator of
sh. This causes that `yes & <insert_random_program_name_here>' can only
be stopped with CTRL+D which causes a logoff. `yes & yes'
however can only stopped if killed from another terminal ...

Is this wanted or are these bugs?

Thank you for your acknowledgement.