Re: Issue with Bash

On 7/31/20 7:27 PM, Ángel wrote: > On 2020-07-31 at 10:13 -0400, Chet Ramey wrote: >> >> I'm going to have to test some more. When I tried it, all the shells >> died. >> (I did send the SIGHUP from another terminal.) I was using ksh93 as >> the parent and bash-5.0.18 as the interactive bash, runnin

Re: Issue with Bash

On 7/31/20 10:04 AM, Ayappan P2 wrote: > We are passing SIGHUP from another terminal ( not from the terminal which > has the interactive bash shell) . The terminal which has the interactive > bash closes immediately. > > The scenario is we just open two terminals. In one terminal , just invoke > b

Re: Issue with Bash

On 2020-07-31 at 10:13 -0400, Chet Ramey wrote: > > I'm going to have to test some more. When I tried it, all the shells > died. > (I did send the SIGHUP from another terminal.) I was using ksh93 as > the parent and bash-5.0.18 as the interactive bash, running on macOS. This is probably AIX-speci

Re: Issue with Bash

On 7/31/20 10:04 AM, Ayappan P2 wrote: > We are passing SIGHUP from another terminal ( not from the terminal which > has the interactive bash shell) . The terminal which has the interactive > bash closes immediately. > > The scenario is we just open two terminals. In one terminal , just invoke > b

RE: Issue with Bash

the parent process (ksh) of bash. Thanks Ayappan P From: Chet Ramey To: Rishita Saha16 Cc: bug-bash@gnu.org, chet.ra...@case.edu Date: 31-07-2020 19:05 Subject:[EXTERNAL] Re: Issue with Bash Sent by:"bug-bash" On 7/31/20 3:25 AM, Rishita Saha16 wrote

Re: Issue with Bash

On 7/31/20 3:25 AM, Rishita Saha16 wrote: > Hi All, >   > We have been able to recreate a scenario where bash dumps core immediately > on issuing a SIGHUP to the parent process (kill -1 ). On > debugging, the core so generated shows exactly the same stack trace as we > had seen with the previous co

RE: Issue with Bash

] Re: Issue with Bash Date: Mon, Jul 20, 2020 6:29 PM On 7/20/20 2:32 AM, Rishita Saha16 wrote: > Hi All, > > From what we have found out, it does not seem like the signal is SIGTTOU. > We are working to find out more about it. Meanwhile, any insight would be

Re: Issue with Bash

On 7/20/20 2:32 AM, Rishita Saha16 wrote: > Hi All, >   > From what we have found out, it does not seem like the signal is SIGTTOU. > We are working to find out more about it. Meanwhile, any insight would be > helpful. If the process isn't an interactive shell, it would be helpful to know why it's

RE: Issue with Bash

HIGOT, CLEMENT" , Rishita Saha16 , "bug-bash@gnu.org" Cc: chet.ra...@case.edu Subject: [EXTERNAL] Re: Issue with Bash Date: Thu, Jul 9, 2020 8:01 PM On 7/9/20 10:16 AM, CHIGOT, CLEMENT wrote: > Hi Rishita, > > Could you try with BullFreeware

Re: Issue with Bash

riday, July 10, 2020 1:40 PM To: CHIGOT, CLEMENT Cc: bug-bash@gnu.org Subject: RE: Issue with Bash Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. Hi Clement, We have given it a try after applyin

RE: Issue with Bash

Cc: Subject: [EXTERNAL] Re: Issue with Bash Date: Thu, Jul 9, 2020 7:46 PM Hi Rishita, Could you try with BullFreeware's version, which have a slightly higher version (5.0.11 instead of 5.0) ? You can find it at [1]http://www.bullfreeware.com/pkg?id=5740. If it&

Re: Issue with Bash

On 7/9/20 10:16 AM, CHIGOT, CLEMENT wrote: > Hi Rishita, > > Could you try with BullFreeware's version, which have a slightly higher > version (5.0.11 instead of 5.0) ? > You can find it at > http://www.bullfreeware.com/pkg?id=5740. > > If it's not worki

Re: Issue with Bash

hat's wrong. Clément From: bug-bash on behalf of Rishita Saha16 Sent: Thursday, July 9, 2020 11:17 AM To: bug-bash@gnu.org Subject: Issue with Bash Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the c

Re: Issue with Bash

On 7/9/20 5:17 AM, Rishita Saha16 wrote: >Hi All, > >We are using Bash 5.0 (64bit built using gcc ) in AIX 7.2 machine .This >is the spec file for reference --> >[1]https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/SPECS/bash-5. >0-1.spec. >We are seeing recurring bash

Issue with Bash

Hi All, We are using Bash 5.0 (64bit built using gcc ) in AIX 7.2 machine .This is the spec file for reference --> [1]https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/SPECS/bash-5. 0-1.spec. We are seeing recurring bash core dumps on our servers. Leaving bash sessions ru

Re: Bash: sleep execution issue with bash loadable builtins

On 2017-12-04 at 16:38 +0530, Thiruvadi Rajaraman wrote: > Hi Chester, > > Based on your review comments and suggestions about the earlier fixes, > reworked on the fix with pselect() > to block the signal. > Blocked the SIGCHLD signal using sigprocmask(). > > Attached the reworked fix patch for y

Re: Bash: sleep execution issue with bash loadable builtins

On Mon, Dec 4, 2017 at 5:08 AM, Thiruvadi Rajaraman wrote: > Hi Chester, > > Based on your review comments and suggestions about the earlier fixes, > reworked on the fix with pselect() > to block the signal. FYI, Chet pushed a few changes related to this in commits 564452a3ec9b73a53949325cc4acb9

Re: Bash: sleep execution issue with bash loadable builtins

Hi Chester, Based on your review comments and suggestions about the earlier fixes, reworked on the fix with pselect() to block the signal. Blocked the SIGCHLD signal using sigprocmask(). Attached the reworked fix patch for your kind reference. Please kindly review the patch and suggest your comm

Re: Bash: sleep execution issue with bash loadable builtins

On 12/1/17 7:49 AM, Thiruvadi Rajaraman wrote: > Hi Chester, > > Thanks a lot for your review comments. > > I reworked on the fix to solve bash sleep issue and here attached the patch. I don't think you got my point. Why would you override bash's installed signal handler -- disabling job and pr

Re: Bash: sleep execution issue with bash loadable builtins

Hi Chester, Thanks a lot for your review comments. I reworked on the fix to solve bash sleep issue and here attached the patch. >From include/bits/signum.h, #define SIG_DFL ((__sighandler_t) 0)/* Default action. */ In the attached patch fix, signal(SIGCHLD, SIG_DFL), SIG_DFL perfo

Re: Bash: sleep execution issue with bash loadable builtins

On 11/28/17 9:41 AM, Chet Ramey wrote: > On 11/27/17 2:47 PM, Ángel wrote: > >> Also there's the issue that select() _may_ modify the object pointed to >> by the timeout argument [POSIX]. But it may not, in which case this >> would end up oversleeping. >> >> On such system, doing eg. >> sleep 9 &

Re: Bash: sleep execution issue with bash loadable builtins

On 11/27/17 2:47 PM, Ángel wrote: > Also there's the issue that select() _may_ modify the object pointed to > by the timeout argument [POSIX]. But it may not, in which case this > would end up oversleeping. > > On such system, doing eg. > sleep 9 & time sleep 10 > > would end up sleeping 19 sec

Re: Bash: sleep execution issue with bash loadable builtins

On 11/28/17 12:17 AM, Thiruvadi Rajaraman wrote: > Hi, > > Thanks a lot for your review comments. > > I have reworked on the bash sleep fix based on your suggestion about signal > and trap handling in fsleep( ). > > I have attached the fix patch for your kind reference. Your patch unconditional

Re: Bash: sleep execution issue with bash loadable builtins

man wrote: > > Hi, > > > > Found a 'sleep' execution issue with bash loadable builtins and has > > performed > > the below sleep test on bash-4.4-rc1. > > That's an interesting one. It looks like the SIGCHLD interrupts the select > loop, even though bash su

Re: Bash: sleep execution issue with bash loadable builtins

On 2017-11-27 at 17:47 +0530, Thiruvadi Rajaraman wrote: > Reproducible test case and Console logs: > Simpler test case: bash-4.4-rc1# cd examples/loadables/ bash-4.4-rc1/examples/loadables# enable -f ./sleep sleep bash-4.4-rc1/examples/loadables# sleep 1 &

Re: Bash: sleep execution issue with bash loadable builtins

On 11/27/17 4:17 AM, Thiruvadi Rajaraman wrote: > Hi, > > Found a 'sleep' execution issue with bash loadable builtins and has > performed > the below sleep test on bash-4.4-rc1. That's an interesting one. It looks like the SIGCHLD interrupts the select loop, even t

Bash: sleep execution issue with bash loadable builtins

Hi, Found a 'sleep' execution issue with bash loadable builtins and has performed the below sleep test on bash-4.4-rc1. Bash version: 4.4-rc1 Web link: https://ftp.gnu.org/gnu/bash/bash-4.4-rc1.tar.gz Reproducible test case and Console logs:

Re: Issue with Bash-4.3 Official Patch 27

On 10/17/14, 11:34 AM, Greg Wooledge wrote: > 3) Everything else. These are ignored. > Not quite. Bash saves them and adds them to the environment it passes to the external commands it invokes. Bash is transparent with respect to environment variables it doesn't handle. Chet -- ``The lyf so

Re: Issue with Bash-4.3 Official Patch 27

On 10/17/14, 11:22 AM, lorenz.bucher@rohde-schwarz.com wrote: > No, I can't. > $ foo%%="bar" > foo%%=bar: command not found You just demonstrated what I wrote: > No, shell variable names should continue to be shell identifiers. You > can already use `%' (any character, really) in environmen

Re: Issue with Bash-4.3 Official Patch 27

On 10/16/14, 4:37 PM, Geir Hauge wrote: > Regardless though, shouldn't source <(declare -xp) work whether or not > the environment contains invalid identifiers? It doesn't at present: > > $ env %=% bash -c 'echo "$BASH_VERSION"; source <(declare -xp)' > 4.3.30(1)-release > /dev/fd/63: line 1: dec

Re: Issue with Bash-4.3 Official Patch 27

> Von:Chet Ramey > No, shell variable names should continue to be shell identifiers. You > can already use `%' (any character, really) in environment variable > names. On Fri, Oct 17, 2014 at 05:22:30PM +0200, lorenz.bucher@rohde-schwarz.com wrote: > No, I can't. > $ foo%%="bar" > foo%

Re: Issue with Bash-4.3 Official Patch 27

chet.ra...@case.edu Datum: 10/16/2014 03:09 PM Betreff:Re: Issue with Bash-4.3 Official Patch 27 Gesendet von: bug-bash-bounces+lorenz.bucher.ext=rohde-schwarz@gnu.org On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: > But anyway. > In my opinion I should trus

Re: Issue with Bash-4.3 Official Patch 27

2014-10-16 15:09 GMT+02:00 Chet Ramey : > On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: > > > But anyway. > > In my opinion I should trust a shell not violating their own rules and be > > able to import their own variables. > > That's not the issue. The shell can import variabl

Re: Issue with Bash-4.3 Official Patch 27

On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: > But anyway. > In my opinion I should trust a shell not violating their own rules and be > able to import their own variables. That's not the issue. The shell can import variables like that just fine, as evidenced by exported fun

Re: Issue with Bash-4.3 Official Patch 27

On 10/15/14, 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote: > Hello, > in refer to > http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables > with suffix "%%" can't be set/exported. > This makes problems restoring environments which where saved by external > programs lik

Re: Issue with Bash-4.3 Official Patch 27

On 10/15/2014 11:49 AM, lorenz.bucher@rohde-schwarz.com wrote: > Yes, you got it. I just gave an example to reproduce that Bug. In my case > I didn't find the save script/binary yet. > I use unset -f function as workaround. > > But anyway. > In my opinion I should trust a shell not violatin

Re: Issue with Bash-4.3 Official Patch 27

o the % character should be allowed to be used in variable names. Von:Greg Wooledge An: Eduardo A. Bustamante López , Kopie: lorenz.bucher@rohde-schwarz.com, bug-bash@gnu.org Datum: 10/15/2014 05:58 PM Betreff: Re: Issue with Bash-4.3 Official Patch 27 On Wed, Oct 15, 2014 at

Re: Issue with Bash-4.3 Official Patch 27

On Oct 15, 2014, at 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote: > Hello, > in refer to > http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables > with suffix "%%" can't be set/exported. > This makes problems restoring environments which where saved by external > prog

Re: Issue with Bash-4.3 Official Patch 27

On Wed, Oct 15, 2014 at 08:50:25AM -0700, Eduardo A. Bustamante López wrote: > On Wed, Oct 15, 2014 at 03:38:01PM +0200, lorenz.bucher@rohde-schwarz.com > wrote: > > variables with suffix "%%" can't be set/exported. > > This makes problems restoring environments which where saved by external

Re: Issue with Bash-4.3 Official Patch 27

On Wed, Oct 15, 2014 at 03:38:01PM +0200, lorenz.bucher@rohde-schwarz.com wrote: > Hello, > in refer to > http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables > with suffix "%%" can't be set/exported. > This makes problems restoring environments which where saved by ext

Issue with Bash-4.3 Official Patch 27

Hello, in refer to http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables with suffix "%%" can't be set/exported. This makes problems restoring environments which where saved by external programs like printenv (see example below) I saw this issue on Ubuntu 12.04 with bash ve