Re: Some possible bugs...

Re: Some possible bugs...

[Sven Wischnowsky]

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@informatik.hu-berlin.de

Re: Some possible bugs...

[Bart Schaefer]

On May 27,  8:44am, Sven Wischnowsky wrote:
} Subject: Re: Some possible bugs...
}
} > 	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. 
} 
} 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.

How hard would it be to make this context-sensitive?  For example, when
the effective compctl says to complete file names, treat the entire
quoted string as one word and attempt to complete it as a file (this is
what bash appears to do); similary for command names or anything else
that normally results in a single shell "word"; otherwise, complete the
way it's presently done.  This might require another compctl option,
similar to using	compctl -x ... -l '' ...	except that the
"range of command line words that are considered to be arguments" is a
single word that has to be split at IFS before completing.

So to get the current behavior you'd use something like (writing old style)

	compctl -x 'c[-1,-c]' -1 -l '' -- zsh

where I'm using -1 as this new option I've described for no better reason
than that I can't remember which (if any) letters are left for compctl.

This would also mean that, in the case where a single word such as a file
name is expected to result, zsh could automatically close the quotes and
append a space after the closing quote.

This so-called -1 option could apply to any other flag that followed it,
not just -l ... generically, it would mean "unquote and split the current
word, find a new current word after the split, then complete using the
following flags, and finally requote the result."

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Some possible bugs...

[Sven Wischnowsky]

Bart Schaefer wrote:

> } 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.
> 
> How hard would it be to make this context-sensitive?

Well, currently this is done by get_comp_string() which calls the
lexer and this *has* to be done at the very beginning, because we
first have to get the command line words and position to find out
which compctl to use. However, we could remove all this quote-removal
stuff and make it always just return the whole quoted string.

> For example, when
> the effective compctl says to complete file names, treat the entire
> quoted string as one word and attempt to complete it as a file (this is
> what bash appears to do); similary for command names or anything else
> that normally results in a single shell "word"; otherwise, complete the
> way it's presently done.  This might require another compctl option,
> similar to using	compctl -x ... -l '' ...	except that the
> "range of command line words that are considered to be arguments" is a
> single word that has to be split at IFS before completing.

I think this wouldn't be enough. One example is the:

  % zsh -c "ls 'foo b<TAB>

I mentioned. This should complete to 'foo bar' if there is such a
possible match. So we would need a way to `remove one level of
quotes'. But the quotes may also contain things where we would need
the whole lexing/parsing if we suddenly decide to work on the parts of 
the quoted string. And, of course, such a quoted string may contain
other quoted parts on which we may or may not want to work separately.

> So to get the current behavior you'd use something like (writing old style)
> 
> 	compctl -x 'c[-1,-c]' -1 -l '' -- zsh
> 
> where I'm using -1 as this new option I've described for no better reason
> than that I can't remember which (if any) letters are left for compctl.

(The only free letter is `h').

> This would also mean that, in the case where a single word such as a file
> name is expected to result, zsh could automatically close the quotes and
> append a space after the closing quote.

Sure, yes. Enhancing cmatch a bit...

> This so-called -1 option could apply to any other flag that followed it,
> not just -l ... generically, it would mean "unquote and split the current
> word, find a new current word after the split, then complete using the
> following flags, and finally requote the result."

If we really want `all flags *following* it' we would have to change
the argument parsing of compctl, which is already pretty complicated.
If we just let it work on all flags surrounding it, at least the
parsing would be simple (of course).

I confess that I hadn't thought about a flag that `works like -l'
(without trying to implement it I would prefer to make it work like -l 
in that it doesn't have an effect on the surrounding flags -- I think
this would be much easier to implement, but I may be wrong).
This sounds good to me, with that we could even use the lexing code
(calling it on the string we should work on). However, if this gets
mixed with completions for the whole quoted string, keeping track of
the positions (where to re-insert the completed string, etc.) may turn 
out to be complicated. Hm, using the quote-removal code when handling
this flag and not using the lexer may be easier, but wouldn't allow us
to complete at places like `zsh -c "[[ -o <TAB>'.

For the new completion system we would need a way, too. We could use
something I've been thinking about when we were discussing it at the
beginning. We could give an option to compset which gets one string as 
argument, parses it and stores the result in $words, $compstate,
$IPREFIX, and so on.

Bye
 Sven

P.S.: I'm mainly thinking about ways to implement this, so some of my
      remarks may be hard to understand, sorry.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Some possible bugs...

[Sven Wischnowsky]

Aldo Cortesi wrote:

> While using it, though, I've run accross a couple of
> problems that force me to use bash for certain tasks. 
> Here they are:

Please try the newest development version which you can get at:

http://www.ifh.de/~pws/computing/
-rw-r--r--   1 pws  quadrics  759988 May 19 13:48 zsh-3.1.5-pws-19.tar.bz2
-rw-r--r--   1 pws  quadrics  368884 May 19 13:48 zsh-3.1.5-pws-19.doc.tar.gz
-rw-r--r--   1 pws  quadrics  249242 May 19 13:48 zsh-3.1.5-pws-19.doc.tar.bz2
-rw-r--r--   1 pws  quadrics  937267 May 19 13:48 zsh-3.1.5-pws-19.tar.gz

...and then we had some patches after that -- see the mailing list
archive at http://www.zsh.org/mla.

> 	The last line of output from a program run in the
> 	shell gets overwritten if it doesn't end in a
> 	newline. This is very, very bad, and should not be
> 	allowed to happen even intentionally. For example
> 	the following program produces no visible output
> 	when run in zsh as I have it set up:
> 		int main(){
> 			printf("mundungus");
> 			return(0);
> 		}

`setopt nopromtcr' -- which has only recently be added to the FAQ.

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

This is still there... no doubt someone will have a look at it.

> 	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. 

We have this discussion again and again... Completion in quotes is
different in zsh because some time ago it was decided to let it work
there (almost) as without the quotes. So if you do ls "one t<TAB>
zsh doesn't think that the quotes are intended to just quote the
filename because for that you simply don't need the quotes. If you do
ls one<TAB> zsh will give you ls one\ two\ , quoting the string as
needed.
However, the behavior shown in your mail looks really weird, I might
have a look at it (but quoting and completion is a terribly
complicated issue).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Some possible bugs...

[Aldo Cortesi]

Hi,

I finally got around to test-driving zsh the other day, and
I liked it enough to make it my default shell. I'm looking
forward to getting to know it well enough to contribute to
it's development. 

While using it, though, I've run accross a couple of
problems that force me to use bash for certain tasks. 
Here they are:

	The last line of output from a program run in the
	shell gets overwritten if it doesn't end in a
	newline. This is very, very bad, and should not be
	allowed to happen even intentionally. For example
	the following program produces no visible output
	when run in zsh as I have it set up:
		int main(){
			printf("mundungus");
			return(0);
		}




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




	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. 

I am running the latest development version (3.1.5).


-- 
Aldo Cortesi
aldo@isetroc.com
Effing the ineffable...