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 loc
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 tho
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 t
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 2
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 and
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -
On Mon, Mar 20, 2017 at 12:17:39PM -0300, Noilson Caio wrote:
> 1 - Using mkdir -p {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/ - ( 5 levels ) No
> problems
10 to the 5th power (100,000) strings generated. Sloppy, but viable on
today's computers. You're relying on your operating system to allow
an extrao
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' -DCONF_MACHTYPE='x86_64-redhat
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 conformance
> issue.
As POSIX has not yet specif
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 conf
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 because 10^6 strings pull the trigger of "Argument list too
long" and
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
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
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 problem with
> your
> > a
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.
> >>
> >>
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";}; a=
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' -DLOCALEDIR='/usr/share/loca
This was reported a month ago:
http://lists.gnu.org/archive/html/bug-bash/2017-02/msg00025.html
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
[...]
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 late
20 matches
Mail list logo
