Date: Thu, 4 Jan 2001 11:23:02 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: DJGPP Workers Mailing List Subject: Re: Minor bug (feature?) in /dev/env support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.)