On Sat, Jul 19, 2025 at 12:46 AM Philip Guenther <guenther@gmail.com> wrote:
>
> On Fri, Jul 18, 2025 at 11:33 PM Omar Polo <op@omarpolo.com> wrote:
> >
> > Matthias Kilian <kili@outback.escape.de> wrote:
> > > Hi,
> > >
> > > On Fri, Jul 18, 2025 at 06:23:45PM +0200, Manuel Giraud wrote:
> > > > For example, one could make the following silly script:
> > > >
> > > > #!/usr/bin/env -S cat -b -e
> > >
> > > In addition to what other people already said, that #!/usr/bin/env
> > > thing in general is an absolute antipattern IMHO.
> >
> > no opinion on -S, but i'm curious about this, why do you think it's an
> > antipattern?
> >
> > curious because i've used it a bit, it's handy for stuff like perl or
> > awk that may be at different paths (/bin vs /usr/bin vs /usr/local/bin
> > depending on the OS, while env is *generally* always at /usr/bin/env)
>
> In my experience, it works when _any_ install of the required
> interpreter is acceptable and fails when there may be multiple
> installs, only some of which will be able to run the script.
>
> I.e, if the OS supplied version would work and you don't want to have
> to update the #! line at install time then sure, but if you can't
> depend on the OS supplied version and are expecting the user to have
> the required, newer version earlier in their $PATH, then you will come
> to grief when it gets invoked via a context where PATH isn't set as
> expected and things blow up.  I have seen the bug reports for the
> latter as a developer at two different commercial software companies
> and personally had to fix it at one of them.

Let me put this more clearly:

I believe this option to be an attractive nuisance: it's useful
exactly when it could have been handled by pre-install
flexibility/patching and dangerous otherwise.  It is hostile to
robust, reliable behavior.


Philip Guenther