Mail Archives: opendos/1997/05/27/09:46:13
On Wed, 7 May 1997, Pierre Phaneuf wrote:
> > Yuk. Embedding spaces into filenames is gross. One thing about Win95
> > that really irked me is that some of the files had embedded spaces.
> > And Win95's use of double-quotation marks to specify embedded spaces
> > is worse than the use of backslashes. IMHO.
>
> Yuk indeed!!! This is horrible!
Then use quote marks. "This is a long filename".
With command line programs you have one of 2 choices.
1) The program accepts a single filename argument.
Example:
del This is a really long filename
2) The program accepts multiple filename arguments.
Example:
del "This is a really long filename" "This is another"
For the delete command, #1 is ok, however for the COPY command,
what would you do? How should it be interpreted then? Should it
be interpreted as:
COPY "This is a really long" "filename"
or
COPY "This is a really long filename" .
????
A standard method needs to be used that is exactly the same with
ALL programs to avoid confusion. This means that for files with
spaces in their names that they absolutely must be quoted or
escaped or problems will result. No heuristics can determine
proper operator intentions in all cases. This is particularly
important with the DEL and MOVE commands!
> > On the whole topic of case sensetivity that's been wracking this group,
> > I don't think there's any burning need to modify FAT. I think we all
> > agree that backward compatibility is vital to OpenDOS. If it can't run
> > legacy apps, it may as well be a whole new OS. Therefore, whether we
> > make some enhancement to FAT or not, the good old FAT will still have
> > to be around for people to use.
>
> I don't think much will happen to OpenDOS/16, apart maybe VFAT and a few
> improvements. OpenDOS/32 though will get a slew of improvement (ext2 is a
> memory hog compared to FAT!) and will have its own protected mode API.
> Program that calls the kernel through the current 16-bit real mode API
> will get an emulation (like complex permissions systems parsed to a simple
> "doesn't exist" (for file for which the user has no permissions),
> "read-only" and "read/write", depending on the users rights. A bit like
> OS/2 native calls and it's INT 21h services...
Well, ext2 *may* be such a memory hog, but that doesn't mean that
it shouldn't be supported. Rather it means that people who's
systems can't afford to dish out the resources that ext2 requires
- won't be able to use it, and will have to use VFAT or something
else instead. That doesn't mean that a 486 user with 16M of RAM
shouldn't be allowed to use it! I hope that you're not implying
that!
> > If you want backward compatibility, FAT is there to be used. If you
> > want long filenames, VFAT or ext2 is there. If you want to be Win95-
> > compatible, use VFAT. If you insist on cast-sensetivity, use ext2.
> > We can enhance FAT if we want to, of course, but I don't really see
> > the need.
>
> OpenDOS/16 will probably get hardcoded FAT and optional VFAT driver (or
> maybe hardcoded too) and nothing else. OpenDOS/32, should get installable
> file systems without any problems...
Well, I think that anything useful that shows up in OD/32 will be
also available or will be ported to OD/16 if enough people want
it.
I agree with the IFS statement above completely.
> > Having said that, Tim Bird's mention of an OO FS intrigues me. That's
> > an enhancement that may be worth making. I would love to see this idea
> > fleshed out.
>
> I think this is quite away from DOS for now! We'll see, we've got pretty
> imaginative people in here! ;-)
Agreed! :o)
Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris
Computer Consultant | Coming soon: dynamic-IP-freedom...
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
Email: mharris at blackwidow.saultc.on.ca <-- Spam proof address
URL: Art Bell - Coast to Coast AM http://www.artbell.com
- Raw text -