Re: Ada.Directories.Base_Name and dot files

[Adam Beneschan <adam@irvine.com>]

On Oct 7, 5:40 am, Thomas Løcke <"tl at ada-dk.org"> wrote:
> Hey all,
>
> While working my way through the excellent Ada.Directories package, I've
> stumbled on a minor annoyance: The Base_Name function does not handle
> dot files very gracefully.
>
> Here's an example:
>
> ++++
> with Ada.Text_IO;
> with Ada.Directories;
>
> procedure Dot is
>     package IO renames Ada.Text_IO;
>     package D renames Ada.Directories;
>
> begin
>     IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
>     IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
>     IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
> end Dot;
> ++++
>
> The output I get is this:
>
> ++++
> 1: foo
> 2:
> 3: .foo
> ++++
>
> What I had hoped for, was this:
>
> ++++
> 1: foo
> 2: .foo
> 3: .foo
> ++++
>
> With the current null string solution, you'd have to do some manual
> parsing to get to the actual basename of a dot file.
>
> Instead of returning a null string when the first character is a dot,
> couldn't Base_Name just as well just return the basename *with* the dot,
> because that is the actual basename for a dot file. The dot is part of
> the name.
>
> Is there a good reason for the current behavior?
>
> There's a comment in the body of Base_Name:
>
> ++++
> --  Look for the last dot in the file name and return the part of the
> --  file name preceding this last dot. If the first dot is the first
> --  character of the file name, the base name is the empty string.
> ++++
>
> So it's not like the programmers behind this wasn't aware of dot files,
> they've just opted for a somewhat odd solution, in my humble, and not
> very expert, opinion.  :o)

P.S. For more information, look at the discussion of AI95-248
(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00248.txt?rev=1.32)
starting at around November 21, 2003 (and a few earlier entries from
July of that year).  There was some discussion of what the best
behavior would be with regard to file names like that.  It was pointed
out that on Windows, a file named ".abc" is treated as any other file
with an extension of .abc---if you open it in Explorer, Windows uses
the "abc" to determine what application to try to open it with.  There
was also some feeling that the rules should be the same on Windows and
Unix, and some feeling that these are marginal cases we shouldn't
worry about, and some feeling that the Base_Name and Extension
functions shouldn't have been there at all.  The resulting solution is
a compromise.  My feeling is still that this is a somewhat "marginal"
case---i.e. many Unix file names don't fall into the base-name/
extension paradigm and it's not sensible to talk about base names or
extensions of such files, so therefore using Base_Name or Extension on
them is likely not to do what you'd expect.

                                   -- Adam