Odd behaviour on Mac OS X Lion

T

Trudge

I've been having some odd behaviour lately on our work computer running the installed Apple Perl. I have the following few lines of code:

#!/usr/bin/perl
BEGIN
{
open (STDERR,">>$0-err.txt");
print STDERR "\n",scalar localtime,"\n";
}
use strict;
use warnings;

my $ext="pdf";
my $Source = "/Desktop/test1";
my $Destination = "/Desktop/test2";

print "Now running $0 ...\n";
print "\$ext: $ext\n";
print "\$Source: $Source\n";
print "\$Destination: $Destination\n";

However, there is no output to the Terminal window, and no entry is made in the log file. There should at least be a date/time stamp.

If I remove the 'shebang' line, the script outputs as expected, and an entry is made in the log file indicating the timestamp.

What gives?
 
D

Dave Saville

I've been having some odd behaviour lately on our work computer running the installed Apple Perl. I have the following few lines of code:

#!/usr/bin/perl

What gives?

I take it that *is* the correct path to your perl executable?
 
A

Alan Curry

running the installed Apple Perl. I have the following few lines of
code:

Heh. Yes. I have several other scripts on this box all running just fine.

There's probably something extra in the #! line, like a ^M or some Unicode
fluff, that you're not seeing because you're using the wrong editor.
 
T

Trudge

Quoth Trudge <[email protected]>:













Are you running it with

    perl script

or with

    ./script

? If the latter, does it make a difference if you invoke perl directly?

I ask because I wonder if something is inserting a UTF-8 BOM (or some
other such invisible character) at the beginning of the file, which is
causing the kernel not to recognise the #!. Of course, I would then
expect you to get some sort of error message...

Otherwise, start with something completely minimal, like

    #!/usr/bin/perl
    1;

and add pieces of the original script until it stops working. If you get
as far as replacing the whole script, compare the two files with 'cmp'
to see if they are actually identical, and if they aren't hex-dump them
both to see what the difference is.

Ben

I'm running 'perl -f test.pl', but I did try your suggestion of
'perl ./test.pl' with identical results.

I'll now try your 2nd one and build it a line at a time.

btw, I'm using TextWrangler with 'Invisibles' turned on but don't see
anything strange.
 
T

Trudge

I'm running 'perl -f test.pl', but I did try your suggestion of
'perl ./test.pl' with identical results.

I'll now try your 2nd one and build it a line at a time.

btw, I'm using TextWrangler with 'Invisibles' turned on but don't see
anything strange.

OK, this is very strange. According to TextWrangler this is my code
for perl_test.pl:

#!/usr/bin/perl
BEGIN
{
open (STDERR,">>$0-err.txt");
print STDERR "\n",scalar localtime,"\n";
}

$|=1;
use strict;
use warnings;

my $Source="/Users/prepress/Desktop/northbay_three";
my $Destination="/Users/prepress/Desktop/northbay_two";
my $ext="pdf";
my $f;
my @pdfs=();

print "Now runnng $0.\n";
print "\$Source: $Source\n";
print "\$Destination: $Destination\n";
print "\$ext: $ext\n";


*But* according to cat it is really:
Prepress-Mac-Pro:scripts prepress$ cat perl_test.pl
Prepress-Mac-Pro:scripts prepress$ n";op/northbay_two";

And then cmp tells me:
Prepress-Mac-Pro:scripts prepress$ cmp perl_test.pl perl_test.1.pl
perl_test.pl perl_test.1.pl differ: char 2, line 1

Ben, it looks like you may have hit on the culprit. Where do I go from
here?
 
M

Michael Vilain

Trudge said:
OK, this is very strange. According to TextWrangler this is my code
for perl_test.pl:

#!/usr/bin/perl
BEGIN
{
open (STDERR,">>$0-err.txt");
print STDERR "\n",scalar localtime,"\n";
}

$|=1;
use strict;
use warnings;

my $Source="/Users/prepress/Desktop/northbay_three";
my $Destination="/Users/prepress/Desktop/northbay_two";
my $ext="pdf";
my $f;
my @pdfs=();

print "Now runnng $0.\n";
print "\$Source: $Source\n";
print "\$Destination: $Destination\n";
print "\$ext: $ext\n";


*But* according to cat it is really:
Prepress-Mac-Pro:scripts prepress$ cat perl_test.pl
Prepress-Mac-Pro:scripts prepress$ n";op/northbay_two";

And then cmp tells me:
Prepress-Mac-Pro:scripts prepress$ cmp perl_test.pl perl_test.1.pl
perl_test.pl perl_test.1.pl differ: char 2, line 1

Ben, it looks like you may have hit on the culprit. Where do I go from
here?

On BBEdit, it will show the line endings. They should be Unix-style
endings. Just a SWAG, but is your file CRLF (Windows) line endings?

Try creating the file in vi. That will only create UNIX style line
endings.
 
T

Trudge

Quoth Trudge

Do you know what -f does?



cat is a very bad tool for examining files. At least use less; something
like od would be better.

It looks to me as though this file has Apple line-endings (\015) rather
than Unix (\012). This means that as far as perl is concerned your file
is one very long line, which happens to all be a comment. If you remove
the #!, it is no longer all a comment, so it works properly.


That's interesting: I would have expected something like 'char 16'. Is
there some other difference? Look at the file with od.


Throw away TextWrangler and get a real text editor.

Ben

Heh. Why did I know you would say that :)

OK, based on yours and Michael's *suggestion* I'll switch to another editor..

btw, TextWrangler was set to Mac line endings. Right on Ben.

Thank you all who responded to this thread. Unless something else weird happens, I would consider this post SOLVED.
 
J

Jim Gibson

Ben Morrow said:
Throw away TextWrangler and get a real text editor.

TextWrangler /is/ a real editor, one of the best on the Mac platform.

In this case, the person using TextWrangler can use the 'File > Hex
Dump Front Document' menu option to see what characters are in his
file. If line endings are a problem, he can use the 'Edit > Document
Options' menu selection to change the line endings for the whole file.
If some other set of characters is the problem, he can use the 'Text >
Zap Gremlins' option to modify or delete non-ASCII, control, or null
characters.
 
M

Michael Vilain

Jim Gibson said:
TextWrangler /is/ a real editor, one of the best on the Mac platform.

In this case, the person using TextWrangler can use the 'File > Hex
Dump Front Document' menu option to see what characters are in his
file. If line endings are a problem, he can use the 'Edit > Document
Options' menu selection to change the line endings for the whole file.
If some other set of characters is the problem, he can use the 'Text >
Zap Gremlins' option to modify or delete non-ASCII, control, or null
characters.

BBEdit, TextWrangler's big brother, allows you to change the file's line
endings between UNIX (\n), Mac (\r), and Windows (\r\n) by selecting the
type at the bottom of the file's window.

I just downloaded TextWrangler 4.01 and it has the same feature. Unless
you like TextWrangler more than MacVim or Emacs, it's time to RTFM and
find out the features of the tool your using.
 
I

ilovelinux

I've been having some odd behaviour lately on our work computer running the installed Apple Perl. I have the following few lines of code:

#!/usr/bin/perl
BEGIN
{
        open (STDERR,">>$0-err.txt");
        print STDERR "\n",scalar localtime,"\n";
}

use strict;
use warnings;

1) I would switch the BEGIN block and the use strict & warnings.
2) If, in the hashbang line, /usr/bin/perl is followed by a carriage
return (^M) the script will not run. That's why I *always* add a '-w'
to the hashbang line of Perl scripts:
#!/usr/bin/perl -w
That makes the script independent of the line endings.
 
T

Tim McDaniel

1) I would switch the BEGIN block and the use strict & warnings.
Yes.

2) If, in the hashbang line, /usr/bin/perl is followed by a carriage
return (^M) the script will not run. That's why I *always* add a '-w'
to the hashbang line of Perl scripts:
#!/usr/bin/perl -w
That makes the script independent of the line endings.

Please let me check to see if I understand correctly. I think the
idea is that UNIX-like kernels will look for "#!" as the first two
bytes, and if found, will skip any space characters immediately after
it, then read bytes up to a space character and use that as the name
of the executable. So if you have a bad line terminator on the first
line, the "[space]-w" will insulate the executable name from it so at
least the kernel will still get the correct executable and be able to
run it -- that is, instead of trying to exec /usr/bin/perl\r, it'll
run /usr/bin/perl. It may pass "-w\r" and maybe more characters as
the first command-line argument to Perl. "-w", then, is just because
you need a valid option (so you can type a space) that happens not to
be harmful.

Is that right?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top