On Thu, 2011-04-07 at 10:27 -0700, Scott McMurray wrote:
On Thu, Apr 7, 2011 at 08:14, Beman Dawes <bdawes@acm.org> wrote:
Does anyone have a stronger argument than intuition for changing or retaining the current behavior?
I like the existing way, actually. It fits with two nice ways of looking at things: - A *nix hidden file is one with no name, after removing all extensions.
I think this is a misleading view. It would be better to expose an "is_hidden" function on (probably?) file_status that applied platform specific rules: on Unix, does the file begin with ".", on Windows, is the Hidden attribute set.
- A file like .gitignore is a file of type "gitignore" that nobody bothered to name.
Arguable. Equally valid is the view that it is a file called ".gitignore" which has no extension. As has been mentioned elsewhere, Unix really doesn't care about extensions (it uses the much more sensible approach of magic numbers to determine file-type). People already have to code around files not having extensions (if they want vaguely portable code, anyway) - an awful lot of my Unix files don't have extensions. Having done a quick straw-poll of my own dot-files with no extensions, they are either: * bespoke config files (mostly from older applications) * some scripts * text files (histories) * and... *mostly* they are INI-style config files
Conceptually, it would make sense to have multiple *.gitignore files, and the one without a stem is just the default name. (And that would allow putting, say, all the auto-generated ones in one file, and a manually-maintained list in another.)
Except that that isn't the case for pretty much any Unix dot-file that I've ever heard of. Do you have a non-conceptual real-world example? I think the library should code against "normal" coding practise - and for that reason, I'd argue that .gitignore has stem .gitignore, and an empty extension. However, I can happily cope with the status-quo, too. Phil -- Phil Richards, <news@derived-software.ltd.uk>