bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64939: 30.0.50; The default auto-mode-interpreter-regexp does not ma


From: Wilhelm Kirschbaum
Subject: bug#64939: 30.0.50; The default auto-mode-interpreter-regexp does not match env with flags
Date: Sun, 30 Jul 2023 12:27:38 +0200
User-agent: mu4e 1.9.3; emacs 30.0.50


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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]