Robert Elz <k...@munnari.oz.au> wrote:

>     Date:        Mon, 3 Jul 2017 11:45:30 +0200
>     From:        Joerg Schilling <joerg.schill...@fokus.fraunhofer.de>
>     Message-ID:  
> <595a123a.dp23fbcbtystwzcf%joerg.schill...@fokus.fraunhofer.de>
>
>
>   | This is not a bug, but a design decision.
>
> One man's design decision is another man's bug ...
>
>   | Since nothing was wrong with the decision to do IO redirection in the
>   | forked child that soon will call the command, "may be reversed" cannot
>   | be seen as a mistake.
>
> When there is going to be a forked child (and given that the discussion
> here is primarily on the simple command case) then the order is specified
> and no reversal happens (or should).
>
> From one perspective the "may be" makes sense (ie: is correct) as that is
> what applications will experience in the wild - exactly as Martijn showed.
>
> But like all situations where what happens isn't specified, it makes it
> harder for applications do do anything at all, so from another perspective
> it is a pity that the bug (or design decision) was there in the first
> place.

I believe that we could call a behavior from the Bourne Shell buggy if the 
expected behavior deviates from the observed behavior and in case there is no 
way to work around the problem.

In our case, it is doubtful whether something like:

        var=value

allows IO redirection at all, as there is no command. Note that we recently
discovered that var=$(cmd) does not set $? because there is no regular command.

        { var=value; }

converts the pure assignement into something tha can be seen as a construct that
forms a command and thus allows redirection.

It may be a good idea to add a related hint to the POSIX text that people 
understand that there are ways to enforce thr order of evaluation in a way that
allows to redirect a commend hidden in "value".

Jörg

-- 
 EMail:jo...@schily.net                    (home) Jörg Schilling D-13353 Berlin
    joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Reply via email to