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

[Wilhelm Kirschbaum <wkirschbaum@gmail.com>]

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