Subject: bug#31215: closed (Re: bug#31215: coreutils env fails in a bash shebang)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 19 Apr 2018 03:12:03 +0000

Your bug report

#31215: coreutils env fails in a bash shebang

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
31215: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31215
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#31215: coreutils env fails in a bash shebang
From: Eric Blake <[email-masked]>
To: William Schmidt <[email-masked]>, [email-masked]
Date: Wed, 18 Apr 2018 22:11:01 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

tag 31215 notabug
thanks

On 04/18/2018 07:18 PM, William Schmidt wrote:
> I think I've found a bug in *coreutils*, *env*.
> 
> Linux debian 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
> x86_64 GNU/Linux
> 
> All my Perl scripts contain either of these shebangs:
> 
> #!/usr/bin/env perl -w
> or
> #!/usr/bin/env perl -wd

That is inherently non-portable.  On some operating systems (such as
GNU/Linux), the #! line is limited to EXACTLY ONE argument beyond the
name of the executable.  But you are trying to shoehorn two arguments
("perl" and "-w").  Just because it may have worked on some other
operating systems does not make it portable.

There may be ways to do what you want by telling perl to turn on -w or
-wd in subsequent lines of the script, or you can rewrite the #! line to
use /path/to/perl instead of trying to make env do the work.  Or perldoc
even includes some arcane formulas for using #!/bin/sh as the start, and
then exec into perl with as many desired arguments as you want
(including by using env to locate perl), as the first line when
interpreted by sh, while that exec line is skipped by perl.

But as this is a limitation of your operating system's handling of #!
and not a bug in env, there's nothing we can do about it in coreutils'
env.  So I'm closing this bug.

> Both of these shebangs work correctly in macOS 10.13.3 with the native perl
> from Apple and perlbrew perl. That is where I do most of my perl work but
> now I need to move those scripts to debian, without changing the shebangs.
> Is this a bug in *env*, something in bash or pilot error?

Pilot error, as you have used two different OS with different #!
handling rules.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Subject: coreutils env fails in a bash shebang
From: William Schmidt <[email-masked]>
To: [email-masked]
Date: Wed, 18 Apr 2018 19:18:01 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

I think I've found a bug in *coreutils*, *env*.

Linux debian 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
x86_64 GNU/Linux

All my Perl scripts contain either of these shebangs:

#!/usr/bin/env perl -w
or
#!/usr/bin/env perl -wd

When I attempt to run a Perl script with either of these shebangs in debian
I get:

/usr/bin/env: ‘perl -w’: No such file or directory

It is not perl that can't be found; it is either *env*'s or *bash*'s
handling of the argument. If I remove the *-w* and/or the *-wd* arguments
the scripts execute, but of course, without the benefit of those switches.

The man page for *env* asserts that any command may take an argument. I
have tried every way I can think of to quote the *-w* and the *-wd* but
*env* is treating these perl command line arguments as filenames, and since
they aren't files, renders that error message. I'm running the latest
*coreutils* as in this apt-get fragment:

Reading package lists... Done
Building dependency tree
Reading state information... Done
coreutils is already the newest version (8.26-3).

Both of these shebangs work correctly in macOS 10.13.3 with the native perl
from Apple and perlbrew perl. That is where I do most of my perl work but
now I need to move those scripts to debian, without changing the shebangs.
Is this a bug in *env*, something in bash or pilot error?

Regards,
T.W. Schmidt