process substitution data corruption on FreeBSD 5.3
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd5.3 Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd5.3' -DCONF_MACHTYPE='i386-portbld-freebsd5.3' -DCONF_VENDOR='portbld' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I/usr/local/include -O -pipe uname output: FreeBSD home.ecn.ab.ca 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #0: Sat Feb 12 12:07:46 MST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IMBEZOL i386 Machine Type: i386-portbld-freebsd5.3 Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Process substitution doesn't work on FreeBSD 5.3 due to corruption of the data. I've tested on other versions of FreeBSD (4.x) and Linux and there are no problems. On all of the 5.3 boxes I have tried though with Bash 3.x and Bash 2.x it does not work properly. I don't know if this is a bash bug or a FreeBSD bug. I submitted a bug report to FreeBSD some time ago but haven't seen any activity on it. http://www.freebsd.org/cgi/query-pr.cgi?pr=77493 Hostname: home - OS: FreeBSD 5.3-RELEASE-p5/i386 - CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2800.11-MHz 686-class CPU) - Processes: 424 - Uptime: 20d 19h - Users: 4 - Load Average: 8.94 - Memory Usage: 756.66MB/1531.22MB (49.42%) - Disk Usage: 3.77GB/142.85GB (2.64%) Repeat-By: while read line ; do echo $line ; done < <(cat /etc/passwd) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
printf builtin retains timezone from un-set TZ environment variable
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin17.7.0 Compiler: clang Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Darwin f638f97d 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PD$ Machine Type: x86_64-apple-darwin17.7.0 Bash Version: 5.0 Patch Level: 7 Release Status: release *Description:* I've noticed that a timezone explicitly set in the TZ environment variable can get cached (if any date-using command/builtin is run) and then show up (at least) in dates produced by the printf builtin's "%(...)T" formats even after the TZ variable is unset. I played around with this for a bit and identified two ways to get the timezone to re-set: - Run an external command. I have yet to find an external command that didn't correct it, so I suspect this behavior is intrinsic to the API calls made when running an external command. It's also possible I'm too unimaginative to find an external command that *doesn't* invoke date APIs :). - Set the TZ variable inline and run any builtin (i.e., `TZ=:/etc/localtime :`). *Repeat-By:* tzcache.sh echo $BASH_VERSION export TZ=Antarctica/South_Pole printf "TZ: $TZ\n\t%(%+)T\n" unset TZ # still prints the now-unset timezone printf "TZ: $TZ\n\t%(%+)T\n" # to reset it # run any external command # or any builtin with an inline TZ setting TZ=:/etc/localtime : printf "TZ: $TZ\n\t%(%+)T\n" $ env -i $(which bash) --norc --noprofile tzcache.sh 5.0.7(1)-release TZ: Antarctica/South_Pole Sun Jul 14 05:21:49 NZST 2019 TZ: Sun Jul 14 05:21:49 NZST 2019 TZ: Sat Jul 13 12:21:49 CDT 2019 Cheers, Travis
syntax errors produced by interaction between process substitution and a SIGCHLD trap
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin17.7.0 Compiler: clang Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Darwin 6841b968 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64 Machine Type: x86_64-apple-darwin17.7.0 Bash Version: 5.0 Patch Level: 7 Release Status: release Description: I stumbled into an odd interaction between process substitution and a SIGCHLD trap that causes syntax errors in otherwise valid commands. I managed to pare this down to a very minimal reproduction. I also included a more realistic command at the end just in case I'm mistaken about the minimal reproduction showing exactly the same issue. I see the same behavior in bash 4.4.23(1)-release and do *not* see it in the macos system bash 3.2.57(1)-release. Repeat-By: $ bash5 --norc --noprofile bash-5.0$ trap '$()' SIGCHLD bash-5.0$ $(:) $(:) bash: command substitution: line 3: syntax error near unexpected token `)' bash: command substitution: line 3: `:)' # Note that backticks don't cause the same trouble bash-5.0$ `:` `:` # in case there are multiple issues here # I found it while composing a command like this (to expand a set of globs, one per line, saved in file "exclude") bash-5.0$ /usr/bin/env cat <(printf "%s\n" $(< exclude )); bash: command substitution: line 6: syntax error near unexpected token `)' bash: command substitution: line 6: `< exclude ));'
inconsistent readonly error behavior
Configuration Information [Automatically generated, do not change]: Machine: x86_64OS: darwin17.7.0 Compiler: clang Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Darwin ecf1160e 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64 Machine Type: x86_64-apple-darwin17.7.0 Bash Version: 5. 0Patch Level: 18 Release Status: release Description: While trying to intentionally trap/ignore EXIT in a sourced script, I noticed that I couldn't keep it from exiting when it tried to overwrite PATH, which I had set to readonly. When I tried to minimize the repro case, I realized the behavior seems to differ between simple command and command list contexts. Repeat-By: readonly sigh=1 sigh=2 : reached sigh=2a; : skipped sigh=2b || : skipped if true; then sigh=3 : skipped fi I also have a gist with a slightly longer example (and output from bash, bash-sh, and osh: https://gist.github.com/abathur/8d18853e06f2a8cf3a97e45acda17f68 T
Re: inconsistent readonly error behavior
I don't understand what distinction you're trying to make; any example you
can give?
I added an extra near-copy of the script to the gist replacing the
assignment with unset (
https://gist.github.com/abathur/8d18853e06f2a8cf3a97e45acda17f68#file-unset-sh-console),
and corresponding output where you can see that it hits all of the lines
skipped in the assignment example. (The behavior in this example is in line
with what I see by replacing the assignment with other errors like a
missing command, or a ${parameter:?word} expansion.)
On Mon, Dec 21, 2020 at 11:46 PM Oğuz wrote:
> On Tue, Dec 22, 2020 at 7:28 AM Travis Everett
> wrote:
>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64OS: darwin17.7.0
>> Compiler: clang
>> Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
>> uname output: Darwin ecf1160e 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug
>> 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64
>> Machine Type: x86_64-apple-darwin17.7.0
>> Bash Version: 5.
>> 0Patch Level: 18
>> Release Status: release
>>
>> Description:
>> While trying to intentionally trap/ignore EXIT in a sourced script, I
>> noticed that I couldn't keep it from exiting when it tried to overwrite
>> PATH, which I had set to readonly. When I tried to minimize the repro
>> case,
>> I realized the behavior seems to differ between simple command and command
>> list contexts.
>>
>> Repeat-By:
>>
>> readonly sigh=1
>>
>> sigh=2
>> : reached
>>
>> sigh=2a; : skipped
>> sigh=2b || : skipped
>>
>> if true; then
>> sigh=3
>> : skipped
>> fi
>
>
> I don't understand what is wrong here. Is there any shell that doesn't
> discard the current line or the lines that constitute a compound command
> when a shell error occurs?
>
>
>> I also have a gist with a slightly longer example (and output from
>> bash, bash-sh, and osh:
>> https://gist.github.com/abathur/8d18853e06f2a8cf3a97e45acda17f68
>>
>> T
>>
>
Re: inconsistent readonly error behavior
I think I'm missing or misreading something. If I understood, the
assignment and expansion errors are both shell errors that should have the
same exit behavior?
But I see the assignment error ending the list and returning to the top
level, and the expansion exiting the script:
readonly sigh=1
if true; then
sigh=2
echo reached1
fi
echo reached2
if true; then
echo ${bad:?word}
echo reached3
fi
echo reached4
outputs:
./shell_error.sh: line 5: sigh: readonly variable
reached2
./shell_error.sh: line 8: bad: word
On Wed, Dec 23, 2020 at 9:09 AM Chet Ramey wrote:
> On 12/22/20 12:21 PM, Travis Everett wrote:
> > I don't understand what distinction you're trying to make; any example
> you
> > can give?
> >
> > I added an extra near-copy of the script to the gist replacing the
> > assignment with unset
>
> `unset' is a different thing. It's a special builtin, so POSIX requires a
> non-interactive shell to exit when it fails. The question is whether or not
> attempting to unset a readonly variable counts as a failure; the standard
> says only "Read-only variables cannot be unset" and doesn't require it to
> be an error. Behavior varies.
>
> (
> >
> https://gist.github.com/abathur/8d18853e06f2a8cf3a97e45acda17f68#file-unset-sh-console
> ),
> > and corresponding output where you can see that it hits all of the lines
> > skipped in the assignment example. (The behavior in this example is in
> line
> > with what I see by replacing the assignment with other errors like a
> > missing command, or a ${parameter:?word} expansion.)
>
> A `missing command' is not a shell error. An expansion error requires the
> shell to exit under the same conditions as a variable assignment error, and
> the bash behavior in posix and default modes is the same.
>
> --
> ``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: inconsistent readonly error behavior
Got it. Thanks. :)
On Wed, Dec 23, 2020 at 10:19 AM Chet Ramey wrote:
> On 12/23/20 11:10 AM, Travis Everett wrote:
> > I think I'm missing or misreading something. If I understood, the
> > assignment and expansion errors are both shell errors that should have
> the
> > same exit behavior?
> >
> > But I see the assignment error ending the list and returning to the top
> > level, and the expansion exiting the script:
>
> That's not an expansion error.
>
>
> > if true; then
> > echo ${bad:?word}
> > echo reached3
> > fi
> > echo reached4
>
> This is a well-defined expansion whose behavior is to exit a
> non-interactive shell if `bad' is unset or null.
>
> --
> ``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/
>
Security Vulnerability Reporting
Good Morning/Afternoon/Evening, Is there a set process in place for reporting security vulnerabilities against bash? If so, what might that process be? Thank you much! Regards, Travis Garrell
