From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6444 invoked from network); 10 Mar 1999 16:33:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Mar 1999 16:33:26 -0000 Received: (qmail 1391 invoked by alias); 10 Mar 1999 16:32:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5734 Received: (qmail 1383 invoked from network); 10 Mar 1999 16:32:30 -0000 Date: Wed, 10 Mar 1999 17:32:28 +0100 (MET) Message-Id: <199903101632.RAA17756@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Bart Schaefer's message of Wed, 10 Mar 1999 08:20:52 -0800 (PST) Subject: Re: PATCH: tricky.c (was messages from Andrej and Bart) Bart Schaefer wrote: > > The problem is that after expansion, the code can't find out > > what came from the expansion in cases like `${foo}x'. > > Hrm ... so what was happening in the old completion code in this case? Thinks went utterly wrong, even worse than what the new code did before the patch: % echo $PWD:h % echwischnow/ ... of course, the result depends on the last pathname component. > > So the patch just uses the expanded prefix if it has the problem that > > the expanded prefix contains slashes and the original string doesn't. > > Maybe a better solution would be to do nothing in such cases. > > Does this apply only to file completion? What if the expansion happens > in some other context where slashes aren't special? The error occured only in the code that is used when completing filenames. In other contexts the expanded prefix would be used and completed. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de