On 6/24/07, Francky Leyn <[EMAIL PROTECTED]> wrote:
Would it not be a good idea that all these cases were handled
correctly by a windows coreutil?
a) so that the command no longer hangs
But it's doing what you tell it. These files are special files in
Windows. Like /dev/null is special in Unix. Except that of course
you can't see them with DIR or Cygwin ls. I assume this is partly
because these filenames were special even in DOS 1.x, which had no
support for directories.
b) that something better than the cryptic 'bad file specifier' is
written out
I'm not sure what is causing that, so I can't comment.
Eg: aux is a name reserved by windows
If windows changes to un-reserve the name, presumably the code would
be out of date.
c) That under UNIX a warning is issued saying the filename is not Windows
compatible.
It would be equally reasonable to have other tools to check for this
too, such as editors, archiving utilities, CD-ROM writing programs,
and so on. Should they also check for VMS filename compatibility?
TOPS-20? MVS? I would argue that it's probably better to put this
kind of checking into a separate tool.
That tool already exists. It's called doschk and it's Free Software,
too. I'm not aware of any equivalent tool for TOPS-20 filenames,
though.
I worked for years under UNIX. Never any problems
with filenames. Now that I'm forced to work under Windows, my
filesystem is broken at multiple points. I wouldn't have encountered
this if I was warned.
My sympathies, I wouldn't enjoy that either.
James.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
