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)


I'm assuming you're using Linux or some other Unix-type system?
Although the exact meanings of the Ada.Directories operations are
implementation-dependent, the AARM gives the "expected interpretation"
on Unix-type and Windows systems.  (AARM A.16(1.a))  AARM A.16(80.a)
says, 'For Unix and Windows®, the base name is the portion of the
simple name preceding the rightmost period (except for the special
directory names "." and "..", whose Base_Name is "." and "..").'

Unlike VAX/VMS, where every file has a definite, separate "base" and
"extension" name (the extension name can be blank), Unix is a lot
looser (and Windows is a little bit looser).  RM A.16(78) says, "The
extension name is a portion of a simple name (not including any
separator characters), typically used to identify the file class."  On
Unix, this is only the case sometimes.  For source files, it's often
true, and also for other files like .o (object) files.  But it's not
consistent.  Executable files don't have an extension.  Files
beginning with a dot are usually "hidden" files with some control
information, and I wouldn't expect them to fall into the "basename-dot-
extension" pattern that other file names fall into.  When I make a
backup copy of a file, I'll often just append .save to the file name,
but I wouldn't consider ".save" to be an extension, and it certainly
doesn't identify the file class.  But I wouldn't expect an application
to read my mind and know that.

So the Base_Name and Extension functions aren't going to be
appropriate for every file name on Unix, since not all Unix files have
definite base names and extensions.  Bottom line: if you know what you
want, just use the string functions and do it yourself.

                                    -- Adam