* LC_ALL=C foo, where foo is a shell function @ 2005-07-09 19:14 Vincent Lefevre 2005-07-09 20:44 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Vincent Lefevre @ 2005-07-09 19:14 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: LC_ALL=C foo, where foo is a shell function 2005-07-09 19:14 LC_ALL=C foo, where foo is a shell function Vincent Lefevre @ 2005-07-09 20:44 ` Bart Schaefer 2005-07-10 0:04 ` Vincent Lefevre 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2005-07-09 20:44 UTC (permalink / raw) To: zsh-users 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: LC_ALL=C foo, where foo is a shell function 2005-07-09 20:44 ` Bart Schaefer @ 2005-07-10 0:04 ` Vincent Lefevre 2005-07-10 0:13 ` Vincent Lefevre 2005-07-10 0:57 ` Bart Schaefer 0 siblings, 2 replies; 8+ messages in thread From: Vincent Lefevre @ 2005-07-10 0:04 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: LC_ALL=C foo, where foo is a shell function 2005-07-10 0:04 ` Vincent Lefevre @ 2005-07-10 0:13 ` Vincent Lefevre 2005-07-10 0:57 ` Bart Schaefer 1 sibling, 0 replies; 8+ messages in thread From: Vincent Lefevre @ 2005-07-10 0:13 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: LC_ALL=C foo, where foo is a shell function 2005-07-10 0:04 ` Vincent Lefevre 2005-07-10 0:13 ` Vincent Lefevre @ 2005-07-10 0:57 ` Bart Schaefer 2007-04-14 19:38 ` Clint Adams 1 sibling, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2005-07-10 0:57 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: LC_ALL=C foo, where foo is a shell function 2005-07-10 0:57 ` Bart Schaefer @ 2007-04-14 19:38 ` Clint Adams 2007-04-14 20:18 ` Bart Schaefer 2008-02-21 18:21 ` Peter Stephenson 0 siblings, 2 replies; 8+ messages in thread From: Clint Adams @ 2007-04-14 19:38 UTC (permalink / raw) To: zsh-users; +Cc: 317773 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: LC_ALL=C foo, where foo is a shell function 2007-04-14 19:38 ` Clint Adams @ 2007-04-14 20:18 ` Bart Schaefer 2008-02-21 18:21 ` Peter Stephenson 1 sibling, 0 replies; 8+ messages in thread From: Bart Schaefer @ 2007-04-14 20:18 UTC (permalink / raw) To: Clint Adams, zsh-users; +Cc: 317773 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); } ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: LC_ALL=C foo, where foo is a shell function 2007-04-14 19:38 ` Clint Adams 2007-04-14 20:18 ` Bart Schaefer @ 2008-02-21 18:21 ` Peter Stephenson 1 sibling, 0 replies; 8+ messages in thread From: Peter Stephenson @ 2008-02-21 18:21 UTC (permalink / raw) Cc: zsh-users, 317773 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-02-21 18:24 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-09 19:14 LC_ALL=C foo, where foo is a shell function Vincent Lefevre 2005-07-09 20:44 ` Bart Schaefer 2005-07-10 0:04 ` Vincent Lefevre 2005-07-10 0:13 ` Vincent Lefevre 2005-07-10 0:57 ` Bart Schaefer 2007-04-14 19:38 ` Clint Adams 2007-04-14 20:18 ` Bart Schaefer 2008-02-21 18:21 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).