From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-6349-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 5883 invoked from network); 26 May 1999 03:03:05 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 26 May 1999 03:03:05 -0000
Received: (qmail 3442 invoked by alias); 26 May 1999 03:02:56 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 6349
Received: (qmail 3435 invoked from network); 26 May 1999 03:02:54 -0000
Date: Wed, 26 May 1999 14:03:19 +1000
From: Aldo Cortesi <aldo@isetroc.com>
To: zsh-workers@sunsite.auc.dk
Subject: Some possible bugs...
Message-ID: <19990526140319.A17252@isetroc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.5us

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