Re: >&"$var" broken in declare -f and exported functions
On 6/3/22 11:18 AM, Namikaze Minato wrote:
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Output redirections to variable file descriptors inside functions
lead to incorrect representation (declare -f). Breaking exported
functions.
Reproductible with all bash versions from version 4.2 to latest
version including beta.
Reproductbile on all all platforms.
Repeat-By:
$ f(){ foo=1; printf test\\n >&"$foo"; }; declare -f f
Thanks for the report. This is, as you've pointed out, ambiguous until the
shell function is executed and `foo' is expanded. It's better for the
command printing code not to try to guess about how it will eventually be
translated when executed. I'll put in something to that effect, after
changing the code that caused this 2004 change.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: >&"$var" broken in declare -f and exported functions
On 2022-06-06 05:31, Namikaze Minato wrote: On Fri, 3 Jun 2022 at 23:24, Alexey wrote: As I can see, problem exist only if we quote "$foo". Without quotes everything looks fine. Hello Alexey. Thank you for the workaround of removing the quotes. And sorry for my being late to answer. Hello. Sorry If I was not clear. My point was only in such "workaround" by removing quotes. Mostly, to more precisely show where the problem is. Regards, Alexey.
Re: >&"$var" broken in declare -f and exported functions
On Sun, Jun 5, 2022, at 9:31 PM, Namikaze Minato wrote: > @everyone, please let me know if I need to do something else to > actually report the bug or if this thread is enough. This thread is enough. -- vq
Re: >&"$var" broken in declare -f and exported functions
On Fri, 3 Jun 2022 at 23:24, Alexey wrote:
>
> As I can see, problem exist only if we quote "$foo". Without quotes
> everything looks fine.
>
> > As a special case, if n is omitted, and word does not expand to one or
> > more digits or -, the standard output and standard error are redirected
> > as described previously.
> I guess this man line is related to this case, and explains why both
> stdin and stdout redirects occurs together (&>).
Hello Alexey.
Thank you for the workaround of removing the quotes.
And sorry for my being late to answer.
Please note however, that:
1 - n not being omited (and quotes being used) still produce the same bug:
$ f(){ printf test\\n 1>&"$foo"; }; declare -f f
f ()
{
printf test\\n &> "$foo"
}
2 - Even if I somehow did misunderstand the manual, the bug really
existing is incontestable as 'declare -f' does not display the
function code being executed.
$ foo=1 test
test
$ # As you can see, it did not create a file named "1" but behaved
just as defined, like `printf test\\n 1>&1`
$ eval "$(declare -f f)"
$ foo=1 f
$ cat 1
test
$ # reading the code from 'declare -f' changed the function!
@everyone, please let me know if I need to do something else to
actually report the bug or if this thread is enough.
Regards,
Minato
Re: >&"$var" broken in declare -f and exported functions
On 2022-06-03 19:18, Namikaze Minato wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -march=native -O2
uname output: Linux ns3012044.ip-37-187-96.eu 4.9.120--std-ipv6-64
#327490 SMP Thu Aug 16 10:11:35 UTC 2018 x86_64 Intel(R) Atom(TM) CPU
N2800 @ 1.86GHz GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Output redirections to variable file descriptors inside functions
lead to incorrect representation (declare -f). Breaking exported
functions.
Reproductible with all bash versions from version 4.2 to latest
version including beta.
Reproductbile on all all platforms.
Repeat-By:
$ f(){ foo=1; printf test\\n >&"$foo"; }; declare -f f
f ()
{
foo=1;
printf test\\n &> "$foo"
}
$ f
test
$ export -f f
$ bash
$ ls -l ./1
ls: cannot access './1': No such file or directory
$ f
$ ls -l ./1
-rw-r--r-- 1 lloyd lloyd 5 Jun 3 17:03 ./1
$ cat ./1
test
$
The representation of the function is incorrect (&> redirects both
stdin and stdout to files)
Please note that the function works properly unless you export and
use it or use the output of declare -f.
Hello.
As I can see, problem exist only if we quote "$foo". Without quotes
everything looks fine.
As a special case, if n is omitted, and word does not expand to one or
more digits or -, the standard output and standard error are redirected
as described previously.
I guess this man line is related to this case, and explains why both
stdin and stdout redirects occurs together (&>).
Regards,
Alexey
>&"$var" broken in declare -f and exported functions
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -march=native -O2
uname output: Linux ns3012044.ip-37-187-96.eu 4.9.120--std-ipv6-64
#327490 SMP Thu Aug 16 10:11:35 UTC 2018 x86_64 Intel(R) Atom(TM) CPU
N2800 @ 1.86GHz GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Output redirections to variable file descriptors inside functions
lead to incorrect representation (declare -f). Breaking exported
functions.
Reproductible with all bash versions from version 4.2 to latest
version including beta.
Reproductbile on all all platforms.
Repeat-By:
$ f(){ foo=1; printf test\\n >&"$foo"; }; declare -f f
f ()
{
foo=1;
printf test\\n &> "$foo"
}
$ f
test
$ export -f f
$ bash
$ ls -l ./1
ls: cannot access './1': No such file or directory
$ f
$ ls -l ./1
-rw-r--r-- 1 lloyd lloyd 5 Jun 3 17:03 ./1
$ cat ./1
test
$
The representation of the function is incorrect (&> redirects both
stdin and stdout to files)
Please note that the function works properly unless you export and
use it or use the output of declare -f.
