Date:	Tue, 13 Oct 1998 17:43:28 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	M DOT A DOT Bukin AT inp DOT nsk DOT su
cc:	djgpp AT delorie DOT com
Subject:	Re: /dev/null problems with bash when rebuild from sources
In-Reply-To:	<204sthx7i1.fsf@Sky.inp.nsk.su>
Message-ID:	<Pine.SUN.3.91.981013174307.4278D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

On 7 Oct 1998 M DOT A DOT Bukin AT inp DOT nsk DOT su wrote:

> > You are NOT supposed to set SYSROOT to anything but a root of a
> > certain drive.  That is, SYSROOT=c: is okay (and /dev/null will work
> > then).
> 
>   Let me quote from bash's readme.dos:

Since when is the docs a valid argument in a discussion? ;-)

Trust me, SYSROOT is not supposed to work well with non-root setting.

> IMHO, replacing `/dev/something' with `something' is not good.  It
> does not add much for portability.

Portability is not the issue for /dev/foo other than /dev/null and
/dev/tty.  The reason for support for other devices is DOS
compatibility.  You *would* like for DJGPP to be DOS-compatible, won't
you?

DOS pretends that every character device lives in a directory called
\DEV on each drive, even if such a directory doesn't exist.  So, for
example, a DOS program should be able to open a file "\DEV\CLOCK$$"
and succeed.  DJGPP should support that.

Unfortunately, DOS is very inconsistent in its handling of devices.
For example, "\DEV\CLOCK$$" works, but "C:\DEV\CLOCK$$" does not.
IMHO, this is unacceptable, since many programs convert the file names
to fully-qualified X:/FOO/BAR form before calling library functions.
So DJGPP's special handling of X:/dev/foo names tries to repair this.
And that is why X:/dev/foo names are special.

> IMHO, bash should handle `/dev' specially itself.

I don't think this is a good idea.  The experience with the
//X/foo/bar pathnames (which Bash does support) indicates that any
feature which isn't supported by the libc (and hence by all the other
programs compiled with DJGPP) eventually means subtle bugs, because
the conversions that Bash needs to perform to support this will work
in some cases, but not in others.

For example, consider the following command line:

	sed /dev/s/foo/bar/g /dev/foo > foobar1

How the heck is Bash supposed to know which of the two /dev strings to
convert?  If it converts the first one, then you have a script that
will mysteriously fail.

> /bin/{cp|rm...} (mostly in shell scripts and Makefiles).
> 
> Current implementation of SYSROOT support makes it easier to have
> `/tmp' and `/bin' on one drive and access them from any other drive.

This is NOT how I would recommend to handle these cases.  These
problems are actually bugs in the scripts, so you should change them
to use ${TMPDIR-/tmp} instead of /tmp, rm and cp instead of /bin/rm
and /bin/cp, etc.  Then submit the changes to the maintainers of these
scripts.  That's what I do when I see such atrocities.

> That's why I think that current implementation of SYSROOT support is
> either broken or useless (the same applies to `//drive/path'
> notation).

If you think it's broken or useless, please feel free to fix it and
submit the patches to DJ Delorie for inclusion in the next release of
DJGPP.

- Raw text -