bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: bug#12580: yes ignores POSIXLY_CORRECT and cannot be stopped (coreutils 8.15)
Date: Fri, 05 Oct 2012 10:32:56 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]