in reply to running scripts in Mac OS 10.4

Thank you very much for your answers. As I thought, it seems that it isn't a problem of line endings. I run the script through od and I get the following:

$ 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

Replies are listed 'Best First'.
Re^2: running scripts in Mac OS 10.4
by kyle (Abbot) on Jun 25, 2008 at 20:40 UTC

    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.

[reply]
      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?
[reply]
        The recommended encoding would probably be ASCII. ;^)

        The problem is not so much the use of utf8 encoding for the script itself (it is possible to put "wide characters" in the script, along with use ut8;). Rather, it is the unnecessary and presumptuous inclusion of the initial byte order mark (BOM), which many people believe should not happen with utf8 encoded files, because byte order is never an issue for utf8 data.

[reply]
[d/l]
        Anyone knowingly using anything other than ASCII for their source code is a damned fool. If you need non-ASCII data, such as for text that you'll spit out at the user, that should live elsewhere in a resource file. Not only will that do away with problems like the one you're having, it will also mean that things don't break when someone using a different character set edits your code*, and you'll already be half way to supporting multiple languages.

        * any bleating about "everyone should use UTF-8" will be ignored because regardless of whether people should use it the fact is that lots of people don't use it, and you want to keep the "barrier to entry" for them submitting patches that fix your bugs as low as possible.

[reply]

In Section Seekers of Perl Wisdom