[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Add {{ }}, ${{ }}, return n [x], and $:
From: |
konsolebox |
Subject: |
Re: Add {{ }}, ${{ }}, return n [x], and $: |
Date: |
Tue, 28 Dec 2021 12:29:32 +0800 |
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