From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Austin David France" To: Cc: "Gnu-Win32 Mailing List (E-mail)" Subject: RE: B20 & bash 2.02.1(2) broken Date: Tue, 17 Nov 1998 04:03:00 -0000 Message-id: <002801be121b$7daae000$010120c0@menpc1> References: <19981116134918.11274.rocketmail@send102.yahoomail.com> X-SW-Source: 1998-11/msg00727.html > 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".