[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: path separator

From: Ralf Wildenhues
Subject: Re: path separator
Date: Wed, 24 Jan 2007 20:14:31 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

* Brian Dessent wrote on Tue, Jan 23, 2007 at 08:56:03PM CET:
> Assuming your app is a native app (i.e. the answer to the above is 'no')
> then even if your app is run from a MSYS sh.exe it should still get a
> copy of PATH that uses colons, since MSYS sh.exe should be able to tell
> that this is not a MSYS binary.  The "how it tells" is either by looking
> at whether it's linked against msys-1.0.dll or whether it's installed in
> the MSYS bin directory -- I forget which method is used and I think it
> changed recently anyway.

I know neither MinGW nor Cygwin people like to commit to this, and I
fully understand this, but for testing purposes, it would be *really*
helpful to have a documentation of the nitty gritty details:
- how exactly paths/variables are translated,[1]
- how exactly "it tells" whether something is a MSYS binary/Cygwin app,

and how those details varied over the course of history, including
planned future changes, as far as known.

I can get at the current behavior by reading source code; but that is
much more work than I would want to do most of the time, and also it's
not enough to know about the history.  My primary concern here is self
defence against triggering those semantics unintentionally while writing
shell code bits like
  sed -n /x/p
that are otherwise portable but cause fun for merely the one user that
happens to have an X: drive *and* at the same time a crooked PATH that
gets him a sed that's not from MinGW (say, the GnuWin32 or the Cygwin
one).  And then we get a bugreport against Libtool that's simply not
reproducible.  (Wrt. older semantics: don't tell me everyone should just
use the most current Cygwin version; I do that, but end users compiling
some package that uses Libtool can't be expected to be.)

For all other systems except the w32 ones, I already have a document
handy that answers the bulk majority of shell incompatibilities:


[1] Here's what I mean by exactly: is /X translated to X: only if an X:
drive exist?  What about removable drives?  What about relative paths
like /X/../foo?  etc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]