Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

open and read text file

by hchana (Acolyte)
on Jul 21, 2017 at 20:01 UTC ( [id://1195740] : perlquestion . print w/replies, xml ) Need Help??

hchana has asked for the wisdom of the Perl Monks concerning the following question:

I am trying to open and print the contents of a text file I've named 'Text1.txt' which is in my perl folder. I'm running the code below using Komodo on my Mac Book Pro but it is not working, I keep getting the message "/bin/sh: command not found". I'm new to Perl as they come, so could my error be explained in a simple manner. Thanks in advance.?

#!/user/bin/perl open(FILE, "Text1.txt"); while(<FILE>){ print "I saw $_ in Text1.txt\n"; } close FILE;

Replies are listed 'Best First'.
Re: open and read text file
by stevieb (Canon) on Jul 21, 2017 at 20:08 UTC
    #!/usr/bin/perl ----^^--------- # you have an "e" here

    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"; }

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



    #/user/bin/perl ----^-- remove the "e"

      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).

        A reply falls below the community's threshold of quality. You may see it by logging in.
Re: open and read text file
by kcott (Archbishop) on Jul 22, 2017 at 03:13 UTC

    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 > #!/user/bin/perl print "Hello, world!\n"; $ chmod +x $ -bash: ./ /user/bin/perl: bad interpreter: N +o such file or directory $ cat > #!/usr/bin/perl print "Hello, world!\n"; $ chmod +x $ Hello, world! $

    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 $ -bash: ./ Permission denied $ ../ -bash: ../ No such file or directory $

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

    #!/usr/bin/env perl

    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".

    — Ken

Re: open and read text file
by talexb (Chancellor) on Jul 21, 2017 at 20:18 UTC

    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. :)

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Re: open and read text file
by thanos1983 (Parson) on Jul 21, 2017 at 20:10 UTC

    Hello hchana,

    Welcome to the monastery. Try this:

    Execute it as perl <> <filename>

    #!usr/bin/perl use strict; use warnings; while (<>) { print "$.\t$_"; # updating $. $.\t$_ } continue { close ARGV if eof; }

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

    Read more here eof.

    Seeking for Perl wisdom...on the process of learning...not there...yet!

      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 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;
Re: open and read text file
by soonix (Canon) on Jul 23, 2017 at 18:35 UTC

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

    I know next to nothing about Komodo except that it's an IDE. But: the error message clearly indicates that it comes from /bin/sh, although you say that you run it using Komodo. This means to me Komodo chose the shell, instead of Perl, for executing your script. Most IDEs use the file name extension for that desision. How did you name your script? Did you perhaps name it something like (which might trick Komodo into thinking it's a Shell script)? If it's not that, you need to look up how Komodo decides which Interpreter to use, and change that accordingly.

    Another point is that the shell is looking for, 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?

    TL;DR: Store your script somewhere like /home/hchana/exercises/
      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 #!/no/such/perl -w use strict; use warnings; print 'Hello\n'; /tmp>chmod +x /tmp>./ -bash: ./ /no/such/perl: bad interpreter: No such file or d +irectory /tmp>

      Interpreter not executable:

      /tmp>cat #!/etc/passwd use strict; use warnings; print 'Hello\n';pstree -al /tmp>chmod +x /tmp>./ -bash: ./ /etc/passwd: bad interpreter: Permission denied /tmp>

      Shebang not identified as such:

      /tmp>cat #!/usr/bin/perl -w # ^- note: Shebang on second line, first line is empty! use strict; use warnings; print 'Hello\n'; /tmp>chmod +x /tmp>./ ./ line 5: use: command not found ./ line 6: use: command not found ./ line 8: print: command not found /tmp>

      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 ./ 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' >> /tmp>./ ./ line 5: use: command not found ./ line 6: use: command not found ./ line 8: print: command not found init . . . |-sshd | `-sshd | `-sshd | `-bash | `-bash | `-pstree -Aal . . .


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

      /tmp>perl -e '$_=<STDIN>;print ord $_' < 10 /tmp>

      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).


      See also Re^2: Shebang behavior with perl


      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)…