Re: Odd -w behavior on scripts written on Win32 platform

All of the answers here point to the end-of-line sequence difference on Windows and Unix.

...but doesn't the error "bash: ./scriptname.pl: No such file or directory" mean that bash can't find the file called scriptname.pl in the current directory?

If it's line endings that cause the problem, then that file has already been found. Wouldn't the error be either from the Perl compiler complaining about syntax, or from bash saying that it can't find whatever appears to be on the shebang line?

Comment on Re: Odd -w behavior on scripts written on Win32 platform

Replies are listed 'Best First'.
(Ovid) Re: Re: Odd -w behavior on scripts written on Win32 platform by Ovid (Cardinal) on Jan 03, 2002 at 03:00 UTC
Note how the script was called: `bash: ./scriptname.pl: No such file or directory` [download] By adding the dot slash before the script name, you're telling the shell to open that script and figure out from the shebang line which program to execute it with. Thus, it is not Perl complaining about syntax issues as Perl is never found. The "no such file or directory" is due to the `\r` at the end of the shebang. Running `cat -vE scriptname.pl` will show those extra newlines as a cntl-M: `$ cat -vE test.pl #!/usr/bin/perl -w^M$ use strict;^M$ ^M$ my $log = './logfile';^M$` [download] Without the warnings switch, the shebang would look like this: $ cat -vE test.pl #!/usr/bin/perl^M$ [download] The shell thinks the cntl-M is part of the filename, thus giving you the 'no such file' error. Cheers, Ovid Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply] [d/l] [select]
Re: Re: Odd -w behavior on scripts written on Win32 platform by Fastolfe (Vicar) on Jan 03, 2002 at 03:04 UTC
Not quite.. It's the C system library that's generating the error message in this case. All your shell is doing is calling an exec() variant with the command you're trying to execute. The C library opens the script, sees that there's a shebang line at the top with an interpreter specified, and it tries to invoke the interpreter. Since the interpreter isn't found (because it has a trailing, spurious CR at the end of it in this case), the exec() call has to return with a "No such file or directory" error, which is what you see. It "might" be feasible for the shell to explore a little further into the cause of the error by testing to see if the file does indeed exist, and if it does, throw a more descriptive error message, but it doesn't. All bash knows is that the system told it ENOENT (No such file or directory) when the shell asked the system to execute your script. `execve("./test", 0x00053AA8, 0x00053AB0) Err#2 ENOENT` [download]	[reply] [d/l]