Re: "builtin jobs" does not output to stdout.

[Koichi Murase]

2023年2月14日(火) 4:32 Oğuz <oguzismailuysal@gmail.com>:
> 13 Şubat 2023 Pazartesi tarihinde Koichi Murase <myoga.murase@gmail.com> 
> yazdı:
>> One of the
>> cases that the fork cost of $() becomes a problem and that other
>> languages cannot be really used is the prompt setting `PS1' containing
>> command substitutions.
>
> Bash has many escape sequences to enrich your prompt strings. If they don't 
> meet your needs and you find yourself embedding so many command substitutions 
> in them that there is a discernible delay,

That is not my personal use case. In fact, my PS1 is just as simple as
PS1='[\[<color code>\]\u@\h\[<color reset>\] \j \W]\$ '. Honestly, I
do more non-trivial and unusual stuff in my personal configurations,
but I'm personally satisfied with the current feature set of Bash
(with many supplementing shell functions) unless the long-lasting Bash
behaviors would be broken by the literal interpretation of a corner of
the standard that people haven't paid much attention historically.

I just naively think that ${ list; } would help normal users who
wouldn't like to do non-trivial stuff. There are many users who try to
embed multiple command substitutions to acquire git repository
information or other version-control-system information for the
current directory, the information of the current Python/Ruby virtual
environment, etc. The upstream Git itself prepares a utility intended
to be used in the command substitution embedded in PS1 as
/contrib/completion/git-prompt.sh in the git repository of git.
Embedding command substitutions for the VCS information and virtual
environment information in the prompt string is nothing wrong, and two
or three command substitutions are generally not considered "so many
command substitutions".

> perhaps it's time you give other shells a try. I hear fish is good.

For me, there are no other shells that are sufficiently matured for
daily uses and have essentially different languages and libraries that
are fully featured as Java, Python, C, etc.

You might hear of Fish shell is good, but which part of Fish shell is
considered good? They are just good for interactive behaviors. When we
focus on the language design, Fish shell is actually worse than Bash.
They tried to change superficial syntax like the keywords "esac",
"fi", etc., but they made a number of mistakes in the initial language
design, and many serious language defects are left unresolved for
compatibility. For example, it was impossible in Fish shell to pass
the multiline result of command substitutions as an argument to
another command until recently. They gave up and now have two
different command substitution syntaxes, () and $().

Instead, one might consider moving to other shells with languages
similar to POSIX sh or Bash, but in that case, the limitations of `sh'
languages still apply.

>> An example is a shell function: a shell
>> function can change the global variables (or previous-scope variables
>> with Bash's dynamic scoping) and, at the same time, can output data to
>> stdout. When one wants to capture the stdout of such a function while
>> keeping the changes made to the global variables, the command
>> substitution cannot be directly used.
>
>
> It's not a good example because there isn't much difference between `f() { 
> list; }; x=$(f)' and `x=$(list)', they both read the output of `list' into 
> `x'.

The assumption is the opposite. I'm not talking about converting
existing command substitutions to shell functions, of course. I'm
thinking the case where we first have a shell function that is not
necessarily intended for the command substitution but for general
uses, and then we would like to use its output in a particular place.

> When is it absolutely necessary to both retain the side effects of `list' and 
> save its output to a variable?

Of course, there is no case where ${ list; } is "absolutely
necessary". But in that logic, the shell functions are not "absolutely
necessary", and even the command substitutions are not "absolutely
necessary" as everything can be in principle processed in combinations
of pipelines and { list; }, etc. The reason that we have shell
functions and command substitutions is that it makes it easier to
organize shell programs. For the same reason, functions are allowed to
return results with a side effect while it is not "absolutely
necessary" as one can rewrite the entire program in a purely
functional way. Then, when one wants to use the output of such a
function, it is useful to have ${ func; } while it is not "absolutely
necessary" because one can always reimplement the entire program so
that it doesn't have any functions with side effects.

>> Anyway, if there are no use cases or no benefits at all, ksh didn't
>> have the feature.
>
> Ksh has many features no one ever uses; some of them don't make any sense, 
> some don't even work. Check out <https://github.com/ksh93/ksh>, it's a mess 
> compared to bash.

OK, I understand what you try to say, (though I regard "no one ever"
and "any sense" as exaggerations; at least the developer who
introduced the feature should have had the reasoning and also should
have used it. Even excluding that, we cannot say "no" or "any" without
any survey.). We can't still conclude that there are "no benefits at
all", but you are right that not all the Ksh features are worth
implementing in Bash.

In particular for ${ list; }, I still think it benefits the users,
even though it can be thought of kind of syntax sugar for `list > tmp;
var=$(< tmp)' (as managing the temporary files properly is
usually.non-trivial).