From: Keith M. <kei...@us...> - 2008-01-17 00:38:24
|
On Wednesday 16 January 2008 21:16, Michael Kappert wrote: > > However, look what happens, if you make a very small > > alteration to that string:-- > > > > =A0 =A0$ ./test "?:(../src) (foo::bar)" > > =A0 =A0test: ?:(../src) (foo::bar) > > =A0 =A0=3D=3D=3D=3D=3D=3D^^=3D=3D=3D^=3D=3D=3D=3D=3D=3D=3D=3D=3D^^=3D= =3D=3D=3D > > > > 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=20 combination of both. A simple environment variable, which merely turns the path=20 transformation on of off just will not do. I say this, based on a=20 discussion, on this very list, which was also related to a LISP=20 expression: in that case, an ELISP expression, to be passed to the=20 embedded interpreter in Emacs, during the build of that editor. The=20 reason why the simple on/off environmental switch would not have=20 worked, on that occasion, was that the command line invoking the ELISP=20 interpreter contained not only the ELISP expression, which needed to be=20 exempt from path transformation, but also POSIX style paths, which did=20 require it. Thus, that command required a solution which would allow=20 path transformation to be on for some arguments on the command line,=20 but off for others, all within the scope of a single command=20 invocation; that requirement simply cannot me satisfied, with a simple=20 on/off selection, applying globally to the entire command line. So, the solution I'd like to propose involves *two* environment=20 variables: firstly... MSYS_PATH_TRANSFORM=3D[ON | OFF | AUTO] where `MSYS_PATH_TRANSFORM=3DON' would correspond to the present=20 behaviour, `MSYS_PATH_TRANSFORM=3DOFF' would disable it globally, and=20 `MSYS_PATH_TRANSFORM=3DAUTO' would activate the mode where a special=20 initial byte sequence would disable it for just the one argument,=20 (causing the initial signature byte sequence to be stripped away, with=20 the remainder of the argument left untouched by any transformation). In the event that MSYS_PATH_TRANSFORM is not defined, then a default=20 behaviour would be adopted; IMO, that default should be equivalent to=20 `MSYS_PATH_TRANSFORM=3DAUTO'. The second environment variable would identify the initial byte sequence=20 to be used to signify an argument which is to be exempt from the normal=20 path transformation behaviour, when `MSYS_PATH_TRANSFORM=3DAUTO' is in=20 effect; let's call it... MSYS_PATH_TRANSFORM_IGNORE=3Dkey where `key' defines that initial signature byte sequence. Again, if MSYS_PATH_TRANSFORM_IGNORE is not defined, a default `key'=20 value would be required; this could be the `?:' I suggested previously,=20 or any other suitable default agreed through further discussion on this=20 list. A possible variation on the above: it may be possible to achieve similar=20 functionality with just one environment variable, by accepting a syntax=20 such as... MSYS_PATH_TRANSFORM=3D"AUTO;IGNORE=3Dkey" (I'm not sure, but parsing that may actually be less expensive, than=20 requiring a second environment variable look-up; intuitively, I suspect=20 that this would be the case). Any further thoughts? Keith. |