DASH Shell discussions
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Geoff Nixon <geoff@geoff.codes>, Harald van Dijk <harald@gigawatt.nl>
Cc: "dash@vger.kernel.org" <dash@vger.kernel.org>,
	"482999@bugs.debian.org" <482999@bugs.debian.org>
Subject: Re: The behavior of `jobs -p` is definitely, without a doubt, a bug
Date: Wed, 18 May 2016 19:51:23 -0600	[thread overview]
Message-ID: <573D1C1B.5020803@redhat.com> (raw)
In-Reply-To: <154c6533dbf.f33a196d271361.3835032381744891755@geoff.codes>

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

On 05/18/2016 06:03 PM, Geoff Nixon wrote:
> Again, speaking for myself, I think the standard is actually pretty clear here.
> Referring again to the "Shell Command Language" page:
> 
>     The format for grouping commands is as follows:
>     (compound-list)
>     Execute compound-list in a *subshell environment*...
> 
> That is, I believe the behavior of bash and busybox does not fully adhere to the
> the standard; pdksh, ksh93, mksh, yash, and oksh are compliant.
> 
>> Personally, I feel that even if your interpretation is wrong (and I'm 
>> not saying it is), it is still less undesirable than dash's current 
>> behaviour. If there's a reasonable chance a patch for it would be 
>> accepted, I'd be willing to try to make it so. 
> 
> Agreed. I'd very much like to see a patch for this; and I certainly hope it
> would be accepted!
> 
> At the *very, very least*, I think the fact that `jobs -p` can have stdout
> redirected to a file, yet cannot be used in a pipeline, is most definitely 
> bug. Can you think of any other command where stdout can be redirected to a file
> but cannot be piped?

http://austingroupbugs.net/view.php?id=53

The trap command is in the same boat as jobs, where redirecting to a
file is different than execution in a subshell, and where the shell may
special case (but perhaps by lexical analysis only) that if a subshell
is about to run where only the single command is being executed, then it
can behave as if that single command were in the context of the parent
instead of being a true subshell, precisely for the purpose of giving
output that would otherwise be lost.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

      reply	other threads:[~2016-05-19  1:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13  2:06 The behavior of `jobs -p` is definitely, without a doubt, a bug Geoff Nixon
2016-05-18 21:03 ` Harald van Dijk
2016-05-19  0:03   ` Geoff Nixon
2016-05-19  1:51     ` Eric Blake [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=573D1C1B.5020803@redhat.com \
    --to=eblake@redhat.com \
    --cc=482999@bugs.debian.org \
    --cc=dash@vger.kernel.org \
    --cc=geoff@geoff.codes \
    --cc=harald@gigawatt.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox