Greg Chicares wrote:
[citing my example of a technique for locating the MSYS root]
> On 2005-10-3 13:40 UTC, Keith MARSHALL wrote:
> [quoting someone else]
That someone else was Lennart Borgman. Apologies for forgetting
to add an appropriate citation; (of course, if Lotus Notes was even
10% as capable as kmail, I wouldn't be required to remember such
detail -- this has to be the most incapable and user hostile
email client on the planet :-(
> Doesn't this solve a different problem than the OP posed? His method
> could be incorporated into a program that might be run from msw
> 'explorer'; I'm guessing that's how it's meant to be used. It tries
> to determine whether MSYS is installed, from outside the MSYS shell.
I believe that is, in fact, the case. But, why would you need to do
this? If you have MSYS installed, then presumably YOU know it; to
run a package configurator which requires the sort of environment
provided by MSYS, then you would run it from an MSYS shell. The
configure script may need to identify this environment when it is
running, but, IMHO, it is rightly incumbent on the USER to choose
this environment, BEFORE starting the configure script; it should
NOT be the responsibility of the script to go searching for some
environment, other than that in which it is originally invoked, in
which it might be able to run.
> Your script above seems to decide whether the shell it's run in is
> MSYS's bash. If I understand that correctly, then wouldn't it be more
> straightforward and reliable to use 'uname -s' and grep for 'MINGW'?
Yes, that would be an alternative approach, and may indeed be more
reliable; it has the minor disadvantage of requiring an additional
fork, from the shell, to run the uname command, but that is probably
insignificant. More importantly, it too can be circumvented, simply
by changing the setting of the `MSYSTEM' environment variable, even
if it is unlikely that a normal user would do so.
> If that succeeds, then you know 'pwd -W' will give you the installation
> root; but isn't it possible, even if unlikely, that some other shell
> would have a '-W' extension for 'pwd' that would return a string
> containing a colon?
AFAIK, `pwd -W' is a unique feature of MSYS, for reporting current
directory path with Win32 semantics, but I suppose there may be some
other shell implementation -- presumably also for Windoze, if it's
adding colons into the root directory path -- which does likewise.
Most `bash' and `ksh' implementations will choke on `pwd -W', and
emit nothing on stdout. Some other Bourne shell implementations DO
accept, but ignore, the `-W' flag, in which case `cd / && pwd -W'
simply emits `/' on stdout.
Identifying any single specific runtime environment is often an
imprecise science. The test I proposed will identify a shell
environment which is COMPATIBLE with MSYS, at least in respect of
its path name reporting capabilities, even if it is not actually
MSYS' bash. Adding a `uname -s' check may give an increased level
of confidence in the identification, but still doesn't provide