Re: set -e not working as expected with conditional operators
On 6/2/23 4:01 AM, rpaufin1 wrote: However, the result should be the same. The manual says otherwise: The shell does not exit if the command that fails is [...] part of any command executed in a && or || list except the command following the final && or ||
Re: `wait -n` returns 127 when it shouldn't
On 5/17/23 3:27 PM, Martin D Kealey wrote: On Wed, 17 May 2023 at 20:20, Oğuz İsmail Uysal wrote: On 5/16/23 8:35 PM, Aleksey Covacevice wrote: [original code elided as it's been mangled by line-wrapping] This boils down to the following true & false & wait -n With respect, I disagree with that statement of equivalence. The only way for the loop to terminate is when `wait` returns 127, after both children have been reaped. By when the non-zero exit status of "false" will have been noted, and then used as the return value of the function. Must have misread then, thanks
Re: `wait -n` returns 127 when it shouldn't
On 5/16/23 8:35 PM, Aleksey Covacevice wrote:
waitjobs() { local status=0 while true; do local code=0; wait -n ||
code=$? ((code == 127)) && break ((!code)) || status=$code done return
$status } # Eventually finishes: while true; do ( true & false &
waitjobs ) && break; done
This boils down to the following
true &
false &
wait -n
There is no guarantee that `wait -n' will report the status of `true',
the shell may acquire the status of `false' first. It's not a bug.
Re: nofork command substitution
On 5/15/23 9:51 PM, Chet Ramey wrote:
Everything is shared between the comsub and its caller, with a
couple of documented exceptions. So it's just like calling `fg' in the
current execution environment, but capturing the output.
Oh, okay then. Thanks.
How about this?
$ declare -i x
$ y=${ :;}
$ declare -i z
bash: make_local_variable: no function context at current scope
$
Re: nofork command substitution
On 5/15/23 8:35 PM, Chet Ramey wrote:
Please test it out
$ cat
^Z
[1]+ Stopped cat
$ x=${ fg;}
foo
foo
<^C or ^D here>
$ declare -p x
declare -- x="cat"
$
Is this intended?
Re: IFS field splitting doesn't conform with POSIX
On 3/30/23 7:51 PM, Felipe Contreras wrote: So? This is argumentum ad populum. The fact that most shells do X doesn't imply that POSIX says X. POSIX documents existing practice. If what it says differs from what the majority of shells do, then it's POSIX that is wrong. And this mailing list is not the right place to complain about it. Yes. 'foo,bar,' has two terminators, and therefore two fields. 'foo,bar,roo' has two terminators and therefore two fields, plus garbage. You want to interpret 'foo' as a field, even though it does not have an an explicit terminator. But that's not specified anywhere in POSIX. POSIX doesn't say what should be done with the text after the last terminator. You could throw it away and still be conforming to POSIX. I don't think *to SPLIT using delimiters as field terminators* involves leaving any part out.
Re: IFS field splitting doesn't conform with POSIX
On 3/30/23 2:12 PM, Felipe Contreras wrote: IFS=, str='foo,bar,,roo,' printf '"%s"\n' $str zsh is the only shell that generates an empty last field, no other shell exhibits this behavior. Besides your link says: >The shell shall treat each character of the IFS as a delimiter and use the delimiters as *field >terminators* to split the results of parameter expansion, command substitution, and arithmetic >expansion into fields. So the delimiters terminate fields, not separate them.
Re: Bash not portable to C23
On 3/24/23 4:49 AM, Paul Eggert wrote: a strict C23 compiler Does such a compiler exist? Is C23 even published yet?
Re: Having an alias and a function with the same name leads to some sort of recursion
On 2/18/23 2:05 AM, Chet Ramey wrote: If the shell reads an unquoted word in the right position, it checks the word to see if it matches an alias name. If it matches, the shell replaces the word [in the input] with the alias value, and reads that value as if it had been read [from the input] instead of the word. This isn't what bash does. See: $ alias foo='cat
Re: "builtin jobs" does not output to stdout.
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.
Re: "builtin jobs" does not output to stdout.
On 2/13/23 2:43 PM, Koichi Murase wrote:
I guess just the support for ksh's ${ list; } [1] would make
everything simple and clear. One can simply call ${ jobs; }, ${ trap
-p; }, etc. without thinking about subshells.
I don't see what difference that'd make. A subshell inherits its
parent's job list, and `$(trap ...)' expands to what `trap ...' would
output if it were run in the parent shell; these are well specified in
the standard.
I think `builtin' should be fixed and the rest left alone.
Re: unset does not remove functions like a[b] unless -f is specified
On 2/4/23 12:23 PM, Koichi Murase wrote: Changing the behavior related to the function names wouldn't make the behavior of the shell entirely unspecified I see, but that's not what you're suggesting. You're suggesting that how command search and execution works be changed to allow functions that contain slashes in their names to prevent command search, and shadow filesystem entries including those of standard utilities. The fact that bash and zsh already allow it doesn't mean it's a good idea. And it's easier to make the overall behavior unspecified than examine each shell and document this new behavior; preferable too considering how little it benefits the user.
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
On 10/31/22 2:20 PM, Greg Wooledge wrote:
Bash already uses the POSIX regex functions (regcomp(3) et al.) to do
[[ =~ ]] using POSIX ERE.
Yeah, and offers no more than what your libc's regex engine has. For
example, you can't tell what `[[ x =~ .{256} ]]' (or even `[[ x =~ ""
]]') would return without knowing the operating system it's run on.
extglobs aren't like that and shouldn't be either.
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
On 10/30/22 3:25 PM, Martin D Kealey wrote: How much faster do you think it can be made? I don't know, irrelevant though. The problem is not that individual steps are slow, but rather that it takes at least a higher-order-polynomial number of steps, possibly more (such as exponential or factorial). Speeding up the individual steps will make no practical difference, while pin-hole optimisations may dramatically speed up some common cases, but still leave the most general cases catastrophically slow. These are technical details; no user cares about them. The purpose of my suggestions was to /minimize/ the complexity that becomes part of Bash's codebase, while leaving as few pathological cases as possible - preferably none. I meant complexity of the language, not the codebase. In my opinion "make the existing extglob code faster" is a wasted effort if it doesn't get us to "run in at-most quadratic time" and preferably "run in regular (linear) time", and so that basically amounts to "write our own regex state machine compiler and regex engine". This is a non-trivial task, and would fairly obviously add *more* complex code into Bash's codebase than any of my suggested alternatives. extglobs are already a part of the bash language. All of your suggested alternatives involve expanding the language in question. That's why I disagree with all of them. (Even my options of "postprocess the codebase" or "modify an existing regex compiler" would leave their execution components untouched; only the compilation phase would be modified, and a modified regex compiler would at least stand a chance of existing as a stand-alone library project.) If you mean bash should start shipping a huge library like pcre for solving an edge case, I don't think that's reasonable at all; why take on such a burden when you already have something that works fine in practice?
wait inside subshell waits for sibling
To reproduce: $ echo $BASH_VERSION 5.2.2(3)-release $ ( : & wait ) > >(cat) *hangs* It should return immediately, but hangs instead.
Re: feature request: new builtin `defer`, scope delayed eval
On 10/8/22 6:03 AM, Cynthia Coan wrote: Otherwise, I think we can perhaps reword this into two smaller features: "function local trap signals", and I don't think this would be a feature worth the time to implement and the complexity it would introduce. Is there any other use case for this than cleaning up temporary files on function return? "options to safely append/prepend to a trap" (for some definition of 'safe', perhaps this just means separating by ';'? Unsure if there's a better way off the top of my head). This can be achieved by adding a new option to `trap' that causes it to print the action string for given condition. Let this option be named `-P', the user would do something like this to update a trap: trap "foo;" EXIT trap "$(trap -P EXIT)bar;" EXIT
Re: Looking to the future (was Re: Light weight support for JSON)
On 8/29/22 5:48 AM, Martin D Kealey wrote:
The Shell persists because it has one killer feature: it does double duty
as a scripting language and as an interactive command language. But we're
kidding ourselves if we think that no other language could fill that gap:
Python has a respectable interactive mode, though its focus is on objects
rather than processes and files; the interactive "debugger" console inside
Firefox speaks Javascript; and even "perl -d" is almost usable.
So, neither of those could fill that gap. What could then?
As for the future, I believe that if we don't move towards making the POSIX
sh behaviour a truly optional part of an otherwise-more-sane language, we
condemn Bash to continued obscurity and eventual extinction.
Nah. I think Bash already has too many features over POSIX; anything
beyond indexed arrays, indirect expansions, and
`${parameter/string/replacement}' is bloat.
Besides, who is going to evolve Bash into this "more-sane language"?
