[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: |
Eli Zaretskii |
Subject: |
bug#64939: 30.0.50; The default auto-mode-interpreter-regexp does not match env with flags |
Date: |
Sun, 30 Jul 2023 13:03:27 +0300 |
> 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.
bug#64939: 30.0.50; The default auto-mode-interpreter-regexp does not match env with flags, Eli Zaretskii, 2023/07/30