Re: [Mingw-msys] Strange path transformation with Emacs
On Wednesday 17 September 2008 17:59:03 Роман Донченко wrote:
> > It's because the MSYS runtime treats arguments starting with - as
> > options, and looks inside them for POSIX-y paths. It skips over
> > the character immediately following the - and then sees the
> > second slash which looks like the start of a POSIX path,
> > triggering the translation.
> > In response to this bug in the past it
> > has been proposed to modify the MSYS runtime to recognise an
> > environment variable that could be used to disable translation,
> > but I don't think anyone has implemented such a feature.
Yes, this is a bug, and yes, that naive solution has been proposed,
(but never formally, via a bug submission, IIRC). However...
> Even if such a feature was implemented, it wouldn't help, since the
> rest of the configure script would be broken, e.g. the translation
> of /etc/xml/catalog. 8=[
Exactly. I have never been in favour of such a naive solution, for
this very reason. Existing behaviour is correct, in > 80% of cases;
if you turn it off globally, (which is what the naive option does),
to capture < 20% of the cases, then you break the > 80%, and if you
happen to have a hybrid case, (which seems to be more common, in the
instances where this has cropped up before, AFAICT), then you haven't
actually achieved anything even remotely useful.
> Perhaps a fine-tuning of the path detection algorithm could help in
> this case.
What I think is actually required, is some form of half-way-house.
Perhaps some specific argument prefix, which MSYS would recognise as
a "Hands off! This isn't a path" operator; it would then strip away
the prefix, passing the remainder of the argument unchanged. (Of
course, developers would then need to insert that prefix at the
appropriate places, within their build scripts, ideally letting
configure scripts do so automatically where required).
IMO, such a solution would be much more useful than a global, "never
interpret MSYS paths", triggered by some environment variable. The
two are not mutually exclusive; the environment variable alone will
*definitely* not suffice, the special prefix alone may well do so.
However, it would be perfectly feasible to support both.
On Wednesday 17 September 2008 18:10:20 Brian Dessent wrote:
> I'm not able to test this but maybe something like the following
> [...patch attached...] would suffice.
This might suffice for the very specific case reported here, but is
nowhere near generalised enough; there are other patterns which also
are erroneously identified as paths, and translated into garbage.
We need a formal bug report for this, (on the tracker, please), so
that an appropriate solution can be developed, agreed, and followed
through to implementation. Given the number of previous reports of
similar issues, on this list, I'd suggest that this should merit
consideration as a "highest priority" issue.
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Mingw-msys mailing list