Antw: [EXT] Re: manual page missing ${parameter-replacement}
Sorry, I actually miussed it, as the typical usage pattern for lengthy manual
pages is like searching for ":-" and looking what is standing there:
${parameter:-word}
Use Default Values. If parameter is unset or null, the
expan-
sion of word is substituted. Otherwise, the value of
parameter
is substituted.
I see that there is some text before describing the first substitution pattern
common to all the ':' substitutions.
But from the syntax "${parameter:-word}" it's not really obvious that the
colon may be omitted.
Should it be "${parameter[:]-word}" (with non-bold square brackets) instead
(as for "name=[value]")?
Despite of that only ":-" is typeset in bold; shouldn't "${" and "}" be
typeset in bold, too?
>>> Lawrence Velázquez schrieb am 21.11.2022 um 08:49 in
Nachricht
<99ac660c-3f76-4461-92b6-605c27c02...@app.fastmail.com>:
> On Mon, Nov 21, 2022, at 2:20 AM, Ulrich Windl wrote:
>> I think the bash manual page lacks some important detail of parameter
>> substitution, namely:
>> "Bash tests for a parameter that is unset or null. Omitting the colon
>> results in a test only for a parameter that is unset."
>>
>> (found in
>>
>
https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.
> html)
>
> You omitted all of the relevant context. The full paragraph is:
>
> When not performing substring expansion, using the form [sic]
> described below (e.g., ':-'), Bash tests for a parameter
> that is unset or null. Omitting the colon results in a
> test only for a parameter that is unset. Put another way,
> if the colon is included, the operator tests for both
> _parameter_'s existence and that its value is not null; if
> the colon is omitted, the operator tests only for existence.
>
> The manual then goes on to describe the ${parameter:-word},
> ${parameter:=word}, ${parameter:?word}, and ${parameter:+word}
> forms. These are what your excerpt is talking about.
>
> So what do you think is missing, exactly?
>
> --
> vq
Re: bash 5.2 regression in optimize_connection_fork
On 11/19/22 3:08 PM, Frode Nordahl wrote: For some reason, when the 'ovn-controller incremental processing' test is executed using bash 5.2 on Debian experimental or Ubuntu Kinetic/Lunar, the `eval` [0] in the `counter_delta_` function misinterprets successful execution of commands [1], leading to a false negative for the 'ovn-controller incremental processing' test [2]. Can you enable -x around these commands so we can at least see what the commands are, and maybe synthesize a reproducer from that? Sure, the command string itself looks like this: + eval 'ovn-nbctl --wait=hv lrp-set-gateway-chassis lr1-public hv3 30 && ovn-nbctl --wait=hv sync Thanks. I was able to put together a small reproducer. The issue was the interaction between `eval' and a (command) subshell earlier in the script. If your fix works for you, go with it. I have somthing from a slightly different angle that I think will work as well. -- ``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: bash 5.2 regression in optimize_connection_fork
On Mon, Nov 21, 2022 at 3:45 PM Chet Ramey wrote: > On 11/19/22 3:08 PM, Frode Nordahl wrote: > > >>> For some reason, when the 'ovn-controller incremental processing' test > is > >>> executed using bash 5.2 on Debian experimental or Ubuntu > Kinetic/Lunar, the > >>> `eval` [0] in the `counter_delta_` function misinterprets successful > execution > >>> of commands [1], leading to a false negative for the 'ovn-controller > >>> incremental processing' test [2]. > >> > >> Can you enable -x around these commands so we can at least see what the > >> commands are, and maybe synthesize a reproducer from that? > > > > Sure, the command string itself looks like this: > > > > + eval 'ovn-nbctl --wait=hv lrp-set-gateway-chassis lr1-public hv3 > > 30 && ovn-nbctl --wait=hv sync > > Thanks. I was able to put together a small reproducer. The issue was the > interaction between `eval' and a (command) subshell earlier in the script. > > If your fix works for you, go with it. I have somthing from a slightly > different angle that I think will work as well. > Excellent, thank you for looking into it! As I'm not intimately familiar with the bash code base, the main reason for providing the proposed revert/fix was to help point in the direction of where the problem might be. We've worked around the concrete issue we had for now by disabling said test, and would have no issue with waiting for a proper fix. -- Frode Nordahl
Re: bash memory leak when querying associative array for nonexisting element
On 11/20/22 8:02 AM, Ralf Oehler wrote:
Bash Version: 5.2
Patch Level: 2
Release Status: release
Description:
I want to read an associative array. Like so: y="${aa[$i]}"
If aa contains the element queried, then everything works as expected
If aa does not contain such an element, the result is the empty string,
which is expected, but the query permanently increases the memory consumption
of the executing bash, which is not expected. The program below demonstrates
this behaviour. When run, the bash process increases its memory indefinitely.
I did not find a fix.
Thanks for the report. Koichi's fix is a good one.
Chet
--
``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/
`time ( someCmd )` Doesn't Print Time Under 5.2
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin22.1.0
Compiler: clang
Compilation CFLAGS: -DSSH_SOURCE_BASHRC
uname output: Darwin triton.parabon.com 22.1.0 Darwin Kernel Version 22.1.0:
Sun Oct 9 20:14:54 PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin22.1.0
Bash Version: 5.2
Patch Level: 9
Release Status: release
Description:
Under 5.2.x, measuring the `time` of a subshell -- `time ( sleep 1 )`
for example -- doesn't display any timing information,
whereas `5.1.x` and before did.
Builtins work[*] but if "someCmd" includes an external program, bupkis:
bash-5.2% time ( sleep 1 ) # No timing output
bash-5.2% time ( sleep 1 /dev/null ) # Okay
bash-5.2% time ( sleep 1 ) /dev/null # No timing output
bash-5.2% time ( sleep 1 ) | cat# Okay
bash-5.2% time ( sleep 1 ) > >(cat) # No timing output
bash-5.2% time ( exec 2>/dev/null; : ) # Builtin(s), but no timing
output (/dev/fd/2 leaks?)
bash-5.2% time ( echo Hi ) # Okay (Builtin)
bash-5.2% time ( exec echo Hi ) # No timing output
bash-5.2% time ( eval echo Hi ) # Okay
bash-5.2% time ( eval sleep 1 ) # Okay (...!)
bash-5.2% time ( eval exec echo Hi )# No timing output
bash-5.2% time ( { sleep 1; } ) # Okay, FWIW
bash-5.2% time { ( sleep 1 ); } # Okay, FWIW
emanuele6 suspects it has to do with
https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00107.html
Also:
i tried to run this script bash 5.2 with little memory
.source_code/bash/bash -c 'ulimit -v 5000; for (( x = 0;
i < 200; ++i )); do echo "$i"; time (:); done'
it fails after 20 calls with OOM
and in bash 5.1, that code runs without problems
Re: `time ( someCmd )` Doesn't Print Time Under 5.2
On Mon, Nov 21, 2022 at 07:07:08PM -0500, d...@dabe.com wrote: > emanuele6 suspects it has to do with > https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00107.html No, actually later, I said that it has probably been introduced earlier since I tried running 'time (sleep 1)' in a version of bash that preceeds that change (namely 6711d2dc7793ed3d35e91b2bd4ecbdfccfcf469f (2022-10-24)), and it still didn't print the timing report. But I said it may have something to do with bash running some code that should run in the main shell, in the subshell that runs the command, since bash 5.2 prints timing information for `time (echo hi)' (builtin command), but not for `time (/bin/echo hi)' (external command). But I have not investigated what is the actual cause of the issue. emanuele6
Re: `time ( someCmd )` Doesn't Print Time Under 5.2
On 11/21/22 7:36 PM, Emanuele Torre wrote: On Mon, Nov 21, 2022 at 07:07:08PM -0500, d...@dabe.com wrote: emanuele6 suspects it has to do with https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00107.html No, actually later, I said that it has probably been introduced earlier since I tried running 'time (sleep 1)' in a version of bash that preceeds that change (namely 6711d2dc7793ed3d35e91b2bd4ecbdfccfcf469f (2022-10-24)), and it still didn't print the timing report. Mea culpa... Thanks for the clarification! :-D -- :- Dabe
Re: `time ( someCmd )` Doesn't Print Time Under 5.2
2022年11月22日(火) 9:36 Emanuele Torre :
> No, actually later, I said that it has probably been introduced earlier
> since I tried running 'time (sleep 1)' in a version of bash that
> preceeds that change (namely 6711d2dc7793ed3d35e91b2bd4ecbdfccfcf469f
> (2022-10-24)), and it still didn't print the timing report.
`git bisect' finds the following commit (2022-01-31) which introduced
the behavior:
> commit b325b0e96bd05c76bbfc4d60d0707fc93d58f03f (HEAD, refs/bisect/bad)
> Author: Chet Ramey
> Date: Mon Jan 31 09:53:03 2022 -0500
>
> more changes for here-docs and $'...'; command optimization updates
>
> [CWRU/CWRU.chlog]
>
>1/25
>
> parse.y
> - parse_matched_pair: ansi-expand $'...' in WORD for ${PARAM OP WORD}
> and single-quote the result if dolbrace_state == DOLBRACE_QUOTE
> (posix pattern removal operators) even if extended_quote == 0
>
> subst.c
> - extract_heredoc_dolbrace_string: add logic to align with parse.y:
> parse_matched_pair and its $'...' expansion, including handling
> extended_quote
>
>1/27
>
> builtins/evalstring.c
> - should_optimize_fork: broke conditions for optimizing away the fork
> for a simple command out of optimize_fork into new function, call
> from should_suppress_fork and optimize_subshell_command. Call from
> optimize_fork if (subshell_environment & SUBSHELL_PAREN), relying
> on fact that CMD_TRY_OPTIMIZING is only set in a couple of specific
> conditions
> - optimize_fork: call should_suppress_fork only if startup_state == 2;
> it does the extra checks for that specific case
> - optimize_fork: call should_optimize_fork if we're in a (list)
> subshell (subshell_environment & SUBSHELL_PAREN)
> - optimize_subshell_command: set CMD_TRY_OPTIMIZING on the right side
> of a `&&', `||', or `;' list as long as it's a simple command so
> we can check with optimize_fork() when it's time to execute it
>
> execute_cmd.c
> - execute_in_subshell: call optimize_subshell_command for (list)
> subshells to either set CMD_NO_FORK for simple commands or set
> CMD_TRY_OPTIMIZING for likely candidates for later optimization
>
> builtins/common.h,builtins/evalstring.c
> - optimize_fork: renamed to optimize_connection_fork; changed callers
Re: `time ( someCmd )` Doesn't Print Time Under 5.2
On 11/21/22 9:32 PM, Koichi Murase wrote: `git bisect' finds the following commit (2022-01-31) which introduced the behavior: commit b325b0e96bd05c76bbfc4d60d0707fc93d58f03f (HEAD, refs/bisect/bad) execute_cmd.c - execute_in_subshell: call optimize_subshell_command for (list) subshells to either set CMD_NO_FORK for simple commands or set CMD_TRY_OPTIMIZING for likely candidates for later optimization More crumbs, FTR: 19:51 this comment looks very suspicious https://git.savannah.gnu.org/cgit/bash.git/diff/execute_cmd.c?h=devel&id=9928dcb48f35d957d936f9c6d8bec8cec8b76317 19:52 that patch addresses this bug https://lists.gnu.org/archive/html/bug-bash/2021-09/msg00047.html -- :- Dabe
Re: [EXT] Re: manual page missing ${parameter-replacement}
On Mon, Nov 21, 2022, at 4:38 AM, Ulrich Windl wrote:
> But from the syntax "${parameter:-word}" it's not really obvious that the
> colon may be omitted.
You're not wrong.
> Should it be "${parameter[:]-word}" (with non-bold square brackets) instead
> (as for "name=[value]")?
No, that would be extremely confusing. But I think something like
this has been suggested before (I don't remember by whom):
${parameter-word}
${parameter:-word}
Use Default Values. [...]
${parameter=word}
${parameter:=word}
Assign Default Values. [...]
${parameter?word}
${parameter:?word}
Display Error if Null or Unset. [...]
${parameter+word}
${parameter:+word}
Use Alternate Value. [...]
> Despite of that only ":-" is typeset in bold; shouldn't "${" and "}" be
> typeset in bold, too?
I don't know. It seems like boldface is used to highlight the parts
that are unique to each form.
--
vq
Antw: Re: [EXT] Re: manual page missing ${parameter-replacement}
>>> Lawrence Velázquez schrieb am 22.11.2022 um 05:06 in
Nachricht
:
[...]
>> Despite of that only ":-" is typeset in bold; shouldn't "${" and "}" be
>> typeset in bold, too?
>
> I don't know. It seems like boldface is used to highlight the parts
> that are unique to each form.
AFAIK, bold means "literal" and non-bold or specifically italics means
"placeholder".
>From man-pages(7):
"(...) boldface is used for as-is text and italics are used to indicate
replaceable arguments. Brackets ([]) surround optional arguments,
vertical bars (|) separate choices, and ellipses (...) can be repeated.
(...)"
>
> --
> vq
Re: [EXT] Re: manual page missing ${parameter-replacement}
On Tue, Nov 22, 2022, at 2:20 AM, Ulrich Windl wrote:
> AFAIK, bold means "literal" and non-bold or specifically italics means
> "placeholder".
> From man-pages(7):
>
> "(...) boldface is used for as-is text and italics are used to indicate
> replaceable arguments. Brackets ([]) surround optional arguments,
> vertical bars (|) separate choices, and ellipses (...) can be repeated.
> (...)"
Again, you have omitted relevant context. That excerpt is from
a section of man-pages(7) that discusses synopses. We are not
talking about a man page synopsis.
The "Parameter Expansion" section of bash(1) simply does not use
boldface for "${" / "}". I don't know if that is intentional, but
I would guess that only the unique portions of each expansion form
are emphasized with boldface. Setting every "${" / "}" in boldface
too would dilute that emphasis significantly.
--
vq
