Re: lockup in bgp_delete()

2017-03-20 Thread Chet Ramey
On 3/20/17 6:29 PM, Eduardo Bustamante wrote: > This was reported a month ago: > http://lists.gnu.org/archive/html/bug-bash/2017-02/msg00025.html The devel git branch on savannah has several fixes for this. If you don't want to run that on a server, you can just snag the jobs.c file from the

arithmetic syntax error loop after declaration of exported integer variable

2017-03-20 Thread D630
I get an infinite error loop in B, and I suppose that's not because of my settings. # A bash$ unset -v foo; declare -i foo; foo='bar bar' bash: bar bar: syntax error in expression (error token is "bar") # B bash$ unset -v foo; foo='bar bar' declare -x -i foo [...]

Re: lockup in bgp_delete()

2017-03-20 Thread Eduardo Bustamante
This was reported a month ago: http://lists.gnu.org/archive/html/bug-bash/2017-02/msg00025.html

lockup in bgp_delete()

2017-03-20 Thread Luke Shumaker
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown'

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 Thread Chet Ramey
On 3/20/17 4:29 PM, Stephane Chazelas wrote: >> I believe he means the behavior of `a=0; a=1 eval unset a', which Posix >> implicitly requires affect the global scope and results in a being unset >> when the statement completes. > [...] > > See also: > > $ bash -c 'f() { unset a; echo "$a";};

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 Thread Stephane Chazelas
2017-03-20 14:47:17 -0400, Chet Ramey: > On 3/20/17 2:30 PM, Eric Blake wrote: > > On 03/17/2017 07:21 PM, Stephane Chazelas wrote: > > > >>> The problem is the non-obvious nature of unset's interaction with scope, > >> > >> the main problem to me is an unset command that doesn't unset. > >> > >>

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Noilson Caio
thank you On Mon, Mar 20, 2017 at 4:03 PM, Greg Wooledge wrote: > On Mon, Mar 20, 2017 at 03:54:37PM -0300, Noilson Caio wrote: > > thank you so much Mr. Wooledge. i guess that BUG is a strong word for > this > > case. i fully agree about "his is not a bash bug. It's a

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Greg Wooledge
On Mon, Mar 20, 2017 at 03:54:37PM -0300, Noilson Caio wrote: > thank you so much Mr. Wooledge. i guess that BUG is a strong word for this > case. i fully agree about "his is not a bash bug. It's a problem with your > approach.", actuality that's my preoccupation. can you help me to > understand

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread Chet Ramey
On 3/20/17 2:54 PM, Noilson Caio wrote: > i have afraid that a non-root user can > compromise a linux box intentionally. the memory needs be eaten until other > threshold can break it. This is why per-process resource limits exist. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 Thread Chet Ramey
On 3/20/17 2:30 PM, Eric Blake wrote: > On 03/17/2017 07:21 PM, Stephane Chazelas wrote: > >>> The problem is the non-obvious nature of unset's interaction with scope, >> >> the main problem to me is an unset command that doesn't unset. >> >> As shown in my original post, there's also a POSIX

Re: Bash monopolizing or eating the RAM MEMORY

2017-03-20 Thread John McKown
On Mon, Mar 20, 2017 at 10:17 AM, Noilson Caio wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu'

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 Thread 渡邊裕貴
It seems to me this matter is specific to the IFS variable (and possibly few others like CDPATH). Unsetting IFS restores the default field splitting behavior, but unsetting PATH does not restore the default command search path. As Peter suggests, you can locally re-define any variables you want

Re: Odd LINENO behaviour in 'eval'

2017-03-20 Thread Chet Ramey
On 3/19/17 10:58 PM, Martijn Dekker wrote: > Test script: > printf "$LINENO " > printf "$LINENO " > eval 'printf "$LINENO " > printf "$LINENO " > printf "$LINENO " ' > printf "$LINENO\n" > > Output on various shells: > bash: 1 2 5 6 7 6 (?!) > {m,l,pd}ksh: 1

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 Thread Stephane Chazelas
2017-03-20 08:04:33 -0400, Greg Wooledge: [...] > > Credits to Dan Douglas > > (https://www.mail-archive.com/miros-mksh@mirbsd.org/msg00707.html) > > for finding the bug. He did find a use for it though (get the > > value of a variable from the caller's scope). > > Isn't this exactly the same as

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 Thread Greg Wooledge
On Fri, Mar 17, 2017 at 09:51:34PM +, Stephane Chazelas wrote: > Then, the "unset", instead of unsetting IFS, actually pops a > layer off the stack. > Credits to Dan Douglas > (https://www.mail-archive.com/miros-mksh@mirbsd.org/msg00707.html) > for finding the bug. He did find a use for it

Re: "unset var" pops var off variable stack instead of unsetting it

2017-03-20 Thread Stephane Chazelas
2017-03-20 12:30:09 +0900, 渡邊裕貴: > It seems to me this matter is specific to the IFS variable (and possibly > few others like CDPATH). Unsetting IFS restores the default field splitting > behavior, but unsetting PATH does not restore the default command search > path. As Peter suggests, you can