LC_ALL=C foo, where foo is a shell function

LC_ALL=C foo, where foo is a shell function

[Vincent Lefevre]

If I type

  foo() { some_command }
  LC_ALL=C foo

then this sets LC_ALL to C in the current shell, probably because foo
is evaluated in the current shell. I wonder whether this is wanted or
this is a bug. The zsh FAQ says in "Why do my csh aliases not work?":

  Otherwise, your aliases probably contain references to the command
  line of the form `\!*', etc. Zsh does not handle this behaviour as
  it has shell functions which provide a way of solving this problem
  more consistent with other forms of argument handling.

This is not a good advice due to the possible side effects (unless
the above behavior is really a bug, but bash behaves in the same way
as zsh). The FAQ should be updated to point out this problem.

Shouldn't the form with parameter assignments be disavised (except
in the cases where this has the wanted effect) in favor of the env
command?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: LC_ALL=C foo, where foo is a shell function

[Bart Schaefer]

On Jul 9,  9:14pm, Vincent Lefevre wrote:
}
} If I type
} 
}   foo() { some_command }
}   LC_ALL=C foo
} 
} then this sets LC_ALL to C in the current shell, probably because foo
} is evaluated in the current shell.

Doesn't happen to me:

schaefer<501> foo() { echo $LC_ALL }
schaefer<502> LC_ALL=C foo
C
schaefer<503> echo $LC_ALL

schaefer<504> foo() { /bin/echo $LC_ALL }
schaefer<505> LC_ALL=C foo               
C
schaefer<506> echo $LC_ALL

schaefer<507> 


What version of zsh are you testing?

Re: LC_ALL=C foo, where foo is a shell function

[Vincent Lefevre]

On 2005-07-09 20:44:33 +0000, Bart Schaefer wrote:
> Doesn't happen to me:
[snip]

Well, I don't know what happens, this is really strange.

ay:~> locale
LANG=POSIX
LC_CTYPE=en_US.ISO8859-1
LC_NUMERIC="POSIX"
LC_TIME=en_DK
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
ay:~> foo() { echo $LC_ALL }
ay:~> LC_ALL=C foo
C
ay:~> echo $LC_ALL

ay:~> locale
LANG=POSIX
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
ay:~> env | grep LC_ALL
LC_ALL=C

Any explanation?

> What version of zsh are you testing?

4.2.5 from Debian (Debian package zsh 4.2.5-7).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: LC_ALL=C foo, where foo is a shell function

[Vincent Lefevre]

On 2005-07-10 02:04:36 +0200, Vincent Lefevre wrote:
> ay:~> env | grep LC_ALL
> LC_ALL=C

Moreover:

ay:~> set | grep LC_ALL
zsh: done       set | 
zsh: exit 1     grep LC_ALL

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: LC_ALL=C foo, where foo is a shell function

[Bart Schaefer]

On Jul 10,  2:04am, Vincent Lefevre wrote:
} Subject: Re: LC_ALL=C foo, where foo is a shell function
}
} On 2005-07-09 20:44:33 +0000, Bart Schaefer wrote:
} > Doesn't happen to me:
} [snip]
} 
} Well, I don't know what happens, this is really strange.
} 
} 4.2.5 from Debian (Debian package zsh 4.2.5-7).

Ah.  I tried it with the latest -dev version, compiled out of my CVS
sandbox.

If I try with 4.2.5, I get the same results as you.

I just noticed that, even in the latest build, if LC_ALL starts out set
(even to nothing), but not exported, then when "LC_ALL=C foo" is run
LC_ALL becomes and remains exported, even though its value gets reset
to the previous state.

I don't know what differs between 4.2.5 and the latest CVS that would
affect this.

Re: LC_ALL=C foo, where foo is a shell function

[Clint Adams]

On Sun, Jul 10, 2005 at 12:57:47AM +0000, Bart Schaefer wrote:
> Ah.  I tried it with the latest -dev version, compiled out of my CVS
> sandbox.
> 
> If I try with 4.2.5, I get the same results as you.
> 
> I just noticed that, even in the latest build, if LC_ALL starts out set
> (even to nothing), but not exported, then when "LC_ALL=C foo" is run
> LC_ALL becomes and remains exported, even though its value gets reset
> to the previous state.
> 
> I don't know what differs between 4.2.5 and the latest CVS that would
> affect this.

I'm think seeing the same behavior in current CVS.

Re: LC_ALL=C foo, where foo is a shell function

[Bart Schaefer]

On Apr 14,  3:38pm, Clint Adams wrote:
}
} On Sun, Jul 10, 2005 at 12:57:47AM +0000, Bart Schaefer wrote:
} > I just noticed

Nearly two years ago.  Phrases like "just now" certainly take on a
different flavor in the face of permanent archival ...

} > that, even in the latest build, if LC_ALL starts out set
} > (even to nothing), but not exported, then when "LC_ALL=C foo" is run
} > LC_ALL becomes and remains exported, even though its value gets reset
} > to the previous state.
} 
} I'm think seeing the same behavior in current CVS.

I'm not able to reproduce it with the latest CVS on my RHEL4 machine, or
at least I can't do so with the most straightforward interpretation of
"LC_ALL starts out set".

If it is happening, it has to be related to this (params.c):

    void
    lc_allsetfn(Param pm, char *x)
    {
	strsetfn(pm, x);
	if (!x) {
	    queue_signals();
	    setlang(getsparam("LANG"));
	    unqueue_signals();
	}
	else
	    setlocale(LC_ALL, x);
    }

Re: LC_ALL=C foo, where foo is a shell function

[Peter Stephenson]

On Sun, Jul 10, 2005 at 12:57:47AM +0000, Bart Schaefer wrote:
> I just noticed that, even in the latest build, if LC_ALL starts out set
> (even to nothing), but not exported, then when "LC_ALL=C foo" is run
> LC_ALL becomes and remains exported, even though its value gets reset
> to the previous state.

There are two completely separate parts of the shell that restore
parameters.  There is one I wrote for function scope, and there is a second
one that someone else wrote without taking any notice of the first one that
restores parameters in this case.  (Good job I never get bitter, eh?)  This
second one doesn't take account of restoring a special parameter when the
local value is exported and the old value isn't.  For specials there is
always an entry in the table, so this applies even if LC_ALL isn't actually
set.

It should just be a case of removing stuff from the environment if we know
it shouldn't be there.  I can't see any cases when this would be wrong,
anyway.  (There are POSIX exceptions, which I don't think cover LC_ALL
anyway, where the value is preserved after the function call, but none that
would force an export to be inconsistent with the local value.)

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.128
diff -u -r1.128 exec.c
--- Src/exec.c	9 Dec 2007 23:53:33 -0000	1.128
+++ Src/exec.c	21 Feb 2008 18:14:41 -0000
@@ -3113,6 +3113,8 @@
 		DPUTS(!tpm || PM_TYPE(pm->node.flags) != PM_TYPE(tpm->node.flags) ||
 		      !(pm->node.flags & PM_SPECIAL),
 		      "BUG: in restoring special parameters");
+		if (!pm->env && tpm->env)
+		    delenv(tpm);
 		tpm->node.flags = pm->node.flags;
 		switch (PM_TYPE(pm->node.flags)) {
 		case PM_SCALAR:


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070