Support ksh93 x=${cmd;}

code=%d\n" "$out_stdout" "$out_stderr" "$out_res"' stdout='', stderr=$'ls: cannot access \'x\': No such file or directory', exit code=2 Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur

Re: bash parallel build: make[1]: warning: -j16 forced in submake: resetting jobserver mode.

On Fri, 26 Apr 2024 at 03:57, Dan Shelton wrote: > > On Mon, 22 Apr 2024 at 22:54, Chet Ramey wrote: > > > > On 4/22/24 11:58 AM, Chet Ramey wrote: > > > On 4/20/24 2:02 AM, Cedric Blancher wrote: > > > > > >>> You can check what env the subma

bash newgrp(1) -c option? Fwd: /usr/bin/sg in Cygwin?

equested group like bash -c does. Dan -- Dan Shelton - Cluster Specialist Win/Lin/Bsd -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur

Re: bash parallel build: make[1]: warning: -j16 forced in submake: resetting jobserver mode.

On Sun, 14 Apr 2024 at 01:24, Dmitry Goncharov wrote: > > On Sat, Apr 13, 2024 at 12:41 AM Cedric Blancher > wrote: > > > > Good morning! > > > > Building bash HEAD on Cygwin 3.5.3 and Debian Linux 11 in make > > parallel mode issues a warning, which look

bash parallel build: make[1]: warning: -j16 forced in submake: resetting jobserver mode.

Good morning! Building bash HEAD on Cygwin 3.5.3 and Debian Linux 11 in make parallel mode issues a warning, which looks like a Makefile bug: $ make -h 16 ... make[1]: warning: -j16 forced in submake: resetting jobserver mode. ... Can this be fixed please? Ced -- Cedric Blancher [https

Re: [PATCH] Add-rm-rf-as-examples-loadables-rm.c

'enable -f /examples/loadables/rm rm'. > > Tested on wget configure script where it increases overall execution time by > 6-7%. > > Tim -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur

Re: Bash-4.3-beta2 available for FTP

t other people stumble >> over that build issue, please? > > I pushed another snapshot this morning. Thank you. Seems to work fine :) Ced -- Cedric Blancher Institute Pasteur

Re: [PATCH] bash: add socket server support

l(1) implementation) which can be used to wait both on the accept socket and the sockets returned by accept. If the accept sockets returns an event you could use something like /dev/tcpserver/nextaccept to open to obtain the next socket returned by accept(), and store the accept() data in an env variable. Ced -- Cedric Blancher Institute Pasteur

Re: [PATCH] bash: add socket server support

x27; or 'root' in Solaris zones is not completely omnipotent. Ced -- Cedric Blancher Institute Pasteur

Re: Bash-4.3-beta2 available for FTP

oes not build. Is that a known problem? >> >> Yes. There are a few issues with the bash-20131025 snapshot. I've >> attached a patch that fixes them. > > Chet, can you push the patch to git to avoid that other people stumble > over that build issue, please? Yes, IMHO this would be a good idea. I just hit exactly that problem, again. Ced -- Cedric Blancher Institute Pasteur

Re: Bash-4.3-beta2 available for FTP

atch uses O_XATTR. > > Mhhh. > That would be very useful to have, at least much better than the > cranky runat(1) kludge. > > Is there a branch I can checkout to try? Not yet, Chet is updating the git only twice a month or so. Please be patient and don't pester him too much. Ced -- Cedric Blancher Institute Pasteur

Re: Bash-4.3-beta2 available for FTP

een this version, bash-4.3-beta2, and > the > previous version, bash-4.3-beta. What happened to the patch for cd -@ to handle NFSv4+Windows alternate streams? ksh93 already has this feature since quite some time and they're now even extending support even further to the builtin POSIX commands... Ced -- Cedric Blancher Institute Pasteur

Re: bash kill(1) doesn't report errors when $(ulimit -i) is exceeded

detect, and even harder to come by). Question in this case is, should bash switch over to use sigqueue(), or should kill(2) be fixed to return an error? Given that the silent mode of failure which can wreak havoc, I'd opt for BOTH. Ced -- Cedric Blancher Institute Pasteur

Re: Check out my profile on LinkedIn

gt; -- > You are receiving Invitation to Connect emails. Click to unsubscribe: > http://www.linkedin.com/e/-usqo9b-hj5tdyem-6t/kprwqZgDdgAtGd22_-d8-W3hN3R/goo/bug-bash%40gnu%2Eorg/20061/I4992179370_1/?hs=false&tok=0x4QjYYdePpBQ1 > > (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. > > > -- Cedric Blancher Institute Pasteur

Fwd: bash kill(1) doesn't report errors when $(ulimit -i) is exceeded

Trying to repost because the list didn't pass the bug report through yet. Ced -- Forwarded message -- From: Cedric Blancher Date: 14 July 2013 20:38 Subject: bash kill(1) doesn't report errors when $(ulimit -i) is exceeded To: bug-bash@gnu.org The tests below i

bash kill(1) doesn't report errors when $(ulimit -i) is exceeded

) because no further signals can be queued to $pid because ulimit -i is exceeded for that child process. Bash version is GNU bash, version 4.2.42(1)-release (x86_64-suse-linux-gnu) on Suse 12.3, 64bit Ced -- Cedric Blancher Institute Pasteur