I ran some additional tests to what I showed in the OP and in Re^2: shebang problem on openSUSE:

ken@ibm-laptop:~/tmp> /usr/bin/env perl -e 'print "Hello, world!"'
Hello, world!ken@ibm-laptop:~/tmp>
[download]

ken@ibm-laptop:~/tmp> /usr/bin/env perl -le 'print "Hello, world!"'
Hello, world!
[download]

ken@ibm-laptop:~/tmp> which env
/usr/bin/env
[download]

ken@ibm-laptop:~/tmp> env perl -e 'print "Hello, world!"'
Hello, world!ken@ibm-laptop:~/tmp>
[download]

ken@ibm-laptop:~/tmp> env perl -le 'print "Hello, world!"'
Hello, world!
[download]

ken@ibm-laptop:~/tmp> env perl -l -e 'print "Hello, world!"'
Hello, world!
[download]

ken@ibm-laptop:~/tmp> env perl -e 1
ken@ibm-laptop:~/tmp>
[download]

This all suggests that env is parsing its arguments correctly. While it doesn't provide an answer to the shebang issue I'm experiencing, it does perhaps narrow down the causes.

Incidentally, this came up on PerlMonks just the other week: How do I use 'which' in the hash-bang line?.

Thanks for digging that up. I've been traveling a lot over the last month or two, not always had access to computers and/or networks, and have missed many posts on this site.

— Ken

A search on DuckDuckGo brings up some relevant results. There was some article/discussion on Perl specific resource, outside of Stack Overflow, but I cannot find or remember it.

In env perl -1, env tries to find a file to execute named perl -l. It is not found, hence the error. OTOH perl -l parses the run time options by itself so there is no problem there.

Thanks for replying.

"A search on DuckDuckGo brings up some relevant results."

That is, in fact, the search engine I used. Could you post the URL you used which returned the "relevant results". I seached for "shebang perl openSUSE", which ended up as this URL: https://duckduckgo.com/?q=shebang+perl+openSUSE&t=opensuse&ia=qa.

I didn't see any results where 'perl -l' (or 'perl -w' or similar) was treated as a single filename containing a space character. As I wrote that, I thought I might try the same code as before with this shebang line:

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

When run, that now produces:

ken@ibm-laptop:~/tmp> test_shebang.pl
/usr/bin/env: perl -w: No such file or directory
[download]

I checked "man env" and subsequently, from the information it suplied, "info '(coreutils) env invocation'" and http://www.gnu.org/software/coreutils/manual/coreutils.html#env-invocation. All show an invocation of this form:

env [option]… [name=value]… [command [args]…]
[download]

As far as I can see, none mention anything special about the space after "command".

I've been using shebang lines like this for over a decade. I would have posted dozens (if not hundreds) of scripts on this site using "#!/usr/bin/env perl -l" without a single complaint.

If 'perl -l' is being interpreted as a single filename (containing a space character), that would be most unusual behaviour and I would hope there would be a way to turn it off.

— Ken

Hi

See perlrun , when  #!/usr/bin/env perl -l doesn't work use

#!/bin/sh
#! -*-perl-*-
eval 'exec perl -x -wS $0 ${1+"$@"}'
    if 0;
[download]

Also see https://www.in-ulm.de/~mascheck/various/shebang/#splitting which says

Splitting arguments

A very few systems deliver only the first argument, some systems split
+ up the arguments like a shell to fill up argv[],
most systems deliver all arguments as a single string. See the table b
+elow. I noticed that for Linux (delivering all arguments as one strin
+g),
a patch to split up was suggested on the Linux kernel mailing list (de
+ad link, try this page, archive.org), followed by a discussion of som
+e portability issues.
[download]

See also https://unix.stackexchange.com/questions/361794/why-am-i-able-to-pass-arguments-to-usr-bin-env-in-this-case?rq=1, https://stackoverflow.com/questions/4303128/how-to-use-multiple-arguments-for-awk-with-a-shebang-i-e...

I had searched for "shebang env perl switch".

... perl -l parses the run time options by itself ...

I meant perl the interpreter parses the options, not perl -l.