I am using perl64 on Windows 10 with UWIN installed.

I wrote a perl script, sv2jb.pl, which runs fine when invoked under ksh by just typing its name, and when it is in the current directory.

I then created a subdirectory of my home directory called "scripts", moved that script there, added its full path to the $PATH environment of ksh. Now when I invoke sv2jb.pl from any other directory than where this script is (by just typing the script's name), this is the message I get back:

$ sv2jb.pl
Can't open perl script "//C/users/me/desktop/scripts/sv2jb.pl" : No such file or directory

But this is exactly where that file is...

If I invoke it so from the home directory (in which the scripts directory is):

$ scripts/sv2jb.pl

it works fine...

Also, if I cd to that directory, and invoke sv2jb.pl:

$ cd scripts
$ sv2jb.pl

it runs correctly.

I am at a loss to understand what is wrong:

  1. The script itself is OK, since when invoked from its directory it runs. FYI, its first line is: #!//c/perl64/bin/perl.exe
  2. The $PATH variable is OK, since the error message shows that ksh located the file (while saying it can't find it).
  • Beware line endings. Can you show output of head -1 sv2jp.pl | od -c? – BowlOfRed Jan 18 at 1:59
  • I had already checked it, it is OK (see below). Also, if it weren't, the script wouldn't work regardless of where it is invoked from. Here is od's output: # ! / / c / p e r l 6 4 / b i n / p e r l . e x e \r \n \r \n – MichaelParis Jan 18 at 6:57
  • I'm unfamiliar with "UWIN" for windows10. Do you have a reference for it? You're not talking about Windows Subsystem for Linux? – BowlOfRed Jan 18 at 7:08
  • No no, see here about UWIN: en.wikipedia.org/wiki/UWIN – MichaelParis Jan 18 at 7:44
  • Let me add this: the PATH environment contains such directories as /usr/bin, etc., and the binary executables that are in these directories can be invoked without a problem from anywhere else. I put my script in /usr/bin and tried to invoke it: same reply, it said it could not find /usr/bin/sv2jb.pl... (I had invoked it without the full path, so it does find it!). – MichaelParis Jan 18 at 7:47

Not familiar with UWIN, but I'm going to assume it's similar to cygwin in that it provides a library layer to run on top of windows.

When you invoke the script, it's found in the PATH, opened by the program loader, examined to find the #! line, the executable binary is found and exec()ed, with the script name passed in as the first argument.

The problem is that the binary is consistent with being the ActiveState perl, a windows application.

I suspect that when the script is in the current directory, perl is run with the script name passed in as a relative program (something like perl sv2jb.jpl). But when it's elsewhere, a full pathname is given (something like perl //C/users/me/desktop/scripts/sv2jb.pl).

But the windows binary doesn't understand the path that's being passed to it. You can see this by invoking it directly from a windows command prompt. You should see this happen:

C:\Perl64\bin>perl //C/users/me/desktop/scripts/sv2jb.pl  # what is running
Can't open perl script "//C/users/me/desktop/scripts/sv2jb.pl

C:\Perl64\bin>perl C:/users/me/desktop/scripts/sv2jb.pl   # Changed to windows-style filepath
[...program runs....]

I can reproduce the same behavior with cygwin/Win10 and ActiveState Perl.

Basically, setting a windows binary as the executable for a unix script has odd problems. With cygwin, I'd suggest that you instead used the package perl instead of the windows one. I don't know if that's a possible solution for UWIN.

Otherwise, you can call the windows perl, but you must pass in a windows-style path to the script explicitly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.