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

[Oğuz İsmail Uysal]

On 2/15/23 2:52 AM, Koichi Murase wrote:
> two or three command substitutions are generally not considered "so 
> many command substitutions".
I can't reproduce a great deal of unresponsiveness with five or six 
either, and my computer is very old too. I think this "delay" you 
mentioned has more to do with the commands being substituted than bash.
> 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.
It's all about priorities; if your top priority is fashionable prompt 
strings, you won't mind the inferior language.
> 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.
But they benefit the user tremendously.
> 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.
The developer doesn't count as an organic user. And ksh93 has been 
around for three decades; if there were demand for the feature in 
question, other shells would have copied it already.
> 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). 
How many forks does that avoid anyway? Let's be realistic, the overhead 
from one fork is not enough to warrant new syntax.