Mail Archives: cygwin-apps/2001/03/30/09:21:37
> > /cygdrive is not "effectively undocumented"...
In terms of:
3) UI Design
4) Actual user (lack of) awareness
It's not a listed resource when you ask for all available resources to be
shown, therefore it's effectively undocumented.
> > Although, I guess it could be undocumented if you never actually read
> > the documentation.
doesn't show /cygdrive. Neither does mount. Therefore, it's undocumented,
by virtue of expectation. The semantic purpose of listing a directory and a
mount table is to request from the operating system a documentation of what
resources are available.
If extra resources are available, even if they're written about in secondary
documentation, they're not in the primary self-documenting interface and
therefore all those resources are undocumented.
The end effect, of course, is that usage of those resources is curtailed
significantly, which is the empirical way to verify that something is
In a similar vein, it doesn't matter if Cisco documents a command line
option in a FAQ; when there are commands in the IOS CLI that are respected
but don't show up to a "show all available commands" '?' request, they're
> The way that I eliminate the need to use /cygdrive is to
> mount -b --change-cygdrive-prefix /
> and then I can
> ls /c
> ls /d
> ls /e
> ls /f
> without mounting each drive.
I believe this fails to add the drives to the visible directory structure,
which is problematic.
> Chris, I would like to make the argument that / would be the better
> default for the cygdrive prefix.
Clearly *something* needs to be done to make it more obvious how to access
system drives. I personally prefer /c, /d, etc. simply because it's a quick
mental translation from c:\ to /c. At minimum, a /cygdrive folder should
exist by default, perhaps just renamed to /drives.
Ideally, the setup program itself would give the user the choice. This is a
*core need* for Cygwin to address; it's explicitly non-obvious how to access
resources outside the Cygwin psuedosandbox.
Dan Kaminsky, CISSP
- Raw text -