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

Replies are listed 'Best First'.
Re^2: /usr/bin/perl^M: bad interpreter: by JavaFan (Canon) on Dec 03, 2009 at 08:59 UTC
`#!/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 `#!`?	[reply] [d/l] [select]
Re^3: /usr/bin/perl^M: bad interpreter: by BrowserUk (Patriarch) on Dec 03, 2009 at 09:25 UTC
Isn't the point that if the original shebang (on *nix) is: `#!/usr/bin/perl --` [download] And the file gets downloaded to win in binmode it will become: `#!/usr/bin/perl --^M` [download] 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. RIP PCW It is as I've been saying!(Audio until 20090817)	[reply] [d/l] [select]
Re^3: /usr/bin/perl^M: bad interpreter: by Bloodnok (Vicar) on Dec 03, 2009 at 16:33 UTC
'--' 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 :-))	[reply] [d/l]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks