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 ||
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 &
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 t
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
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?
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
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
On 3/24/23 4:49 AM, Paul Eggert wrote:
a strict C23 compiler
Does such a compiler exist? Is C23 even published yet?
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] inst
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 d
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
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
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
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 factor
To reproduce:
$ echo $BASH_VERSION
5.2.2(3)-release
$ ( : & wait ) > >(cat)
*hangs*
It should return immediately, but hangs instead.
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
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 interac
17 matches
Mail list logo
