Re: [lmi] [lmi-commits] master c98c00d 10/33: Say "basename" rather than "leaf"

[Greg Chicares]

On 5/9/21 9:41 PM, Vadim Zeitlin wrote:
> On Mon,  3 May 2021 08:15:52 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> branch: master
> GC> commit c98c00dbe5559b76a22b502dcce471f347514b3c
> GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> 
> GC>     Say "basename" rather than "leaf"
> GC>     
> GC>     The POSIX dirname/basename nomenclature is universally understood.
> 
>  I must be an exception, but I never know if "basename" is supposed to
> include the extension or not.

For basename(3), it does:

  https://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
| The basename() function shall take the pathname pointed to by path and
| return a pointer to the final component of the pathname, deleting any
| trailing '/' characters.

Looking further into this now, I note that basename(1) optionally
removes a "suffix", which seems to be much like the shell parameter
expansion "${parameter%%word}". Perhaps that's most commonly used
to remove a file extension, so that it "suffix" comes to be seen as
implying "extension"; I'm just not aware whether it's conventional
to think of it that way.

>  It looks like it does include the extension in lmi, and maybe we don't
> need anything else anyhow, but I just wonder: how would you call just the
> name part if you had to refer to it, should we use "stem" for it now? I

I'd never seen that term used anywhere except the make manual:

https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html
| $*
| The stem with which an implicit rule matches (see How Patterns Match).
| If the target is dir/a.foo.b and the target pattern is a.%.b then the
| stem is dir/foo.

and that's why "stem" seems less good to me than "basename".

Of course, you could cite

https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
| $(basename names…)
| Extracts all but the suffix of each file name in names. If the file name
| contains a period, the basename is everything starting up to (and not
| including) the last period.

as evidence against "basename" for boost::filesystem::leaf.
But I'm not trying to follow 'make'; I'm trying to follow posix.
And the only reason I'm trying to follow posix is to avoid
confusion.

> don't have any real objections to using "stem", but doing it while not
> using "filename" for the "stem + extension" part is 50% consistent with
> std::fs, which is arguably the worst kind of (in)consistency.

Wait...are we talking past each other? Let's establish some
definitions first. In '/home/greg/foo.txt':
  let the HEAD be '/home/greg/'
  let the TAIL be 'foo.txt'
All I really want is an unambiguous name for each of those.
I've proposed
  dirname = HEAD
  basename = TAIL

Although I consider this much less important, we could add
  let the CEDILLA be '.txt'
and, least important of all, there's 'foo', which IMO doesn't
need a name, but for completeness we could say
  let the TAIL_SANS_CEDILLA be 'foo', or
  let the THING_THAT_DESERVES_NO_SHORT_NAME be 'foo'
I think we can agree on
  extension = CEDILLA

Then do we agree that 'dirname' is good nomenclature for HEAD?

And, where I propose 'basename' as nomenclature for TAIL, do you
propose 'stem'? It seems not, if you speak of "stem + extension";
for that, do you propose 'filename'?

The problem I have with 'filename' is that I never know what it
means, even when I'm the one who's written it: is it the same as
'pathname', i.e., '/home/greg/foo.txt' above, or is it 'foo.txt',
which I propose to call 'basename'?

>  FWIW personally I find the terms "base name" for "stem" and "full name"
> for "stem + extension" the most clear, but I'm not going to claim that
> there is anything universal about this terminology neither.

I'm averse to 'full name' for two reasons. First, in a definition like
  std::string foo
    (std::string const& full_name
    ,std::string const& file_name
    )
I'm certain to get the "full" and "file" confused. Second, for the
'/home/greg/foo.txt' example above, I'd say the "full" name is the
whole thing: '/home/greg/foo.txt'.

And I wouldn't know what the "filename" is.

>  Sorry for starting yet another naming discussion, I know that those are
> the most annoying ones, but I've decided that if there ever was a chance
> for this to be useful, it was now, and not later.

The rectification of names is crucial, and the best time is now,
as we're migrating to std::filesystem.

For me, the most important thing by far is to devise unambiguous
names for what I called HEAD and TAIL above. I had thought this:
  dirname = HEAD
  basename = TAIL
was posixy and unambiguous, but what other names might we choose?

Would
  dirname = HEAD
  filename = TAIL
  pathname = HEAD+TAIL
seem good to you instead? Does std::filesystem have any generic
name for HEAD, or must we devise one ourselves? (And if we're
going to follow std::filesystem, we can use "stem" on the rare
occasions when we actually want stem().)

I guess that "filename = TAIL" might be as good as we're going
to do. It corresponds to the standard. My objection to 'filename'
is that it has been used in multiple or ambiguous ways heretofore,
so that the term is spoiled; but we can unspoil it today by fiat,
for lmi at least, endowing it with a righteous meaning forevermore.
What do you think?