B20 & bash 2.02.1(2) broken

B20 & bash 2.02.1(2) broken

[Austin David France]

CYGWIN_NT-4.0 MENPC1 20.0 (0.1/1/1) 1998-10-29 15:33:43 i486 unknown
BASH 2.02.1(2)-release
NTW40 Y2KSP4

I installed B20, and discovered a problem with the version of bash shipped
with b20.

I can log in using cygnus.bat OK, however logins via inetd don't work.

Further investigation reveals a very strange problem.  Bash 2.02.1(2) won't
execute a script whose name is less than 6 characters long.

A colleagues is experiencing exactly the same problem, except that bash
won't execute a script whose name is less than 4 characters long.

An interesting co-incidence is that I have 6 dos drive letters, my colleague
has only 4.  I am sure this is just a weird co-incidence.

I have replaced bash 2.02.1(2) with bash 2.02.1(1) and this corrects the
problem for both short script names and inetd (which was presumably a
related problem)

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

Re: B20 & bash 2.02.1(2) broken

[Matt Behrens]

Hmm.  Did it hang when it wouldn't execute those scripts?  If so, that
might well explain part of the problem with configure scripts not
working.

Austin David France wrote:
> 
> CYGWIN_NT-4.0 MENPC1 20.0 (0.1/1/1) 1998-10-29 15:33:43 i486 unknown
> BASH 2.02.1(2)-release
> NTW40 Y2KSP4
> 
> I installed B20, and discovered a problem with the version of bash shipped
> with b20.
> 
> I can log in using cygnus.bat OK, however logins via inetd don't work.
> 
> Further investigation reveals a very strange problem.  Bash 2.02.1(2) won't
> execute a script whose name is less than 6 characters long.
> 
> A colleagues is experiencing exactly the same problem, except that bash
> won't execute a script whose name is less than 4 characters long.
> 
> An interesting co-incidence is that I have 6 dos drive letters, my colleague
> has only 4.  I am sure this is just a weird co-incidence.
> 
> I have replaced bash 2.02.1(2) with bash 2.02.1(1) and this corrects the
> problem for both short script names and inetd (which was presumably a
> related problem)
> 
> 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".

-- 
  __
 /-/    Matt Behrens
( (     mbehrens@iserv.net
 ) )    Iserv Network Operations Center
/_/     http://inoc.iserv.net/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: B20 & bash 2.02.1(2) broken

[Austin David France]

Yes.  ^C breaks out of it though.

I have since switched back to the b20 release of bash (2.01.1(2)) to avoid
having to have the b19 DLL loaded (I wonder if they will happily co-exist)
and the problem now seems intermittent.  One invocation of bash, it works
OK, yet another invocation of bash it hangs.

Humm... Just testing it now, and it's changed again.  I have a script called
"vi" which is a wrapper for vim/vile (it parses the arguments for me).

In /mentor I have a symbolic link bin -> /d/Mentor/bin (i.e. /mentor/bin is
a link to /d/Mentor/Bin).

Here are some example of how it changes, these commands were all performed
as I was composing this mail in the same instance of bash.

	$ vi /tmp/oz
	/d/Mentor/Bin/: Can't open /d/Mentor/Bin/
	$ /d/Mentor/Bin/vi /tmp/oz
	(thrown into vim on /tmp/oz)
	$ export PATH=/bin:/mentor/bin:/usr/local/bin
	$ vi
	hangs, bash.exe eating CPU (believe this is the parent bash)
	^C interrupts
	$ vi /tmp/oz
	(thrown into vim on /tmp/oz)
	$ cd /bin
	$ sh.exe
		do some stuff (echo etc) and exit
	$ vi /tmp/oz
	/mentor/bin/: /mentor/bin/: Permission Denied
	$ /mentor/bin/vi /tmp/oz
	(thrown into vim on /tmp/oz)
	$ export PATH=/bin:/d/Mentor/Bin:/usr/local/bin
	$ vi /tmp/oz
	(thrown into vim on /tmp/oz)
	$ vi /tmp/oz
	hangs, ^c interrupts
	$ export PATH=/bin:/mentor/bin:/usr/local/bin
	$ vi /tmp/oz
	/mentor/bin/: /mentor/bin/: Permission Denied
	$ /mentor/bin/vi /tmp/oz
	(thrown into vim on /tmp/oz)

If I run my script using an aboslubte path, it reliably works.

My ORIGIONAL path (when bash was loaded) did contain spaces.

> -----Original Message-----
> From: owner-gnu-win32@cygnus.com [ mailto:owner-gnu-win32@cygnus.com]On
> Behalf Of Matt Behrens
> Sent: 06 November 1998 12:14
> Cc: Gnu-Win32 Mailing List (E-mail)
> Subject: Re: B20 & bash 2.02.1(2) broken
>
>
> Hmm.  Did it hang when it wouldn't execute those scripts?  If so, that
> might well explain part of the problem with configure scripts not
> working.
>
> Austin David France wrote:
> >
> > CYGWIN_NT-4.0 MENPC1 20.0 (0.1/1/1) 1998-10-29 15:33:43 i486 unknown
> > BASH 2.02.1(2)-release
> > NTW40 Y2KSP4
> >
> > I installed B20, and discovered a problem with the version of
> bash shipped
> > with b20.
> >
> > I can log in using cygnus.bat OK, however logins via inetd don't work.
> >
> > Further investigation reveals a very strange problem.  Bash
> 2.02.1(2) won't
> > execute a script whose name is less than 6 characters long.
> >
> > A colleagues is experiencing exactly the same problem, except that bash
> > won't execute a script whose name is less than 4 characters long.
> >
> > An interesting co-incidence is that I have 6 dos drive letters,
> my colleague
> > has only 4.  I am sure this is just a weird co-incidence.
> >
> > I have replaced bash 2.02.1(2) with bash 2.02.1(1) and this corrects the
> > problem for both short script names and inetd (which was presumably a
> > related problem)
> >
> > 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".
>
> --
>   __
>  /-/    Matt Behrens
> ( (     mbehrens@iserv.net
>  ) )    Iserv Network Operations Center
> /_/     http://inoc.iserv.net/
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
>
>


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

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

RE: B20 & bash 2.02.1(2) broken

[jwills]

"Austin David France" <adf@mentor-systems.com> wrote:

> Creating a function called vi will work around the problem, as shown below,
> because the path to the script is specified.
> 
> 	$ function vi () { /d/Mentor/Bin/vi ; }
> 	$ type -a vi
> 	vi is a function
> 	vi ()
> 	{
> 		/d/Mentor/Bin/vi
> 	}
> 	vi is /d/Mentor/Bin/vi
> 	vi is /d/Mentor/Bin/vi
> 
> But this digresses from the problem.  The problem is there is a bug in bash
> in it's handling of the command line and executing scripts.  I cannot afford
> to have to create a function wrapper for every possible script I may want to
> execute.

This failure to execute shell scripts is a real pain. I also considered writing
function wrappers but settled on a simpler approach. I just "source" my
shell scripts and they seem to execute.

bash-2.02$ echo "echo \"test script\"" > foo
bash-2.02$ chmod +x foo
bash-2.02$ foo
bash: ./foo: No such file or directory
bash-2.02$ . foo
test script
bash-2.02$

This is surely a hack but it's letting me get some real work done.

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

RE: B20 & bash 2.02.1(2) broken

[Austin David France]

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

RE: B20 & bash 2.02.1(2) broken

[Austin David France]

Creating a function called vi will work around the problem, as shown below,
because the path to the script is specified.

	$ function vi () { /d/Mentor/Bin/vi ; }
	$ type -a vi
	vi is a function
	vi ()
	{
		/d/Mentor/Bin/vi
	}
	vi is /d/Mentor/Bin/vi
	vi is /d/Mentor/Bin/vi

But this digresses from the problem.  The problem is there is a bug in bash
in it's handling of the command line and executing scripts.  I cannot afford
to have to create a function wrapper for every possible script I may want to
execute.

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


> -----Original Message-----
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> Sent: 13 November 1998 12:20
> To: Austin David France
> Subject: RE: B20 & bash 2.02.1(2) broken
>
>
>
> Interesting.  I wonder what would happen if you created a bash
> function named vi?
>
> General syntax is:
>
> function vi {
>   COMMANDS
> }
>
> Caution: You can create circular dependencies which will hang bash
> every time.
>
> ---Austin David France <adf@mentor-systems.com> wrote:
> >
> > $ type -a vi
> > bash: type: vi: not found
> > $ chmod +x /d/Mentor/Bin/vi
> > $ type -a vi
> > vi is /d/Mentor/Bin/vi
> > vi is /d/Mentor/Bin/vi
> > $ vi /tmp/oz
> > (hangs, ^C aborts)
> >
> > vi is a script that starts
> >
> > 	#!/bin/bash
> > 	echo "vi"
> > 	set -x
> > 	cmd="${MEDITOR:-vim}"
> >
> > It matters not what the #!/bin/<shell> is, (tried sh, ksh and bash)
> if it
> > points to a valid shell, it hangs.  If the #! line is missing
> (blank) or a
> > silly shell name is put in, for
> > example #!/bin/winkle then bash reports
> >
> > 	bash: /d/Mentor/Bin/vi: No such file or directory
> >
> > which is to be expected.
> >
> > Some more tests with interesting results
> >
> > 	$ cd /d/Mentor/Bin
> > 	$ ln -s vi viabcd
> > 	$ cp vi viabcdef
> > 	$ chmod +x *vi*
> > 	$ vi
> > 	(hangs)
> > 	$ vi viabcdef
> > 	(throws me into vi)
> > 	$ viabcdef
> > 	(throws me into vi on no file)
> > 	$ vi a
> > 	(hangs)
> > 	$ vi winkle
> > 	(hangs)
> > 	$ vi viwinkle
> > 	(throws me into vi)
> > 	$ vi xxwinkle
> > 	(throws me into vi)
> > 	$ vi winklexx
> > 	(theows me into vi)
> > 	$ vi # hello this is a comment
> > 	(hangs)
> > 	$ vi hello this is a comment
> > 	(throws me into vi on files "hello", "this", "is" and so on)
> >
> > It has to be something to do with the length of the command + it's
> > arguments.
> >
> > Austin David France
> > Mentor Systems plc
> > mailto:adf@mentor-systems.com
> >
> >
> > > -----Original Message-----
> > > From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> > > Sent: 12 November 1998 12:08
> > > To: Austin David France
> > > Subject: RE: B20 & bash 2.02.1(2) broken
> > >
> > >
> > >
> > >
> > > What does the bash command `type -a vi' show?  Is it possible that
> > > you're picking up the wrong version of vi?
> > >
> > >
> > > ---Austin David France <adf@mentor-systems.com> wrote:
> > > >
> > > > No joy, exactly the same problem.  uname -a reports
> > > >
> > > > 	CYGWIN_NT-4.0 MENPC1 20.0 (0.1/1/1) -11-8 11:59:08
> i486 unknown
> > > >
> > > > I'm guessing the -11-8 is based upon build date of the DLL (8
> Nov 98).
> > > >
> > > > For example, I just tried
> > > >
> > > > 	$ vi /tmp/oz
> > > > 	(hangs, ^C aborts)
> > > > 	$ export PATH=/bin:/mentor/bin:/usr/local/bin
> > > > 	$ vi /tmp/oz
> > > > 	/mentor/bin/: /mentor/bin/: Permission Denied
> > > > 	$ /mentor/bin/vi /tmp/oz
> > > > 	(throws me into vim as expected)
> > > >
> > > > A find of cygwin find no other cygwin dll's in the path.  My
> > > cygwinb19.dll
> > > > is a copy of the new b20 dll.
> > > > Austin David France
> > > > Mentor Systems plc
> > > > mailto:adf@mentor-systems.com
> > > >
> > > <snip>
> > >
> > > ==
> > > -                  \\||//
> > > -------------o0O0--Earnie--0O0o--------------
> > > --          earnie_boyd@yahoo.com          --
> > > -- http://www.freeyellow.com/members5/gw32 --
> > > ----------------ooo0O--O0ooo-----------------
> > >
> > > PS: Newbie's, you should visit my page.
> > > _________________________________________________________
> > > DO YOU YAHOO!?
> > > Get your free @yahoo.com address at http://mail.yahoo.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.
> >
> >
> ------------------------------------------------------------------------
> >
> >
> >
>
> ==
> -                        \\||//
> -------------------o0O0--Earnie--0O0o-------------------
> --                earnie_boyd@yahoo.com               --
> -- http://www.freeyellow.com/members5/gw32/index.html --
> ----------------------ooo0O--O0ooo----------------------
>
> PS: Newbie's, you should visit my page.
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.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".

RE: B20 & bash 2.02.1(2) broken

[Austin David France]

$ type -a vi
bash: type: vi: not found
$ chmod +x /d/Mentor/Bin/vi
$ type -a vi
vi is /d/Mentor/Bin/vi
vi is /d/Mentor/Bin/vi
$ vi /tmp/oz
(hangs, ^C aborts)

vi is a script that starts

	#!/bin/bash
	echo "vi"
	set -x
	cmd="${MEDITOR:-vim}"

It matters not what the #!/bin/<shell> is, (tried sh, ksh and bash) if it
points to a valid shell, it hangs.  If the #! line is missing (blank) or a
silly shell name is put in, for
example #!/bin/winkle then bash reports

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

which is to be expected.

Some more tests with interesting results

	$ cd /d/Mentor/Bin
	$ ln -s vi viabcd
	$ cp vi viabcdef
	$ chmod +x *vi*
	$ vi
	(hangs)
	$ vi viabcdef
	(throws me into vi)
	$ viabcdef
	(throws me into vi on no file)
	$ vi a
	(hangs)
	$ vi winkle
	(hangs)
	$ vi viwinkle
	(throws me into vi)
	$ vi xxwinkle
	(throws me into vi)
	$ vi winklexx
	(theows me into vi)
	$ vi # hello this is a comment
	(hangs)
	$ vi hello this is a comment
	(throws me into vi on files "hello", "this", "is" and so on)

It has to be something to do with the length of the command + it's
arguments.

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


> -----Original Message-----
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> Sent: 12 November 1998 12:08
> To: Austin David France
> Subject: RE: B20 & bash 2.02.1(2) broken
>
>
>
>
> What does the bash command `type -a vi' show?  Is it possible that
> you're picking up the wrong version of vi?
>
>
> ---Austin David France <adf@mentor-systems.com> wrote:
> >
> > No joy, exactly the same problem.  uname -a reports
> >
> > 	CYGWIN_NT-4.0 MENPC1 20.0 (0.1/1/1) -11-8 11:59:08 i486 unknown
> >
> > I'm guessing the -11-8 is based upon build date of the DLL (8 Nov 98).
> >
> > For example, I just tried
> >
> > 	$ vi /tmp/oz
> > 	(hangs, ^C aborts)
> > 	$ export PATH=/bin:/mentor/bin:/usr/local/bin
> > 	$ vi /tmp/oz
> > 	/mentor/bin/: /mentor/bin/: Permission Denied
> > 	$ /mentor/bin/vi /tmp/oz
> > 	(throws me into vim as expected)
> >
> > A find of cygwin find no other cygwin dll's in the path.  My
> cygwinb19.dll
> > is a copy of the new b20 dll.
> > Austin David France
> > Mentor Systems plc
> > mailto:adf@mentor-systems.com
> >
> <snip>
>
> ==
> -                  \\||//
> -------------o0O0--Earnie--0O0o--------------
> --          earnie_boyd@yahoo.com          --
> -- http://www.freeyellow.com/members5/gw32 --
> ----------------ooo0O--O0ooo-----------------
>
> PS: Newbie's, you should visit my page.
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.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".

RE: B20 & bash 2.02.1(2) broken

[Earnie Boyd]

Perform your tests with the newest release of the cygwin1.dll found in
the coolview package on Sergey Okhapkin's site.  See my site if you
need the URL.

---Austin David France <adf@mentor-systems.com> wrote:
>
> Yes.  ^C breaks out of it though.
> 
> I have since switched back to the b20 release of bash (2.01.1(2)) to
avoid
> having to have the b19 DLL loaded (I wonder if they will happily
co-exist)
> and the problem now seems intermittent.  One invocation of bash, it
works
> OK, yet another invocation of bash it hangs.
> 
> Humm... Just testing it now, and it's changed again.  I have a
script called
> "vi" which is a wrapper for vim/vile (it parses the arguments for me).
> 
> In /mentor I have a symbolic link bin -> /d/Mentor/bin (i.e.
/mentor/bin is
> a link to /d/Mentor/Bin).
> 
> Here are some example of how it changes, these commands were all
performed
> as I was composing this mail in the same instance of bash.
> 
> 	$ vi /tmp/oz
> 	/d/Mentor/Bin/: Can't open /d/Mentor/Bin/
> 	$ /d/Mentor/Bin/vi /tmp/oz
> 	(thrown into vim on /tmp/oz)
> 	$ export PATH=/bin:/mentor/bin:/usr/local/bin
> 	$ vi
> 	hangs, bash.exe eating CPU (believe this is the parent bash)
> 	^C interrupts
> 	$ vi /tmp/oz
> 	(thrown into vim on /tmp/oz)
> 	$ cd /bin
> 	$ sh.exe
> 		do some stuff (echo etc) and exit
> 	$ vi /tmp/oz
> 	/mentor/bin/: /mentor/bin/: Permission Denied
> 	$ /mentor/bin/vi /tmp/oz
> 	(thrown into vim on /tmp/oz)
> 	$ export PATH=/bin:/d/Mentor/Bin:/usr/local/bin
> 	$ vi /tmp/oz
> 	(thrown into vim on /tmp/oz)
> 	$ vi /tmp/oz
> 	hangs, ^c interrupts
> 	$ export PATH=/bin:/mentor/bin:/usr/local/bin
> 	$ vi /tmp/oz
> 	/mentor/bin/: /mentor/bin/: Permission Denied
> 	$ /mentor/bin/vi /tmp/oz
> 	(thrown into vim on /tmp/oz)
> 
> If I run my script using an aboslubte path, it reliably works.
> 
> My ORIGIONAL path (when bash was loaded) did contain spaces.
> 
> > -----Original Message-----
> > From: owner-gnu-win32@cygnus.com
[ mailto:owner-gnu-win32@cygnus.com]On
> > Behalf Of Matt Behrens
> > Sent: 06 November 1998 12:14
> > Cc: Gnu-Win32 Mailing List (E-mail)
> > Subject: Re: B20 & bash 2.02.1(2) broken
> >
> >
> > Hmm.  Did it hang when it wouldn't execute those scripts?  If so,
that
> > might well explain part of the problem with configure scripts not
> > working.
> >
> > Austin David France wrote:
> > >
> > > CYGWIN_NT-4.0 MENPC1 20.0 (0.1/1/1) 1998-10-29 15:33:43 i486
unknown
> > > BASH 2.02.1(2)-release
> > > NTW40 Y2KSP4
> > >
> > > I installed B20, and discovered a problem with the version of
> > bash shipped
> > > with b20.
> > >
> > > I can log in using cygnus.bat OK, however logins via inetd don't
work.
> > >
> > > Further investigation reveals a very strange problem.  Bash
> > 2.02.1(2) won't
> > > execute a script whose name is less than 6 characters long.
> > >
> > > A colleagues is experiencing exactly the same problem, except
that bash
> > > won't execute a script whose name is less than 4 characters long.
> > >
> > > An interesting co-incidence is that I have 6 dos drive letters,
> > my colleague
> > > has only 4.  I am sure this is just a weird co-incidence.
> > >
> > > I have replaced bash 2.02.1(2) with bash 2.02.1(1) and this
corrects the
> > > problem for both short script names and inetd (which was
presumably a
> > > related problem)
> > >
> > > 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".
> >
> > --
> >   __
> >  /-/    Matt Behrens
> > ( (     mbehrens@iserv.net
> >  ) )    Iserv Network Operations Center
> > /_/     http://inoc.iserv.net/
> > -
> > For help on using this list (especially unsubscribing), send a
message to
> > "gnu-win32-request@cygnus.com" with one line of text: "help".
> >
> >
> 
> 
>
------------------------------------------------------------------------
> 
> 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".
> 

==
-                  \\||//
-------------o0O0--Earnie--0O0o--------------
--          earnie_boyd@yahoo.com          --
-- http://www.freeyellow.com/members5/gw32 --
----------------ooo0O--O0ooo-----------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

RE: B20 & bash 2.02.1(2) broken

[Austin David France]

Additional Info:

I had to revert to bash 2.01.1(2)-release because of delay problems and
stopped jobs, I then at some point later installed a copy of cygwin1.dll as
cygwinb19.dll (to try and get around some problems with telnet) and the
original bash 2.02.1(2) problem (wont run scripts with short names) has
re-occurred (in bash-2.01.1(2)-release).

Sound like a problem with cygwin1.dll to me.

> -----Original Message-----
> From: Austin David France [ mailto:adf@mentor-systems.com ]
> Sent: 03 November 1998 12:24
> To: Gnu-Win32 Mailing List (E-mail)
> Cc: Jonathan Storey
> Subject: B20 & bash 2.02.1(2) broken
>
>
> CYGWIN_NT-4.0 MENPC1 20.0 (0.1/1/1) 1998-10-29 15:33:43 i486 unknown
> BASH 2.02.1(2)-release
> NTW40 Y2KSP4
>
> I installed B20, and discovered a problem with the version of
> bash shipped with b20.
>
> I can log in using cygnus.bat OK, however logins via inetd don't work.
>
> Further investigation reveals a very strange problem.  Bash
> 2.02.1(2) won't execute a script whose name is less than 6
> characters long.
>
> A colleagues is experiencing exactly the same problem, except
> that bash won't execute a script whose name is less than 4
> characters long.
>
> An interesting co-incidence is that I have 6 dos drive letters,
> my colleague has only 4.  I am sure this is just a weird co-incidence.
>
> I have replaced bash 2.02.1(2) with bash 2.02.1(1) and this
> corrects the problem for both short script names and inetd (which
> was presumably a related problem)
>
> 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".