On 03/01/2011 10:31 AM, Nick Sabalausky wrote:
"Jonathan M Davis"<[email protected]> wrote in message
news:[email protected]...
I think that I agree with you on all counts. I can understand if the path
stuff
can't deal with / or \ in file names (that's probably not worth trying to
get to
work right), but it _should_ be able to handle directories with dots in
them and
files with no extension. Files without extension may be uncommon in
Windows, but
they're common enough on Linux.
Due to the practical need for dealing with Unixy systems (for instance, an
external web server) and cross-OS compatibility, etc, I deal with
extension-less files (and filenames that start with a dot) quite frequently
even on Windows, and even though I'm primarily a Windows user.
That reminds me of something I've often wondered, though: Does unix consider
a file named ".bashrc" to be a nameless file with an extension of "bashrc",
or just an extentionless file named ".bashrc"? (I know unix doesn't
typically have a concept of file extension, it's all just part of the name,
but unix programs will often care about the extension portion of a
filename.)
To be consistent with how things work on Unixes, file names starting with a '.'
should be special-cased.
This '.' is a conventional code just meaning normal users should not cope with
such files/dirs during normal use (and thus such files do not appear on normal
dir content lists). It definitely has nothing to do with the notion of
extension (which as you say is not a primary notion on Unixes). Treating it as
an extension would totally be buggy.
I would thus approve
assert( getName("/home/me/.foo" == "/home/me/.foo" );
assert( getName("/home/me/.foo.cfg" == "/home/me/.foo" );
on Unixes, provided this behaviour is well documented.
Denis
--
_________________
vita es estrany
spir.wikidot.com
