Hello,
Currently (thanks to someone asking a question on IRC) I realised that
FVWM was allowing environment variable names with fullstops ('.') in
them. I don't believe FVWM should allow this.
Currently it's not a problem if one is onlt ever intending for a
variable to be used via SetEnv solely within FVWM; FVWM of course just
exports and reads from its own environment space without ever parsing
via the shell.
Of course, when one tries to do:
SetEnv FOO.VAR hello
... and then:
echo $FOO.VAR
Via a subsequently spawned xterm or whatever, then it will obviously
fail. The patch attached with this email, patches flib_putenv() in
libs/envvar.c using strstr() to see if the env var name contains a '.'
or not (I have no idea just how portable strstr() is but it's a tad
faster than having to iterate over a character array).
I haven't bothered updating the fvwm.1.in in lieu of this, given that
the description doesn't mention this in the first place. By all means
do so if it's felt necessary.
-- Thomas Adam
--
"Wanting to feel; to know what is real. Living is a lie." -- Purpoise
Song, by The Monkees.
Index: ./libs/envvar.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/libs/envvar.c,v
retrieving revision 1.18
diff -u -r1.18 envvar.c
--- ./libs/envvar.c 26 Nov 2005 21:55:12 -0000 1.18
+++ ./libs/envvar.c 27 Feb 2007 01:20:44 -0000
@@ -453,6 +453,13 @@
void flib_putenv(char *var, char *env)
{
char *s;
+ char *dotchar = ".";
+
+ if( strstr(var, dotchar) )
+ {
+ fprintf(stderr,"<<Cmd_SetEnv>> Illegal character '.' in variable name.\n");
+ return;
+ }
s = safestrdup(var);
var = s;
