> If you are using whatver `close' button your window manager provides to
> exit the shell rather than exit or ^D, it's possible that there is a signal
> race condition involved here. Many window managers send SIGHUP/SIGKILL to
> running processes on window close.
That's pretty much what happens.
Greg Wooledge writes:
> Do you mean variable expansions?
No, I mean what I write.
> Here's the code in question, simplified even further:
>
> imadev:~$ unset IFS
> imadev:~$ foo=a/b/c
> imadev:~$ cat < <(echo $foo)
> a/b/c
> imadev:~$ IFS=/ cat < <(echo $foo)
> a b c
>
> Clearly the IFS assignm
On Fri, Jul 26, 2013 at 10:38:46PM +0200, Andreas Schwab wrote:
> Greg Wooledge writes:
>
> > Your unquoted $instring is being split into fields by bash, which is
> > operating with IFS=: at that point.
>
> Variable assignments are supposed to be performed _after_ redirections
> (read is not a s
Greg Wooledge writes:
> Your unquoted $instring is being split into fields by bash, which is
> operating with IFS=: at that point.
Variable assignments are supposed to be performed _after_ redirections
(read is not a special built-in).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On Sat, Jul 27, 2013 at 01:34:53AM +0900, David H. wrote:
> # The test string:
> $ echo $instring
> root:x:0:0:root:/root:/bin/bash
>
> # Gives incorrect (unexpected) output:
> $ ( IFS=: read -a strings < <( echo $instring ) ; printf '[%s]\n'
> "${strings[@]}" )
> [root x 0
From: David H.
To: bug-bash@gnu.org,b...@packages.debian.org
Subject: read builtin. input processes improperly inheriting IFS setting
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE=
On 7/24/13 2:53 AM, Geoff Kuenning wrote:
> I have to confess that I'm equally confused. The probability of a
> malloc failure seems vanishingly small; my bashes are only about 20M
> virtual, my history size is a measly 500, and my current history is just
> over 8K..
>
> I can't think of an inte
Geoff Kuenning wrote:
Instead of "junk", secure file systems mark it as needing to be
zeroed. Perhaps instead of zeroing it ext3 simply marks it of zero
length? Imagine, embedded in the junk are credit cards and passwords
and you'll begin to understand why zero pages are kept "in-stoc
