Re: Add {{ }}, ${{ }}, return n [x], and $:

[konsolebox]

On Sat, May 1, 2021, 10:58 Robert Elz,

>   | You also would almost always want to enable the
>   | subshell to avoid the parent from getting its parameters altered.
>
> Many cases, yes, the point is that not forking works in the simple
> cases where it is most desired to not fork for speed $(echo ...) or
> more probably $(printf ... ) but in more than just those cases,
> extracting info from many shell built-in commands ( nfiles=$(ulimit -Sn) )
> can be handled without forking.
>

The problem is most people wouldn't want this optimization for simple
commands but rather on function calls where alteration of parameters is
unpredictable.


> Don't misunderstand though, getting this right is not trivial, detecting
> when it is safe requires a bunch of code, and handling issues like very
> large
> output streams (which would normally simply fill the pipe and hang a forked
> process until read) take care.
>
> It is however possible, and when implemented, simply works in the cases
> where it is possible, with all scripts, new and old.
>

It's very fragile to implement and the outcome of reliability is uncertain.
Having a set of new commands that allow it to be done with clearness is
better and avoids intrusive modifications.


> The problem with new invented features is that they tend to only work in
> one shell (at least initially) which means people prefer not to use them,
> in order to make their scripts more portable, which means other
> implementors
> are under no pressure to copy the feature...    Implemented optimisations
> for the standard shell syntax simply work, and improve performance, while
> still allowing the script to work anywhere.
>

I'm not really concerned about portability for this.  Bash has always made
its own fruitful implementations.


--
konsolebox