2025年8月27日(水) 12:27 Kevin Pulo <kevin.p...@mongodb.com>:
> [...] (1) the choice of using shopts to modify behavior (vs
> alternative syntax ala [3]; each of these approaches has pros and cons), and
I'm opposed to adding new shell options to change the behaviors of
existing codes. If these options were added, we would need to manage
those options everywhere we use command substitutions. The purpose of
the suggestion is to provide a way to simplify
> foo=$(some_command ... ; rc=$? ; echo . ; exit $rc)
> rc=$?
> foo=${foo%.}
to something like
> when what you actually mean (idiomatically) is:
>
> foo=$(some_command ...)
However, this isn't true. With these features implemented as shell
options, in general, one actually needs to write it in the following
way:
local saved=$(shopt -p cmdsubst_trailing_nls) # (assume we are in a function)
shopt -s cmdsubst_trailing_nls
foo=$(some_command ...)
eval -- "$saved"
This is complication rather than simplification. One can write the
simple « foo=$(...) » *only when* it is not an interactive Bash
settings or shell libraries and the script doesn't source any external
libraries. Otherwise, every time one uses any command substitions, one
needs to save and restore the shell option, or one needs be careful
about whether the shell option is esnured to be at the expected side
in the current context. Even worse, this affects existing command
substitutions (which assumes the traditional behavior of stripping
trailing newlines). To properly do it, all command substitutions in
existing shell libraries and Bash interactive settings need to be
rewritten as
local saved=$(shopt -p cmdsubst_trailing_nls)
shopt -u cmdsubst_trailing_nls
...
foo=$(cmd_expecting_tranditional_cmdsub_behavior)
...
eval -- "$saved"
At least the behavior of existing command substitutions shouldn't be
touched. It should be implemented as a new syntax or a shell function.
The suggestion argued that a shell-function implementation
(illustrated as `grab_output') wouldn't look like command
substitutions and thus doesn't look so idiomatic, but if one accepts a
different way of calling the feature than the traditional command
substitutions, there doesn't seem to be a strong reason to refrain
from a shell function. Honestly, I think these can be simply
implemented as shell functions.
--
Koichi
