Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
X-Envelope-Sender-Is: Andrej DOT Borsenkow AT mow DOT siemens DOT ru (at relayer david.siemens.de)
From: "Andrej Borsenkow" <Andrej DOT Borsenkow AT mow DOT siemens DOT ru>
To: "Michael Schaap" <cygwin AT mscha DOT com>, <cygwin AT cygwin DOT com>
Subject: RE: Zsh observations
Date: Thu, 5 Jul 2001 09:59:10 +0400
Message-ID: <000101c10517$9c432f80$21c9ca95@mow.siemens.ru>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.1.0.14.2.20010704215312.0425ae78@imap.mscha.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
Importance: Normal

>
> 1. zsh doesn't like it if ...\cygwin\bin is not in the Windows
> path.  If I
> start up zsh without this, it works as long as the current directory is
> /usr/bin.  If I then do
> 	PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
> 	export PATH
> 	cd $HOME
> (either on the command line, or in /etc/zprofile), any external command I
> run gives:
> 	      0 [main] zsh 2432 sync_with_child: child 2356(0x230)
> died before
> initialization with status code 0x80
> 	   1288 [main] zsh 2432 sync_with_child: *** child state
> waiting for longjmp
> /home/mscha/.zshrc:150: fork failed: resource temporarily unavailable
>

Well ... it does work if you start cmd.exe (I am on NT), and then run zsh as
e.g. \cygwin\bin\zsh. It does not work if you define shortcut and start zsh
via shortcut. Both with current snapshot.

I am pretty sure it worked at some point (because I did have shortcut to
zsh). I cannot recall any changes in zsh that could result in this problem,
but who knows.

zsh exec's other commands in DLL no in main EXE if it matters.

> 2. Sometimes, zsh finds a command further in the path than it
> should.  For
> instance, if PATH=/a:/b, and both /a/hello.exe and /b/hello.exe exist,
> typing "hello" sometimes (but not always) runs /b/hello.exe.  I'm
> not sure,
> but it seems that running "hello.exe" works as it should, so
> perhaps it has
> something to do with the cygwin automagic exe extension handling.
>

Zsh relies on system execve to find command. Basically, it does

for dir in path
  execve dir/cmd

until it succeeds. We recently have a brief discussion on zsh-workers about
it. Irrespectivley if you consider it a bug or feature this was around for a
very long time. So the above lets suspect problem in Cygwin exec - sometimes
it fails to execute /a/hello.exe. Can you reliably reproduce it?

> 3. The command line completion module ("autoload -U compinit; compinit")
> does not work.  It I run this, then command line completion becomes
> erratic.  About half the time it works, but often TAB either expands to
> incorrect strings, or core dumps zsh.
>

Unfortunately, without some information how to reporduce it it is pretty
useless. I have never seen it, but I do not use zsh heavily (on Cygwin).

There were several reports about stray test errors on some systems. So, I
really appreciate any reliable way to reproduce the problem.

-andrej


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/