Re: [Mingw-msys] etags behaves differently under MSYS

[Keith M. <kei...@to...>]

Michael Chen wrote:
> I am trying to use etags to generate tag files for emacs, and the
> following command works under linux environment, but failed under
> MSYS 1.0
>
> etags --language=none --regex='/[ t]*param[ \t]+\([^ \t]+\)/\1/' \
>  blendingexample.mod
>
> Error Msg:
>
> e:\chen\programs\emacs\emacs-21.3\bin\etags.exe:
> E:/chen/programs/msys/1.0/[ t]*param[ /t]+/([^ /t]+/)//1/:
> unterminated regexp

This appears to be yet another manifestation of the automatic path
name translation, performed by MSYS when passing arguments to native
Woe32 programs, interfering with your intended purpose.  In this
case, MSYS is mistaking your --regex expression for a path name,
expressed in MSYS-POSIX form, and is "helpfully" converting it
to native Woe32 form.

Unfortunately there is no way, with existing MSYS implementations,
to override this behaviour, beyond the existing double slash hack
for passing options to brain dead M$ style programs, which don't
recognise `-' as a SWITCHAR; (and unfortunately, this hack doesn't
seem to help, in this particular case, since the reduction of the
initial slashes doesn't occur when another slash appears later in
the argument):

  $ cmd //c echo --regex='/[ t]*param[ \t]+\([^ \t]+\)/\1/'
  "--regex=D:/usr/MSYS-1.0.11/[ t]*param[ /t]+/([^ /t]+/)//1/"

  $ cmd //c echo --regex='//[ t]*param[ \t]+\([^ \t]+\)/\1/'
  "--regex=//[ t]*param[ /t]+/([^ /t]+/)//1/"

Notice how doubling the initial slash avoids the substitution of
the MSYS root path, but still leaves a malformed regex because the
extra slash is not removed; I'm convinced this is a bug in the
MSYS path translation logic.

Also notable is that the backslash of the `\1' substitution term
has been transliterated, becoming `/1', and similarly for the `\t'
substitutions, becoming `/t'; yet another bug.

Do notice that this same problem affects sed regexes, if you use
a non-MSYS implementation of sed.  In that case, it is often
possible to work around the issue, by choosing an alternative
delimiter character to `/', for regexes; e.g. parsing the text of
this message, (before pasting in this example):

  $ sed -n '\?trans?p' mail.txt
  name translation, performed by MSYS when passing ...
  MSYS path translation logic.
  has been transliterated, becoming `/1', ...

I'm not an emacs user, so I don't know if a similar workaround is
possible with etags:

  $ cmd //c echo --regex='\?[ t]*param[ \t]+\([^ \t]+\)?\1?'
  "--regex=\?[ t]*param[ \t]+\([^ \t]+\)?\1?"

If not, then I don't think you are going to have much success
using etags in MSYS, until we can develop a suitable fix for this
long-standing bug, unless you can build etags as an msys-1.0.dll
dependent application.

Regards,
Keith.