Re: [boost] [filesystem] Decomposition of filenames beginning with period?

Subject: Re: [boost] [filesystem] Decomposition of filenames beginning with period?
From: Phil Richards (news_at_[hidden])
Date: 2011-04-09 03:56:29

On Thu, 2011-04-07 at 10:27 -0700, Scott McMurray wrote:
> On Thu, Apr 7, 2011 at 08:14, Beman Dawes <bdawes_at_[hidden]> 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_at_[hidden]>