Date: Tue, 13 Oct 1998 17:43:28 +0300 (IDT) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.