Date: Fri, 30 Apr 2021 19:28:47 +0800
From: konsolebox <konsole...@gmail.com>
Message-ID:
<cajnmqwzj6si_eoldjxhkmiuvwsro68zlfv_9+68++np6r7l...@mail.gmail.com>
| That was my initial idea too, but I think it's better to just leave {
| } alone as modifying its behavior still has a chance of breaking
| scripts.
It does have, though most usage of local is right at the start of
a function, so there would not be many scripts affects. But there
could be some.
| It will inherit or access the parent context's arguments just like in
| { } and ( ), virtually.
So, no specific args (an argumentless function) - that's what I
expected but these things need to be clear.
| I don't think it would break compatibility. `return n` will still
| work. Is there something I missed?
I meant that return cannot be modified to mean "leave the block" in a { }
block, it always needs to exit the enclosing function, so if that
functionality is needed, a new syntax would be required (I'm not sure it
really is needed though).
| It's to emulate how $? behaves,
Aside from being init'd to 0 when the shell starts, rather than unset,
$? works just the same as $!, its value remains until something occurs to
alter it. It is true that far more things set exit status than background
pid, but that's just a matter of degree, nothing operational.
| and also so people would write more readable code.
Good luck with that objective.
| > | The string can be a constant static for the sake of efficiency.
| It's an optional enhancement to implementation.
The point was that it isn't an enhancement - the only way to use a static
array of chars is to have a size limit on the value, and that's both ugly
to implement and to use. And there's no point.
| This optimization can be done as well as a separate target but $() can
| never be optimized enough as it almost would always rely on an opened
| pipe.
No, if there's no fork, there's no pipe either, the pipe simply allows
inter-process communications (simply - it could also be done using shared
memory, but that turns out to be far more complicated, and needs to turn
into a pipe if an external process ends up being run anyway).
| It would also be difficult to tell if one of the commands
| within it would send a message to &1 or not,
No, not difficult. Only code built into the shell (obviously) can
execcute in the shell without forking, and the shell knows what is
built in (and in shells like bash where something might be dynamically
loaded running such a command can be treated the same as running an
external command). Whenever an external command is to be run, a fork
is always required, so it may as well be done early, rather than late.
| or if one of them would execute `exec`.
Same thing, if anything in what should be a subshell env is to exec
or change the shell's state (in a way that cannot easily be undone)
the shell simply forks.
| 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.
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.
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.
kre
