[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [MiNT] MiNTLib 0.52.3b

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Martin-Eric Racine
> Sent: Friday, August 06, 1999 2:34 PM
> To: Julian Reschke
> Cc: Jo-Even.Skarstein@gjensidige.no; mint@fishpool.com
> Subject: RE: [MiNT] MiNTLib 0.52.3b
> > > Try "cd /dev/c" and list, then compare with "cd /c" and list.
> >
> > /dev/c ist not supported by MiNT. What you see is a hack in the MiNT
> > libraries.
> Oh?  How could libraries insert a device?  Please explain.

They can "invent" entries and report them just as if they would be really

If you really claim that there is something like U:\dev\<driveletter> in
MiNT, you should go back to the source and read it.

> > > Both are the same and it's already there, just hidden (i.e. ls
> > > still won't show you /dev/c even though it is there).
> >
> > No, it's not.
> Then how do I manage to cd to /dev/c and see the same as /c ?

Because your shell is linked against a library which fakes these entries.

> > > Couldn't U: also hide the single-letter drives the same way, but
> > > still make them available to whichever app request /c etc.?
> >
> > Of course -- just hiding them doesn't make them inaccessible.
> Making them hidden by default, but still accessible, would be nice.

No. By default they should be visible.

> Less clutter when listing U: and doesn't break existing practices.

Sure it does. For instance people might use a fileselector where you need U:
to get to other drives, and the fileselector might be coded in a way where
it doesn't show these entries.

> However, the above bit about that being a library hack confuses me;
> I'm not sure I would know where to change the kernel, to change it.

Well, use the source.