Re: Some possible bugs...

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Aldo Cortesi wrote:

> 	Running zsh with invalid command-line arguments
> 	causes a coredump. For instance
> 		zsh -asdfas
> 	produces a very nice corefile on my machine. 

The problem was the `-a'. This turned on ALL_EXPORT before
createparamtable() was called. When it was called, the first few
parameters were put into the environment before that was copied. This
made the realloc() in addenv() fail.
The patch below tries to fix this by temporarily unsetting ALL_EXPORT
before the environment is copied.

> 	I think that tab-completion of filenames containing
> 	spaces is not useful. For instance, if you have two
> 	files called:
> 		"one two three"
> 		"one two five"
> 	and you type 
> 		ls "one<tab>"
> 	it completes to "one two". If you press tab
> 	repeatedly you get:
> 		ls "one two one two one two..."
> 	I guess this should really cycle between the two
> 	filenames to be consistent with normal
> 	file-completion. Another problem is that if you
> 	type:
> 		ls "one<tab>"
> 	and get:
> 		ls "one two"
> 	and then type the next couple of characters and
> 	press tab again, like so:
> 		ls "one two f<tab>"
> 	no completion is done at all. 
> 	Bash does this type of thing quite nicely. It might
> 	be an idea to take a leaf from their book, so to
> 	speak. 

Only some more remarks for this one. I'd like to hear comments if we
should change something here (and I'd like to find a way to avoid this 
question -- which is almost a FAQ -- in the future, but I don't think
this is possible).
The problem is that in things like `zsh -c "ls <TAB>' one doesn't want 
the shell to treat the `"ls ' as one string. So when completing inside 
quotes, zsh treats words separated by spaces as outside the quotes.
Aldo's example shows the problem that arises when the string inserted
by the shell contains characters that would need to be quoted outside
of quotes. We could change it to backslash such characters even inside
quotes, which would give the expected result for ls "foo<TAB> and
for ls 'foo<TAB>, but not for "ls 'foo<TAB>, unless we test for such
nested quotes, too. But this can get rather complicated very quickly.
Also, zsh does quite a bit of work to find out how the string it is
working on is quoted and uses the result of this test to determine if
characters should be quoted or not. I don't remember exactly why we
decided to use what we have now (w.r.t. to inserting special
characters unbackslashed inside quotes), but I vaguely remember Peter
spending time improving this testing, so there almost certainly are
reasons for doing so.
Ok, now the question is: should zsh insert special characters
backslashed inside quotes? Should it do that only inside the first
level of quotes (after "ls , not after "ls '), or what. I don't think
I'll find enough time to think about/try out all possible combinations 
of quotes and what to do there, so I need some help here.

Bye
 Sven

--- os/params.c	Fri May 21 19:59:38 1999
+++ Src/params.c	Wed May 26 21:36:39 1999
@@ -443,7 +443,7 @@
     Param ip, pm;
     char **new_environ, **envp, **envp2, **sigptr, **t;
     char buf[50], *str, *iname;
-    int num_env;
+    int num_env, oae = opts[ALLEXPORT];
 
     paramtab = realparamtab = newparamtable(151, "paramtab");
 
@@ -463,6 +463,7 @@
 	 * be initialized before we copy the environment variables. *
 	 * We don't want to override whatever values the users has  *
 	 * given them in the environment.                           */
+	opts[ALLEXPORT] = 0;
 	setiparam("MAILCHECK", 60);
 	setiparam("LOGCHECK", 60);
 	setiparam("KEYTIMEOUT", 40);
@@ -508,6 +509,7 @@
 	    }
 	}
 	environ = new_environ;
+	opts[ALLEXPORT] = oae;
 
 	pm = (Param) paramtab->getnode(paramtab, "HOME");
 	if (!(pm->flags & PM_EXPORTED)) {

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx