2023年2月14日(火) 2:16 Oğuz <oguzismailuy...@gmail.com>:
> 13 Şubat 2023 Pazartesi tarihinde Koichi Murase <myoga.mur...@gmail.com>
> yazdı:
>> Nevertheless, even if we forget about trap, jobs, etc., ${ list; }
>> alone is very useful as it's free from the fork cost
>
> Shells fork all the time. If your application can't afford the overhead,
> you've chosen the wrong language to write it in.
I agree that when we see such a request in this mailing list or in
help-bash, it would probably be the wrong choice of language in most
cases, more than 80% or 90%.
But it doesn't mean that it's always the wrong choice 100%. 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. Even a 30--50ms delay of prompts is actually
noticeable by humans, but the delay can easily reach that threshold by
two or three command substitutions $() in slower systems. How can we
program Bash's prompt in a "more appropriate" language? We cannot
request Bash users to directly edit the C source of Bash and build
Bash binary from the source every time the user wants to change the
configuration slightly.
There is an attempt to replace the shell prompt with a single call of
$(external-cmd) and let the external command generate the entire
prompt, such as Starship written in Rust. I think that is one valid
option that a user can choose, but I don't think we should delete
every feature related to PS1 from Bash and totally switch to an
approach to ask users to write the prompt codes in another compiler
language from scratch.
>> and also can
>> affect the parent shell context when it wants to.
>
> This doesn't sound like an upside to me, I can't think of any use case where
> it wouldn't make the code more confusing.
The fact that one cannot think of the use cases doesn't prove that
there are no use cases at all. 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. This can happen unless one
argues the global variable should not be changed by shell functions at
all. Of course, it is still possible to do the trick « eval
"$(something; declare -p global1 global2 etc)" », but this is
unnecessarily complicated compared to what to achieve.
Anyway, if there are no use cases or no benefits at all, ksh didn't
have the feature.
