Web lists-archives.com

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 
variables: firstly...


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 
such as...


(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