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.
There's no rational advantage (to the script writer) in evaluating the
assignments before the redirects - the only time this can make a difference
is in something like
a=foo >$a
(regardless of what "foo" is) which can just be written as
a=foo; >$a
and there is no question about which comes first. But, other than
complicating things by adding extra syntax elements (like the command group
in Martijn's example) to make things work there is no truly simple alternative
to allow a redirect to apply to the assignment (when it makes a difference
which is only when there is a command substitution in the assignment).
So, redirect first is the way that offers most functionality (also consistency
with the case where there is a command) - implementing it differently (as a
"design choice") might make the implementation simpler, but it has no other
redeeming features. Hence a bug.
kre
