From mboxrd@z Thu Jan  1 00:00:00 1970
From: jwills@tollbridgetech.com
To: gnu-win32@cygnus.com
Subject: RE: B20 & bash 2.02.1(2) broken
Date: Tue, 17 Nov 1998 13:53:00 -0000
Message-id: <199811171855.KAA19943@vmx01.brainstorm.net>
References: <19981113121954.1291.rocketmail@send103.yahoomail.com> <000101be0f27$b571ae20$010120c0@menpc1>
X-SW-Source: 1998-11/msg00744.html

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