Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

/usr/bin/perl^M: bad interpreter:

by venuka (Initiate)
on Dec 03, 2009 at 04:51 UTC ( #810745=perlquestion: print w/ replies, xml ) Need Help??
venuka has asked for the wisdom of the Perl Monks concerning the following question:

i integrate sphinx with asterisk following these steps

http://www.syednetworks.com/asterisk-integration-with-sphinx-voice-recognition-system

when i start the sphinx server in the terminal by typing

#/usr/local/bin/sr_server &

i got this error message

[root@localhost ~]# /usr/local/bin/sr_server &

[1] 3885

[root@localhost ~]# bash: /usr/local/bin/sr_server: /usr/bin/perl^M: bad interpreter: No such file or directory

1.what is the reason for that error?

2.how can i fix it ?

( os fedora core 7)

Comment on /usr/bin/perl^M: bad interpreter:
Select or Download Code
Re: /usr/bin/perl^M: bad interpreter:
by merlyn (Sage) on Dec 03, 2009 at 05:03 UTC
    I'm betting that three things were involved here:
    1. FTP performed incorrectly in binary mode, not text mode
    2. Windows
    3. Mac or Unix
    The first item there is your key. Don't forget to set "text" mode when FTP'ing.

    -- Randal L. Schwartz, Perl hacker

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Re: /usr/bin/perl^M: bad interpreter:
by brap (Pilgrim) on Dec 03, 2009 at 05:03 UTC
    The comments on that page mention that same error. The resolution provided is to run the dos2unix /usr/local/bin/sr_server.dat command.

    Windows and Unix systems use different end-of-line characters. The ^M bit you're seeing is from a Windows system, and isn't needed on the Unix system.

      Thanks for the dos2unix tip as it solved a problem for me.
Re: /usr/bin/perl^M: bad interpreter:
by ww (Bishop) on Dec 03, 2009 at 05:06 UTC
    The bad interpreter seems to mean that bash or sr_server can't find perl at /usr/bin/perl (or that your perl is corrupt).

    You might try which (or where or whatever your OS/distro decrees to find perl in some other location; you might also try perl -v from /usr/bin/perl/ and see if it spits back version info and a short note on finding help.

      No, it means that /usr/bin/perl^M cannot be found. Please read the error message correctly. The ^M is the key to the entire problem, it's not something that just can be ignored.
Re: /usr/bin/perl^M: bad interpreter:
by codeacrobat (Chaplain) on Dec 03, 2009 at 07:13 UTC
    get rid of ^M with
    dos2unix /usr/local/bin/sr_server # or more perlish perl -pi -e 'tr[\r][]d' /usr/local/bin/sr_server
    see also crlf to \n

    print+qq(\L@{[ref\&@]}@{['@'x7^'!#2/"!4']});
Re: /usr/bin/perl^M: bad interpreter:
by Anonymous Monk on Dec 03, 2009 at 07:38 UTC
    If you end you shebang with " --", you don't have to worry about that
    #!/usr/bin/perl --
      #!/usr/bin/perl -- works for me, but #!/usr/bin/perl ^M -- doesn't.

      On what OS does -- tell the kernel to chop off a character from the path following the #!?

        Isn't the point that if the original shebang (on *nix) is:

        #!/usr/bin/perl --

        And the file gets downloaded to win in binmode it will become:

        #!/usr/bin/perl --^M

        And the ^M will then be ignored!


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        '--' isn't used to 'chop off' any characters - when used, as BrowserUk implied earlier, it flags the end of the CLI option list to the script/executable and thus whatever follows (in this case the ^M) is/are arguments to the script/executable.

        The 'classic' usage is when grep'ping for a string containing dash(es) &/or minus(es) e.g. grep -- this-string some_file - which tells grep that 'this-string' is a string and not a malformed CLI option.

        A user level that continues to overstate my experience :-))
Re: /usr/bin/perl^M: bad interpreter:
by sonrisitas (Initiate) on Aug 12, 2011 at 19:01 UTC
    I have the same problem when I execute ./program.pl but this problem fixed when I execute perl program.pl Try...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://810745]
Approved by GrandFather
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2014-11-01 04:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (227 votes), past polls