Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: localhost.localdomain: ronald owned process doing -bs Date: Tue, 11 Feb 2003 19:06:50 +0100 (CET) From: Ronald Landheer-Cieslak X-X-Sender: ronald AT localhost DOT localdomain To: john mapoles cc: cygwin AT cygwin DOT com Subject: Re: New install, script execution, bad interpreter In-Reply-To: <20030211164114.47849.qmail@web9806.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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' 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. Doing $ 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! rlc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/