RE: B20 & bash 2.02.1(2) broken

["Austin David France" <adf at mentor-systems dot com>]

> Oh, I wasn't saying that you should do this for every possible script.
>  I was just trying to narrow down the possibilities.

Apologies then, it just seemed were diverging from the actual problem.

> So far we know that:
>
> 1) #! /bin/[sh|ksh|bash] will cause a "hang".
> 2) If #! /bin/[sh|ksh|bash] isn't present the script will operate
> normally.

In my case, it does not.  If I remove the #! line from the script (either
completely or by replacing it with a blank line) I get the following results

	$ vi
	bash: /d/Mentor/Bin/vi: No such file or directory
	$ mv /d/Mentor/Bin/vi /d/Mentor/Bin/vilongname
	$ vilongname
	bash: /d/Mentor/Bin/vilongname: No such file or directory

If in put the #!/bin/ksh back into "vilongname"

	$ vilongname
	(throws me into vim as required)
	$ mv /d/Mentor/Bin/vilongname /d/Mentor/Bin/vi
	$ vi
	( hangs )

It all comes down to the length of the script name.  The only other factor
that seems to have some baring is the PATH.  With a long path, with win32
directories in it (including spaces)

	$ vi thisisatest
	(hangs)
	$ export PATH=/bin:/d/Mentor/Bin
	$ vi thisisatest
	(throws me into vim on thisisatest)
	$ vi
	(hangs)

> 3) If you convert the script to a function it will operate normally.

No, converting the script into a function does not correct the problem,
consider

	$ mv /d/Mentor/Bin/vi /d/Mentor/Bin/myvi
	$ vi () { myvi $@ ; }
	$ vi
	(hangs - because the script has a short name )
	$ vi () { /d/Mentor/Bin/myvi $@ ; }
	$ vi
	(works - because the script (command) is now a long name, or perhaps it
	is because bash did not have to search the path).

I believe the problem is a memory corruption on, related to the searching of
the path for the command name, or the shell with which to run the command.
Using a longer name probably just avoids the corruption.

>
> Based on what we know, IMHO, the problem isn't bash but the problem is
> with the cygwin library (cygwin[whateverishere].dll) which controls
> the child processes, and there is an extra level of child processes
> when you use #!/bin/[sh|ksh|bash].

I also believe the problem lies with the cygwin DLL (I am using the 8/11/98
coolview version at present).  I would question the extra level of child
process for #!/bin/.... there is still only one (or should only be one) but
this happens to be a shell which is passed the script name to execute along
with the arguments for that script.

In fact, that's probably the exact point where the problem lies, when the
DLL is building the final command line to execute, it is hanging (or
otherwise failing) when the script name is a short one.

>
> I don't know what else you could do except maybe help debug the winsup
> code.  For some fun in your spare time take a look at fork.cc from the
> winsup source directory.

I think that is probably a good idea.  I can then do my own investigations
and then communicate the results, rather that the slow process of
communicating the symptoms in the hope that someone can reproduce and
correct - which I know being a developer is not always that simple.

Thankyou for your assistance.  I will keep you (and the list) up to date
with any progress I make.

TTFN
Austin David France
Mentor Systems plc
mailto:adf@mentor-systems.com



------------------------------------------------------------------------

The views and opinions expressed in this e-mail message are the sender's
and do not necessarily represent the views of Mentor Systems plc.

------------------------------------------------------------------------


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".