Date: 03 Sep 2003 10:41:14 +0200
Message-Id: <u4qzu5knp.fsf@elta.co.il>
From: Eli Zaretskii <eliz AT elta DOT co DOT il>
To: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3F550293.76E873F8@phekda.freeserve.co.uk> (message from Richard
	Dawe on Tue, 02 Sep 2003 21:50:27 +0100)
Subject: Re: /dev/c - c: or c:/ ?
References: <002a01c370ca$b51801e0$2202a8c0 AT dualzastai> <3F550293 DOT 76E873F8 AT phekda DOT freeserve DOT co DOT uk>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Tue, 02 Sep 2003 21:50:27 +0100
> From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> > 
> > How about simple shell sanity?  Shell scripts may consider
> > $dir and $dir/. to be interchangeable (and I wouldn't be surprised
> > if POSIX mandated this), which would not necessarily be true in
> > our case ('c:' versus 'c:/.' if $dir is /dev/c).
> 
> POSIX mandates that.

Well, DOS isn't a Posix system ;-)  The fact that "c:" and "c:/" are
two different things is one of the frequent gotchas in ported
programs.  So the Posix compatibility is already broken here, and it
ain't our fault.

> The idea of having an absolute path like /dev/c the semantics of a relative
> path seems like a really bad idea.

"c:" isn't a relative path, it's 99% absolute path, as far as Posix
semantics is concerned.

Look, I don't necessarily object to this change, but please keep in
mind that these features are all quite fragile; we are lucky that we
narrowly escape the various insanities involved in the underlying
OSes.  Why risk breaking something down the road for no apparent
reason?

In other words, I don't recommend changes on purely academic grounds,
especially in such ad-hoc features, where there's no ``theory'' we
could back ourselves up.  If the current behavior _really_ hurts
somewhere, or is an obstacle to some development that has its own
merit, by all means let's make the change.  If not, my recommendation
would be not to fix what ain't broken.

In any case, if the change _is_ done, please don't forget to test the
new code with the full /dev/x syntax, including environment variable
substitution.  We don't want to break that as a side effect.