Re: redirections preceded by a word with builtins inconsistent
On 5/24/16 12:09 PM, Dan Douglas wrote: > On Tue, May 24, 2016 at 10:23 AM, Chet Rameywrote: >> It's not that Posix `allows' a subshell, it requires a subshell >> environment: > > Hm sorry I thought it was "may". This is kind of easy to confuse with > all the other unspecified things about side-effects from assignments > affecting subsequent assignments and commands when there's no command > name. Yeah. A subshell environment doesn't automatically mean a subshell, but it means that changes in the subshell environment don't affect the parent. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: redirections preceded by a word with builtins inconsistent
On Tue, May 24, 2016 at 10:23 AM, Chet Rameywrote: > It's not that Posix `allows' a subshell, it requires a subshell > environment: Hm sorry I thought it was "may". This is kind of easy to confuse with all the other unspecified things about side-effects from assignments affecting subsequent assignments and commands when there's no command name.
Re: redirections preceded by a word with builtins inconsistent
On 5/24/16 1:41 AM, Dan Douglas wrote: >> You don't precede it with an `exec', so it doesn't affect the current >> shell. So-called `null' commands with redirections are executed in >> subshells. This is where you need the `exec'. > > I know POSIX allows for a subshell but don't know what the point is. I > was confused by this when I first hit it. The subshell isn't obvious. It's not that Posix `allows' a subshell, it requires a subshell environment: "If there is no command name, any redirections shall be performed in a subshell environment." Bash produces a subshell environment by creating a subshell. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: redirections preceded by a word with builtins inconsistent
On Sun, May 22, 2016 at 1:06 PM, Chet Rameywrote: > On 5/21/16 5:16 PM, adonis papaderos wrote: > >> Bash Version: 4.3 >> Patch Level: 42 >> Release Status: release >> >> Description: >> When using redirections preceded by a word on builtins >> 'i.e. : {varname}<&1' >> the redirection persists to the current shell. > > This is by design, and has been discussed previously. One such discussion > starts at http://lists.gnu.org/archive/html/bug-bash/2016-01/msg00156.html. > Maybe it should only do it when preceded by `exec', but it never has. > >> Later using {varname}<&- does not close fd. > > You don't precede it with an `exec', so it doesn't affect the current > shell. So-called `null' commands with redirections are executed in > subshells. This is where you need the `exec'. I know POSIX allows for a subshell but don't know what the point is. I was confused by this when I first hit it. The subshell isn't obvious. $ bash -c 'echo "$BASHPID" {x[$((pid=BASHPID))$(echo "2: $pid" >&2),0]}<<<"$((pid=BASHPID))$(echo "1: $pid" >&2)"' 3907 1: 3908 2: 3908 $ bash -c 'echo "$BASHPID" {x[$((pid=BASHPID))$(echo "2: $pid" >&2),0]}<<<"$((pid=BASHPID))$(echo "1: $pid" >&2)"' 3911 1: 3911 2: 3911 ksh being the only other shell that supports auto-fd assignment for null commands doesn't create one. $ bash -c 'typeset -li y=2 {x[y*=2]}<&$((y*=2,0)); typeset -p x y' bash: line 1: typeset: x: not found declare -il y="2" $ bash -c 'typeset -li y=2 : {x[y*=2]}<&$((y*=2,0)); typeset -p x y' declare -a x='([8]="10")' declare -il y="8" $ ksh -c 'typeset -li y=2 {x[y*=2]}<&$((y*=2,0)); typeset -p x y' typeset -a -i x=([8]=11) typeset -l -i y=8 $ ksh -c 'typeset -li y=2 : {x[y*=2]}<&$((y*=2,0)); typeset -p x y' typeset -a -i x=([8]=11) typeset -l -i y=8 ksh and zsh are hard to test since they do a horrible job parsing the {fd} in all but trivial cases. It would be way simpler to only allow redirects at the end of a command and require each redirect to be a separate word. That eliminates a ton of ambiguities for {fd}>x, &>x and > Maybe add a `set -k` work-alike for legacy scripts and people that insist on `echo >&2 i like surprise redirec{t}
Re: redirections preceded by a word with builtins inconsistent
On Sun, May 22, 2016 at 09:48:47PM +0300, adonis papaderos wrote: > > > When using redirections preceded by a word on builtins > > > 'i.e. : {varname}<&1' > > > the redirection persists to the current shell. That surprises me, but if Chet says it's not a bug, then so be it. Simply stop doing it. It's not good shell code. If you want to open or close an FD for the current shell, use exec. exec {varname}<&1 exec {varname}<&-
Re: redirections preceded by a word with builtins inconsistent
I had read this before sending this message. The discussion you mention concerns leaking named redirections from function calls. This is not what I was trying to say. I was talking about the difference in behaviour between the creation and the destructions of the fd. There is also the difference in behaviour between builtins and external programs that confuses me, but in this case I just wanted to understand the creation and the destruction. Imho, since it is by design, there should be a mention of this is the documentation. I'm probably nitpicking, but the reasoning behind this is not obvious to me. Thanks, Adonis 2016-05-22 21:06 GMT+03:00 Chet Ramey: > On 5/21/16 5:16 PM, adonis papaderos wrote: > > > Bash Version: 4.3 > > Patch Level: 42 > > Release Status: release > > > > Description: > > When using redirections preceded by a word on builtins > > 'i.e. : {varname}<&1' > > the redirection persists to the current shell. > > This is by design, and has been discussed previously. One such discussion > starts at http://lists.gnu.org/archive/html/bug-bash/2016-01/msg00156.html > . > Maybe it should only do it when preceded by `exec', but it never has. > > > Later using {varname}<&- does not close fd. > > You don't precede it with an `exec', so it doesn't affect the current > shell. So-called `null' commands with redirections are executed in > subshells. This is where you need the `exec'. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ >
Re: redirections preceded by a word with builtins inconsistent
On 5/21/16 5:16 PM, adonis papaderos wrote: > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > When using redirections preceded by a word on builtins > 'i.e. : {varname}<&1' > the redirection persists to the current shell. This is by design, and has been discussed previously. One such discussion starts at http://lists.gnu.org/archive/html/bug-bash/2016-01/msg00156.html. Maybe it should only do it when preceded by `exec', but it never has. > Later using {varname}<&- does not close fd. You don't precede it with an `exec', so it doesn't affect the current shell. So-called `null' commands with redirections are executed in subshells. This is where you need the `exec'. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
redirections preceded by a word with builtins inconsistent
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux venus 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 42 Release Status: release Description: When using redirections preceded by a word on builtins 'i.e. : {varname}<&1' the redirection persists to the current shell. Later using {varname}<&- does not close fd. Repeat-By: ls -l /proc/self/fd : {varname}<&1 ls -l /proc/self/fd {varname}<&- : ls -l /proc/self/fd