Mail Archives: djgpp-workers/2003/09/05/17:27:46
Hello.
Eli Zaretskii wrote:
>
> > 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.
/dev/c is something we've introduced. I don't see why /dev/c shouldn't be
POSIX-compliant, just because c: and c:/ are different things.
> > 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.
How about c:foo?
Actually I think of c: being a relative path - something ../../dev/c/foo/bar.
But maybe I'm just weird. ;) If we didn't have /dev/c notation, then obviously
this idea (../../dev/c/...) wouldn't work and c: couldn't be considered a
relative path.
> 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?
I think it's already broken, due to the inconsistent behaviour of /dev/c and
/dev/c/.
> 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.
I think it is broken already. It's just that no-one has noticed.
Part of my objection is because of me maintaining fileutils. Wearing my
fileutils hat I look at a path and think "is that relative". So far we have:
1a. Starts with a slash -> absolute.
1b. Oops, unless it's just /dev/<letter> -> relative.
1c. But /dev/<letter>/something-else -> absolute.
2a. Starts with a drive-letter, then a slash -> absolute.
2b. Starts with a drive-letter, then no slash. Absolute? Relative? Really we
need to expand it, to make it absolute. Or convert it to a ../../../dev/c/...
path to make it relative. Aargh.
Every program needs to be updated to have these rules in them. That's
horrible. It seems like we should provide an API that helps our developers
out.
> 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.
I think a "suck it and see" approach is probably best. Try building the whole
tool chain with the patch applied. Maybe that will catch some /dev/c vs.
/dev/c/ usages. If it works, put it in alpha 2. If someone justly complains,
remove it.
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -