2017-05-23 23:38:40 +0000, Austin Group Bug Tracker:
[...]
> My guess (pure guess) would be that it was not specified to allow
> "command"
> but only "compound-command", as allowing "command" that way makes a
> redirect
> at the end of the line ambiguous - just what does that mean, ie: in
>
> f() g() h() echo hello >&2
>
> to what exactly is the redirect applied, just to when we run f, so
> g is defined with stdout redirected to stderr, but then h runs with
> the original stdout ?
[...]
[taking the discussion to the ML as it has little relevance to
issue 767]
Thanks, I think you nailed it.
I thought the Bourne function definition syntax was unambiguous
and it was just a matter of sticking functioname() in front of a
command (not pipeline).
h() echo hello >&2
would be unambiguous (functionally the same as h() { echo hello
>&2; }) just like
h() (echo hello) >&2
in POSIX is unambiguous and explicitely defined as being
functionally equivalent to h() { (echo hello) >&2; }
But when I test it now with the /bin/sh (Bourne) or /bin/ksh
(ksh88) of Solaris 10:
$ ksh -c 'err() printf "%s\n" "$1" >&2; err test'
ksh: syntax error at line 1 : `>' unexpected
$ /bin/sh -c 'err() printf "%s\n" "$1" >&2; err test'
/bin/sh: syntax error at line 1: `>' unexpected
(same with ksh93. ash, zsh and pdksh are OK (though zsh used to
have issues even with compound commands there).
While it works OK with compound commands.
So I suppose POSIX limited to compound commands so not to have
to specify the inconsistent behaviour of Bourne/ksh88
note that
define_err() err() { echo "$1" >&2; } > /dev/null
works OK (well, at least like I (and it seems you) expect) in
Bourne/AT&T ksh (but there's no point POSIX explicitely allowing
it as it's not useful). The problem seems to be only for
f() simple-command > redirections
--
Stephane
