Mail Archives: djgpp-workers/2001/01/04/04:24:53
On Wed, 3 Jan 2001, Tim Van Holder wrote:
> I noticed an annoying thing when running the mkinstalldirs script
> that comes with automake. Besides the fact that it will try to
> create /dev and /dev/env (because they don't exist), this does
> not result in the creation of /dev and /dev/env directories.
> Instead, a /dev dir is created, and an env subdir is created in
> the current directory.
This is a known problem. It doesn't do anything harmful except
leaving behind the /dev and ./env directories.
We already discussed this in the past (I think Mark started that
discussion), so please search the djgpp-workers archives for those
discussions, to avoid reiterating what we've been through already.
> The problem seems to be /dev. In bash, using completion on
> /dev/env/ yields no result (even when there is an actual /dev/env
> directory on the current drive), but /dev seems to resolve to the
> current directory (yet a test -d on it fails).
All correct and known. "/dev/" and "x:/dev/" prefixes are removed
from any file name, to support devices which some DOS calls want to
see without leading directories.
> Would it be possible to adjust this so a /dev path is first
> treated as a regular path, with the magic only kicking in if
> there is no corresponding real dir (as seems to happen for the
> contents of /dev/env/? If not, I believe /dev and /dev/env
> should be presented to apps as real, existing directories (so
> mkinstalldirs will not try to create them).
Please look at src/libc/dos/io/putpath.c in the library, suggest
any fixes you see fit, and let's discuss that.
Note that _put_path is called in many places and therefore should be
reasonably efficient. It also cannot depend on any application-level
knowledge, like what function exactly is going to be called on the
file name it receives, and it cannot itself issue any system calls.
(The last restruction seems to make you first suggestion above
impossible to implement.)
- Raw text -