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/
>
