bug#64939: 30.0.50; The default auto-mode-interpreter-regexp does not match env with flags

[Wilhelm Kirschbaum]

Eli Zaretskii <eliz@gnu.org> writes:

> > From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> > Date: Sat, 29 Jul 2023 22:08:19 +0200
> >
> >
> > A file without an extension will load ruby-mode if the first 
> > line 
> > is:
> >
> >     #!/usr/bin/env ruby
> >
> > but not when the first line is:
> >
> >     #!/usr/bin/env -S ruby -e 'puts 123'
> >
> > Is there any reason why the latter should not be matched by the 
> > default
> > `auto-mode-interpreter-regexp' value in 'files.el'?
>
> That line _is_ matched by auto-mode-interpreter-regexp:
>
>   (string-match-p auto-mode-interpreter-regexp "#!/usr/bin/env 
>   -S ruby -e 'puts 123'") => 0
>
> The problem is how to find the name of the interpreter if the 
> text
> after "/usr/bin/env" includes more than one word?  Once we start 
> using
> command-line switches and their arguments, and take into 
> consideration
> that many GNU/Linux programs can freely intersperse options and
> non-option arguments on the command line in any order, where 
> does this
> end?

I am hoping there is some way of effectively matching command-line
switches for '/usr/bin/env', but sounds like it is perhaps too 
complex?

This probably ends with a match to some common command-line 
variations
for the '/usr/bin/env' program.  It is not complete now, so make 
it
guess slightly better is perhaps appropriate?

> > A more useful example I stumbled on today while working on a 
> > language
> > server after adding:
> >
> > `(add-to-list 'interpreter-mode-alist '("elixir" 
> > . elixir-ts-mode))'
> >
> >
> >     #!/usr/bin/env -S elixir --erl "-kernel 
> >     standard_io_encoding 
> >     latin1"
>
> How about making a script that invokes elixir with those 
> arguments,
> and then augment interpreter-mode-alist to name that script 
> instead?

That is an option, but then I have to convince the maintainers of
all the packages I work on to make this change, vs my editor 
handling this.
Even locally changing the regexp means that the match index has 
changed, so
can't see this working without a patch.

If this is perhaps too much work and/or uncertainty for negligible
benefit to users, then it won't cause distress on my side :).

Wilhelm