GNU bug report logs - #12580
yes ignores POSIXLY_CORRECT and cannot be stopped (coreutils 8.15)

Previous Next

Full log

Message #7 received at control <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Marius Spix <marius.spix <at> web.de>
Cc: 12580-done <at> debbugs.gnu.org
Subject: Re: bug#12580: yes ignores POSIXLY_CORRECT and cannot be stopped
	(coreutils 8.15)
Date: Fri, 05 Oct 2012 10:32:56 -0600

[Message part 1 (text/plain, inline)]

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   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.