Re: [Mingw-msys] forking issue on Windows XP?
On Wednesday 16 January 2008 21:16, Michael Kappert wrote:
> > However, look what happens, if you make a very small
> > alteration to that string:--
> > $ ./test "?:(../src) (foo::bar)"
> > test: ?:(../src) (foo::bar)
> > ======^^===^=========^^====
> > Close to what you want, but not quite there.
> Ok! Following your example I found a way to modify the lisp expr
> such that it's still valid but does not get replaced. So at least
> we have a workaround by manually editing the Makefile.
That's good; perhaps you could share the solution?
> > Additionally, while I've suggested `?:' as the signature tag, the
> > user population should be given an opportunity to discuss that, and
> > to agree on any final preferred sequence.
> CLISP's vote goes to the environment variable solution (or implement
> both :^))
On further reflection, I'm leaning towards a solution which is indeed a
combination of both.
A simple environment variable, which merely turns the path
transformation on of off just will not do. I say this, based on a
discussion, on this very list, which was also related to a LISP
expression: in that case, an ELISP expression, to be passed to the
embedded interpreter in Emacs, during the build of that editor. The
reason why the simple on/off environmental switch would not have
worked, on that occasion, was that the command line invoking the ELISP
interpreter contained not only the ELISP expression, which needed to be
exempt from path transformation, but also POSIX style paths, which did
require it. Thus, that command required a solution which would allow
path transformation to be on for some arguments on the command line,
but off for others, all within the scope of a single command
invocation; that requirement simply cannot me satisfied, with a simple
on/off selection, applying globally to the entire command line.
So, the solution I'd like to propose involves *two* environment
MSYS_PATH_TRANSFORM=[ON | OFF | AUTO]
where `MSYS_PATH_TRANSFORM=ON' would correspond to the present
behaviour, `MSYS_PATH_TRANSFORM=OFF' would disable it globally, and
`MSYS_PATH_TRANSFORM=AUTO' would activate the mode where a special
initial byte sequence would disable it for just the one argument,
(causing the initial signature byte sequence to be stripped away, with
the remainder of the argument left untouched by any transformation).
In the event that MSYS_PATH_TRANSFORM is not defined, then a default
behaviour would be adopted; IMO, that default should be equivalent to
The second environment variable would identify the initial byte sequence
to be used to signify an argument which is to be exempt from the normal
path transformation behaviour, when `MSYS_PATH_TRANSFORM=AUTO' is in
effect; let's call it...
where `key' defines that initial signature byte sequence.
Again, if MSYS_PATH_TRANSFORM_IGNORE is not defined, a default `key'
value would be required; this could be the `?:' I suggested previously,
or any other suitable default agreed through further discussion on this
A possible variation on the above: it may be possible to achieve similar
functionality with just one environment variable, by accepting a syntax
(I'm not sure, but parsing that may actually be less expensive, than
requiring a second environment variable look-up; intuitively, I suspect
that this would be the case).
Any further thoughts?
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Mingw-msys mailing list