2025年8月27日(水) 17:30 Kevin Pulo <kevin.p...@mongodb.com>:
> It's correct that using the shopt to change the behavior will, in general,
> break existing code that assumes the original unmodified behavior, and this is
> one of the main downsides of using shopts to modify behavior.
>
> However, I don't agree that the responsibility lies with everyone who's ever
> previously used $() (or ever will use it in the future), to check that the
> user
> hasn't opted-in to some strange non-standard non-historical behavior that
> previously didn't exist.
I also really would like to agree with the idea that the
responsibility should be attributed to the one who left the
non-standard option, but in reality, it is merely an ideal.
We constantly receive reports from users saying "the frameworks should
work flawlessly with this set of options because it is the built-in
feature of Bash", etc. in bash-completion, oh-my-bash, ble.sh, etc. It
won't stop until we enclose all command substitutions within « local
saved=$(shopt -p cmdsubst_trailing_nls); shopt -s
cmdsubst_trailing_nls ... eval -- "$saved" ».
In addition, meta-language frameworks, such as bashdb, bats,
shellspec, etc., by definition need to work under an arbitrary set of
non-historical options because otherwise, these frameworks cannot be
used to test any shell programs that use non-historical options.
Even if a consensus that "the frameworks don't need to handle
non-historical options" could be formed in the future, such a shell
option to change the traditional behavior still remains to be a
pitfall. Why do you stick with changing the historical behavior?
----
> - It's harder to implement, and I would expect a higher maintenance burden.
It's much easier than implementing an entire shell from scratch. On
this list, you are talking to the people who have developed and
maintained a shell. The cost is negligible as long as it is properly
implemented.
> - The new syntax should be chosen carefully to ensure clean/graceful failure,
> or acceptable fallback behavior, in earlier versions and shells which don't
> support the new syntax.
This is actually my point. By "a new syntax", of course, I mean a
syntax that fails to parse and causes a syntax error in previous
versions of Bash. Otherwise, it would affect the behavior of existing
codes that were parsed without errors so cannot be called "a new
syntax".
What you propose is actually the opposite. With the shell options to
change existing behaviors, existing codes expecting the traditional
behavior may produce unexpected results *without causing an explicit
error*, when they are combined with a code that changes the option
poorly.
> - There are downstream effects to additional syntax, eg. syntax highlighting
> rules need to be updated, linters need updating, etc.
It is negligible if they already support the entire shell syntax.
> - Modifying existing code which uses traditional trailing newline behavior, to
> instead use the alternate trailing newline behavior, requires switching to
> the new syntax throughout the scripts, rather than choosing the desired
> behavior once at the start of the script.
This doesn't seem to make sense. When you want to switch to use the
new behavior, even if you decided to change the existing behavior of
command substitutions instead of adding a new syntax, you still need
to rewrite the entire scripts to remove the extra handling of $? and
${result%.} in the existing scripts, or you need to scan through the
entire shell scripts to see whether the behavioral change do not
affect the behavior of the existing codes.
----
> > 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.
>
> Unfortunately "if one accepts a different way" is exactly saying "if one
> accepts non-idiomatic code"
Do you mean that a new syntax is also non-idiomatic? Do you think the
only idiomatic code is to change the existing behavior of the command
substitutions with exactly the same syntax? If so, I cannot agree.
> For example, while it's possible for me to write a shell function that wraps
> builtins/commands and "adjusts" their behavior, the inability to use shell
> functions (or anything else) to modify the behavior of shell syntax constructs
> like $(), is precisely why I looked into adding these shopts in the first
> place.
This is tautological. The above seems to attempt to explain the reason
why the option to change the existing behavior of shell constructs
like $() is introduced instead of using a shell function. It says the
reason is that the existing constructs like $() cannot be modified by
using shell functions. More than half of the arguments seem to be
nonsensical. Do you use LLM?
--
Koichi
