On Wed, 27 Aug 2025 at 15:16, Koichi Murase <myoga.mur...@gmail.com> wrote:
> 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) > > 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. 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. Instead, the responsibility is on anyone who uses shopt -s cmdsubst_trailing_nls, because in doing so, they are specifically choosing and opting-in to the alternative behavior. It's not reasonable to expect a shell with modified behavior to flawlessly run code that was written before the modified behavior even existed. When a user chooses modified behavior, and also tries to run code which assumes unmodified behavior, it is that user who must adjust accordingly (eg. by using their own wrapper functions to save/restore the shopt values before/after calling any external library shell code, thereby ensuring this external code's assumptions are valid). This is why the default values for the shopts are to preserve the standard historical behavior. It's also the way things are for a variety of other existing behavior-modifing options (eg. cdable_vars, dotglob, extquote, failglob, ...), and most shell code is written while (reasonably) assuming the defaults for these options. > It should be implemented as a new syntax or a shell function. New syntax does have advantages (including avoiding the above shopt disadvantages), but it also has disadvantages: - It's harder to implement, and I would expect a higher maintenance burden. - 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. - There are downstream effects to additional syntax, eg. syntax highlighting rules need to be updated, linters need updating, etc. - 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. > 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" - whereas the entire goal here is to find a solution without compromising on that requirement. It may be that the downsides to user-selectable behavior outweigh the benefits of idiomatic code, but I don't think it's right to say that shell functions can idiomatically solve all issues of this type. 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. Kev
