Perl - edit in Windows but run directly on Unix shell? - windows

I write my Perl code in Textpad (which I believe is only avai in Windows). I run it on Linux cmd prompt by calling the Perl interpreter explicitly, e.g. "perl script.pl". I was wondering if it's possible to run it simply as in "./script.pl". When I add the shebang in Windows, the Linux prompt complains "command not found", but it works fine if I call it with Perl, and also works fine after I dos2unix the script, so the issue seems to be the shebang not being parsed correctly. Any suggestions? Why does the rest of the Windows-formatted code work but not the shebang?

Your problem is that Windows prefers a different line ending convention (CRLF, or \r\n) than other operating systems (LF, or \n). Your editor is creating files with \r\n line endings by default.
The shebang is parsed by the operating system, which is not as forgiving as Perl about the stray \r at the end of the command. It tries to run /usr/bin/perl\r, which doesn't exist.
Your text editor should be able to save the script with Unix line-endings. This won't cause problems with using it on Windows, though a few Windows text editors (including Notepad) won't recognize the line endings properly. This will make it work properly on Linux.

The first line of your file is
#!/usr/bin/perl<CR><LF>
<LF> is the line terminator, so the OS tries to launch /usr/bin/perl<CR>. There is no such program. dos2unix changes the first line to
#!/usr/bin/perl<LF>
<LF> is the line terminator, so the OS tries to launch /usr/bin/perl and succeeds.

Related

How to set up Cygwin to use DOS file endings?

I have following problem:
When I run a shell script, that has been stored with CR+LF line endings, I get following error:
myscript.sh: line 1: cd: $'somedir\\someotherdir\r': No such file or directory
I have researched the problem and there is a solution for Cygwin shell, found here:
Create a .bashrc file
Put this inside:
export SHELLOPTS
set -o igncr
Reload Cygwin shell
However, I use Cmder and I'd like to apply this in it. But, I do not know how. As noted here, Cygwin used to have an option to set the use of DOS file endings as a default during installation, but got rid of it (no idea why).
The weirdest thing of all is that I have the same setup on my older computer, also Windows 10, and everything works well, even with CRLF endings...
I ran into the same problem with upgrading from a very old Cygwin version to the latest.
For just a very few limited "sed" invocations, I explicitly added a \r to the output to keep some other downstream, non-cygwin tools happy.
sed s_(complicated-regex-with-capture)_\1\r_g infile > outfile
A regex guru could probably improve upon this approach to optionally capture and emit the "\r" only if it is found in the data.
sed s_(capture1)(capture\r-or-empty:\r*)$_\1\2_g infile > outfile
You can also use dos2unix which can be installed with Cygwin.

newline in mac command file created in windows

I am creating a command file in windows using JavaScript activexobject.
This file will run on Mac after double click.
I am writing the file as
script.write("#!/bin/bash\r");
script.write('cd "$(dirname "$0")"\r');
The additional \r is for carriage return line ending in Mac.
But this doesn't work. The command doesn't execute just starts and over. No cd happens.
I am sure that this problem is related to line endings because when I edit the line ending (by deleting the newline and again add newline using return key) after opening the command file in Mac with TextEdit, it works.
How can I solve this in write method?
You should try writing '\n' instead of '\r'. Carriage returns were used in pre OSX machines only.
If you wanna visually see the line endings you could open up vim on the Mac and type :set list. All new lines will appear like $ and carriage returns as ^M. You should only be seeing $ if this is an OSX machine.

error while trying to run a script in cygwin

unexpected end of file.
now I did a search on the error and I understand that my script file (that was created in windows) has wrong endings. I also read that I can use dos2unix command on the file to fix this.
however, I've tried that and cygwin tells me:
-bash: dos2unix: command not found
other than cygwin I work on a remote unix terminal, on which my script runs fine and there is even a dos2unix command. I've used it on the script file, and tried to use the converted file in cygwin with the same unexpected end of file error.
so what are my options?
You can install dos2unix from the cygwin setup utility
But, this should work too:
sed -i 's/\r$//' file
However, "unexpected end of file" often means you have an open quote (or brace or parenthesis) with no close quote (or brace or parenthesis)

#!/usr/bin/perl is not needed to run perl in Windows, but

A similar question about the use of
#! /usr/bin/perl
has been answered. But I think I have a slightly different question, although probably still similar to people in the know given my lack of understanding of computation in general.
I don't have UNIX on my Windows so could not test the following directly, but while the shebang line is indeed not needed for me to run Perl under Windows, with the shebang line in the hello.pl, I still could NOT run the file if I move from
c:\Users\XYZ\Desktop\BegPerl
to
c:\Users\XYZ\Desktop
My script is stored under
c:\Users\XYZ\Desktop\BegPerl
My perl folder is stored under
c:\Strawberry\perl\bin\perl.exe
So my questions are:
How does Windows find "perl.exe"?
Why could Windows find hello.pl ONLY when I type perl hello.pl under c:\Users\XYZ\Desktop\BegPerl but NOT under c:\Users\XYZ\Desktop even with the shebang line included?
The answer I got about the "purpose" of the shebang line is
for UNIX-like systems to locate the executable for scripts
So, I guess the answers to my two questions might have something to do with the difference between UNIX-like systems and Windows.
By associating the pl file extension with perl.exe in the OS registry. The directory where perl.exe is should be in the system PATH.
Both should happen when you install perl but if they are not, that is what you need to do.
dir/perl script.pl or /dir/perl script.pl
Unix: The OS will search for perl in the specified path. The shebang line will not be used.*
Win: The OS will search for perl in the specified path. The shebang line will not be used.*
perl script.pl
Unix: The OS will search for perl at the paths in the PATH env var. The shebang line will not be used.*
Win: The OS will search for perl relative to the current directory and at the paths in the PATH env var. The shebang line will not be used.*
script.pl
Unix: The OS will for look for a shebang line, and execute the indicated program and arguments followed by name of the script and command line arguments.
Win: The OS will look for a file association for a file of that extension, and execute the indicated program and arguments. %1 will be replaced with the file's name. %* will be replaced with the command line arguments.
* — The shebang line will not be used by the system. Perl will actually do its own interpretation of the shebang line in case it wasn't used. This allows a -w there to take effect even when the shebang line wasn't used.

Emacs ^m end of line encoding

I was wodnering why my emacs started putting ^m at the end of every line, i know how to "fix it" but i was wondering what caused it to happen. I have been using emacs in windows for some time now and it started more recently. Does anyone know why this starts?
Most likely the reason is that the buffer is using '...-unix' coding system when the file contains Windows carriage-return/linefeed line ends. The mode line will show you the coding system in use. See 'Coding Systems' in the Emacs Manual.
Ctrl-h C
will display the coding system currently in use.
I see this happening when the file contains both \r\n and \n\r line endings. That is, someone has written broken Windows line endings to the file (\n\r).
Go through your file and look for lines that start with ^M. This implies that the carriage return was after the newline character on the previous line, which is incorrect.
If that is the case, go back to the program that generated the file and make sure that it's writing correct Windows line endings.

Resources