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>
>> Cc: 64939@debbugs.gnu.org
>> Date: Sun, 30 Jul 2023 10:28:14 +0200
>> 
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 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?
>
> How can we do that without incurring non-trivial maintenance 
> costs?
> 'env' is being actively developed; e.g., the old version I have 
> where
> I'm typing this doesn't even have the -S option.  Are we 
> supposed to
> track every new command-line option added to 'env', and update 
> our
> code accordingly?  That is even impractical, because someone 
> could use
> 2-year old Emacs with Coreutils released just yesterday.

No, I don't think we should track every command-line option added, 
but
just allow to match command-line options for env ( maybe this is 
the
non-trivial part).  I don't understand why it will have an impact 
for
someone who is using a version 5+ year old version of Coreutils.

If it was possible for a user to add configuration to 
set-auto-mode
script files like the ones mentioned above I think this will be 
less of
an issue.