#!/usr/bin/perl
----^^--------- # you have an "e" here
[download]

Also, don't use bareword filehandles, and always check that open() succeeded using its three-arg form, and use warnings; use strict; ...yadayada

use warnings;
use strict;

my $fh = open '<', 'Test1.txt'
  or die "can't open the damned file!: $!";

while (<$fh>){
    chomp; # this will remove the newline from $_
    print "I saw $_ in the file\n";
}
[download]

Call with perl script.pl, or to call it without requiring using the perl command, add:

#!/usr/bin/perl
[download]

...not:

#/user/bin/perl
----^-- remove the "e"
[download]

The OP’s experience is quite surprising to me, because, when out of curiosity I tried the same thing on my friendly neighborhood Linux box, I got this:

/user/bin/perl: bad interpreter: No such file or directory

As do I actually, but it's the only obvious thing that is wrong in the post.

Perhaps it's because it's a Mac, or some weird way OP is calling the script.

I know nothing of Mac computers, but I do know they don't have /user/bin. Without further clarification, it's a guessing game (unless a mac person can test).

G'day hchana,

Welcome to the Monastery.

As there was some discussion regarding your error message and platform, here's what I get running on "macOS Sierra 10.12.5".

$ cat > pm_1195740_bad_shebang.pl
#!/user/bin/perl
print "Hello, world!\n";
$ chmod +x pm_1195740_bad_shebang.pl
$ pm_1195740_bad_shebang.pl
-bash: ./pm_1195740_bad_shebang.pl: /user/bin/perl: bad interpreter: N
+o such file or directory
$ cat > pm_1195740_good_shebang.pl
#!/usr/bin/perl
print "Hello, world!\n";
$ chmod +x pm_1195740_good_shebang.pl
$ pm_1195740_good_shebang.pl
Hello, world!
$
[download]

You'll need to show us exactly how you're running your command. Please put that, and whatever output you get, within <code>...</code> tags.

I also tried a couple of other things to replicate your error message. Here's what I get when (a) it doesn't have execute access, and (b) I use an incorrect path; neither of which, incidentally, match your error message.

$ chmod -x pm_1195740_good_shebang.pl
$ pm_1195740_good_shebang.pl
-bash: ./pm_1195740_good_shebang.pl: Permission denied
$ ../pm_1195740_good_shebang.pl
-bash: ../pm_1195740_good_shebang.pl: No such file or directory
$
[download]

A much better shebang line, which I use, is:

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

That will use whatever your current Perl is. You won't need to change your scripts when you upgrade to a newer version of Perl.

You also really shouldn't use the system perl (/usr/bin/perl) anyway. This is provided with the OS for the OS to use. At some point you'll probably want to install one or more CPAN modules; which has the potential to break some part of the OS. Furthermore, when you next upgrade macOS, that stands a good chance of installing a newer Perl and removing the old one (including all the modules you installed). Instead, use Perlbrew: I've been using this for many years without any problems.

Finally, do follow the good advice from stevieb regarding strict, warnings and open. You can save yourself some time and effort hand-crafting '... or die "...";' messages with the autodie pragma. I'd also recommend you read "perlintro -- a brief introduction and overview of Perl".

It looks like you had a typo in your closing code tag .. the good news is that you can go back and edit your post to close the tag properly. :)

Hello hchana,

Welcome to the monastery. Try this:

Execute it as perl <name.pl> <filename>

#!usr/bin/perl
use strict;
use warnings;

while (<>) {
    print "$.\t$_"; # updating $. $.\t$_
} continue {
    close ARGV if eof;
}
[download]

Update: Adding line output from ($.) to ($.\t$_).

Read more here eof.

I have managed to get this working on my Mac. My perl scripts needed to be stored in my home directory. Also when running the code using Komodo (as your stated in your reply) you need to write: perl filename.pl. I was not stating the perl pre-fix.The following code now works. Thanks for your help

#!\usr\bin perl
use warnings;
use strict;
use diagnostics;

open(FILE, "Text1.txt");
while(<FILE>){
    print "I saw the following in Text.txt file:\n$_\n";
}
close FILE;
[download]

I think the Shebang thing, although valid, is a red herring.

Another point is that the shell is looking for open.pl, which makes me think you either have some shell alias or function in place, or Komodo's macro facility is chiming in. Where did you store your script? Is it perhaps the path where Komodo stores its macros?

I think the Shebang thing, although valid, is a red herring.

Other things may happen:

Bad interpreter, i.e. the program after #! could not be found. The Mac error message is at least similar.

/tmp>cat shebang.pl
#!/no/such/perl -w

use strict;
use warnings;

print 'Hello\n';
/tmp>chmod +x shebang.pl

/tmp>./shebang.pl
-bash: ./shebang.pl: /no/such/perl: bad interpreter: No such file or d
+irectory

/tmp>
[download]

Interpreter not executable:

/tmp>cat shebang.pl
#!/etc/passwd

use strict;
use warnings;

print 'Hello\n';pstree -al

/tmp>chmod +x shebang.pl

/tmp>./shebang.pl
-bash: ./shebang.pl: /etc/passwd: bad interpreter: Permission denied

/tmp>
[download]

Shebang not identified as such:

/tmp>cat shebang.pl

#!/usr/bin/perl -w
# ^- note: Shebang on second line, first line is empty!

use strict;
use warnings;

print 'Hello\n';
/tmp>chmod +x shebang.pl

/tmp>./shebang.pl
./shebang.pl: line 5: use: command not found
./shebang.pl: line 6: use: command not found
./shebang.pl: line 8: print: command not found

/tmp>
[download]

This also happens when there is an (invisible) Byte Order Mark (BOM) at the start of the file. What happens here?

The shell attempts to start ./shebang.pl via fork() and exec(), as usual. This will fail, because the kernel can't identify the file as binary executable or script with some interpreter (first two bytes aren't #!). At this point, a legacy mechanism in the shell kicks in. In the very early days of Unix, shell scripts did not have to have the shebang. If you chmod +x any text file and try to run it, but exec() fails, the shell will attempt to read it as a shell script. A little experiment shows this:

/tmp>echo 'pstree -Aal' >> shebang.pl

/tmp>./shebang.pl
./shebang.pl: line 5: use: command not found
./shebang.pl: line 6: use: command not found
./shebang.pl: line 8: print: command not found
init
  .
  .
  .
  |-sshd
  |   `-sshd
  |       `-sshd
  |           `-bash
  |               `-bash
  |                   `-pstree -Aal
  .
  .
  .
[download]

Update:

A little trick to ensure you don't run into the BOM trap:

/tmp>perl -e '$_=<STDIN>;print ord $_' < shebang.pl
10
/tmp>
[download]

This test must return 35 or the script does not start with the shebang. 10 is a LF, the end of the first line. 13 is CR, the end of the first line with MS-DOS or classic Mac line-endings, 32 is a space, 9 is a tab. Byte Order Marks may show up as 239 (UTF-8), 254 (UTF-16 BE), 255 (UTF-16 LE or UTF-32 LE), 0 (UTF-32 BE), 43 (UTF-7), 247 (UTF-1).

Update:

See also Re^2: Shebang behavior with perl

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Other things may happen:
Bad interpreter,

That's what I meant with "although valid". But the shebang is (or originally was) implemented in the kernel. While the IDE could execute the user script directly via exec, obviously Komodo execs an interpreter (although the wrong one)…