What happens when you try to run it the way you want to run it?

Sometimes I've seen scripts fail because the shebang line has a trailing carriage return. You can find this if you run it through "od" or some other hex dump program.

$ head -1 good.pl | od -c
0000000  #   !   /   u   s   r   /   b   i   n   /   p   e   r   l  \n
0000020

$ head -1 bad.pl | od -c
0000000  #   !   /   u   s   r   /   b   i   n   /   p   e   r   l  \r
0000020 \n
0000021
[download]

You can strip out the carriage returns using perl this way:

perl -pi.bak -e 's/\r//g' my_script.pl
[download]

If the script is supposed to have some carriage return in it, this will break it, but that's unusual. If it causes a problem, the above line creates a .bak file that you can revert to.

$ head -1 edit_abi.pl | od -c
0000000  357 273 277  #  !  /  u  s  r  /  b  i  n  /  p  e
0000020   r  l \n
[download]

However, there are those odd (for me) numbers, 357 273 277 before the shebang text. What could that be? I think that this could be what is giving me the problem.

I am using the TextWrangler editor for writing the scripts, which is the light version of BBEdit.

UPDATE!

I solved the problem. Given the "odd numbers" that appeared at the beginning of the file when I run it through od, I searched what they meant and I learnt that \357\273\277 is the Byte Order Mark (BOM) for UTF-8, the encoding I was using. The text editor was just adding that invisible sequence automatically. So, I changed the encoding to UTF-8 whitout BOM (available in this text editor) and now the scripts run as expected.

I hope this can help other people. And thank you very much for your help, it was really very useful (I didn't know od, nor what hexadecimal dumper meant). Roger

That's a Byte-order mark. It looks as if your editor is trying to save your file as UTF-8. If you get rid of those, I think you'll be OK.

Thank you Kyle... you are right, that was the problem. Maybe I am going out of topic, but can I ask you which encoding do you recommend to use?

Open the file in vi or another *NIX editor and make sure that the file hasn't somehow gotten old CR-only Mac-ish line endings (or even CRLF DOS-y endings). That can be confuzzling things when the system tries to find the interpreter to exec.

The error message I get is:

 -bash: ./edit_abi.pl: cannot execute binary file

I am checking all the options you gave me...

You didn't by chance upload from a Windows box using FTP did you? If you uploaded in binary mode, it will mangle the line endings and the #! line won't make sense to the shell. If you invoke perl manually, perl is smart enough to handle both unixy and windowsy line endings.

If you did upload with FTP, try uploading again in ASCII mode.

--Pileofrogs

This is another argument why -w is far superior than use warnings;.

#!/usr/bin/perl -w
[download]

will work in situations where

#!/usr/bin/perl
use warnings;
[download]

will not :)

#!/usr/bin/perl --
[download]

I think you meant well, but you said it wrong.

FTP in binary mode does not mangle your line-endings. This mode does not even have a concept of what line endings are. It will keep everything "as is" and if the line-endings happen to be wrong for your kind of OS, they will simply remain wrong.

On the other hand, ASCII mode will try to "translate" the wrong line endings to what your box expects (actually the sender translates the data into a common 8-bit ASCII format with line endings being <CRLF> or <NL> and the receiver will translate this data in its internal format - read all about it here). Whether that is a good thing is something what remains to be seen.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

No, I wrote the scripts myself. I use the TextWrangler editor, for Mac, which is the light version of the BBEdit editor. That's why I haven't thought it was a problem of line endings; however I am checking that with the way the other sugest me...