Zsh Mailing List Archive
Messages sorted by:
Re: unset IFS - zsh: segmentation fault (core dumped) zsh
- X-seq: zsh-users 14143
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: unset IFS - zsh: segmentation fault (core dumped) zsh
- Date: Tue, 19 May 2009 12:39:26 +0100
- In-reply-to: <20090519110848.12650.qmail@xxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20090518113402.12840.qmail@xxxxxxxxxxx> <20090518125753.1931c23d@news01> <20090519110848.12650.qmail@xxxxxxxxxxx>
Atom Smasher wrote:
> On Mon, 18 May 2009, Peter Stephenson wrote:
> >> if i unset IFS i get:
> >> zsh: segmentation fault (core dumped) zsh
> > This is a bug: can you work out what it was doing when that happened?
> edge case. apparently it's the '(e)' in this line from my zshrc that's
> causing the trouble:
Unfortunately, we don't know what's in $PR_STUFF[FILLBAR], and other
forms don't crash, so this doesn't help.
I can see cases in the code where we don't test whether the internal
variable ifs is NULL, however. This is bad as unsetting IFS sets ifs to
NULL. So that needs fixing and may well fix your problem.
> i'm not sure if this is a priority bug, but i still think that unsetting
> IFS should cause it to return to its default, rather than setting it to
There's nothing special about \n, but since IFS unset isn't always properly
handled it could do anything.
We already treat IFS being NULL as the default in at least one place.
Either we need to do that globally, or we need to do treat it as IFS
being the empty string globally. It's not really clear to me what the
empty string actually means, so I think the default is probably better.
If we treat it as the default, which is what the following does, it
should probably be noted in the documentation.
Ah... actually, POSIX mandates this behaviour...
(Input Field Separators.) A string treated as a list of characters that
is used for field splitting and to split lines into fields with the read
command. If IFS is not set, the shell shall behave as if the value of
IFS is <space>, <tab>, and <newline>; see Field
Splitting. Implementations may ignore the value of IFS in the
environment at the time the shell is invoked, treating IFS as if it were
... except we include \0 as well as the three characters mentioned;
does anyone care?
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
retrieving revision 1.55
diff -u -r1.55 params.yo
--- Doc/Zsh/params.yo 17 May 2009 18:23:10 -0000 1.55
+++ Doc/Zsh/params.yo 19 May 2009 11:25:20 -0000
@@ -893,6 +893,9 @@
a field. If an IFS white space character appears twice consecutively
in the IFS, this character is treated as if it were not an IFS white
+If the parameter is unset, the default is used. Note this has
+a different effect from setting the parameter to an empty string.
RCS file: /cvsroot/zsh/zsh/Src/subst.c,v
retrieving revision 1.97
diff -u -r1.97 subst.c
--- Src/subst.c 23 Mar 2009 12:17:33 -0000 1.97
+++ Src/subst.c 19 May 2009 11:25:21 -0000
@@ -714,8 +714,8 @@
- if (*ifs)
- def = dupstrpfx(ifs, MB_METACHARLEN(ifs));
+ if (!ifs || *ifs)
+ def = dupstrpfx(ifs ? ifs : DEFAULT_IFS, MB_METACHARLEN(ifs));
def = "";
if (preone && !*preone)
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.223
diff -u -r1.223 utils.c
--- Src/utils.c 19 May 2009 08:41:17 -0000 1.223
+++ Src/utils.c 19 May 2009 11:25:21 -0000
@@ -3162,7 +3162,7 @@
- set_widearray(ifs, &ifs_wide);
+ set_widearray(ifs ? ifs : DEFAULT_IFS, &ifs_wide);
for (s = SPECCHARS; *s; s++)
typtab[STOUC(*s)] |= ISPECIAL;
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
Messages sorted by: