This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New install, script execution, bad interpreter

On Tue, 11 Feb 2003, john mapoles wrote:
> bash: ./testAS: /usr/local/bin/perl: bad interpreter:
> No such file or directory
Look whether /usr/local/bin/perl exists - I bet it doesn't (because that's 
what it says: /usr/local/bin/perl: (...) No such file or directory

> I've check a number of things.  The scripts are all unix, dos2unix has
> no effect.  Running a simple bash script works fine, althought ?? if I
> move the script to my bin directory and back it will not work.
> cyg> testSH
> bash
> cyg> mv testSH ./bin
> cyg> testSH
> bash
> cyg> mv ./bin/testSH .
> cyg> testSH
> bash: /home/jmapoles/bin/testSH: No such file or
> directory
> cyg>
bash.indo, chapter "Command Search and Execution" says:
  3. If the name is neither a shell function nor a builtin, and
     contains no slashes, Bash searches each element of `$PATH' for a
     directory containing an executable file by that name.  Bash uses a
     hash table to remember the full pathnames of executable files to
     avoid multiple `PATH' searches (see the description of `hash' in
     *Note Bourne Shell Builtins::).  A full search of the directories
     in `$PATH' is performed only if the command is not found in the
     hash table.  If the search is unsuccessful, the shell prints an
     error message and returns an exit status of 127.

What this means is that, when you run your little shell script (without 
specifying where it is) Bash looks for it in the PATH, and puts it in an 
internal hash. If you then move your script, the hash will not be 
up-to-date but it will look in there anyway. If it doesn't exist where it 
expects tp find it => error

This is all you need to know about the hash built-in command:

          hash [-'r] [-p FILENAME] [-dt] [NAME]
     Remember the full pathnames of commands specified as NAME
     arguments, so they need not be searched for on subsequent
     invocations.  The commands are found by searching through the
     directories listed in `$PATH'.  The `-p' option inhibits the path
     search, and FILENAME is used as the location of NAME.  The `-r'
     option causes the shell to forget all remembered locations.  The
     `-d' option causes the shell to forget the remembered location of
     each NAME.  If the `-t' option is supplied, the full pathname to
     which each NAME corresponds is printed.  If multiple NAME
     arguments are supplied with `-t' the NAME is printed before the
     hashed full pathname.  The `-l' option causes output to be
     displayed in a format that may be reused as input.  If no
     arguments are given, or if only `-l' is supplied, information
     about remembered commands is printed.  The return status is zero
     unless a NAME is not found or an invalid option is supplied.

Hence, when I try your little experiment and type
$ hash -l
it shows me where I put the script and when I try to launch it, I get the 
same error as you do.
$ hash -r
will make it find your original script again.

As for your missing /usr/local/bin/perl interpreter:
you probably put the perl wrapper script there when you started out, it 
got lost, so you'll have to put it there again

Good luck!


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]