From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,e96fdf9557794655 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!12g2000pri.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Ada.Directories.Base_Name and dot files Date: Wed, 7 Oct 2009 07:52:38 -0700 (PDT) Organization: http://groups.google.com Message-ID: <09eb2709-aa43-460f-9db1-7228b4ff38ef@12g2000pri.googlegroups.com> References: <4acc8c20$0$284$14726298@news.sunsite.dk> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1254927158 15506 127.0.0.1 (7 Oct 2009 14:52:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 7 Oct 2009 14:52:38 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 12g2000pri.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8604 Date: 2009-10-07T07:52:38-07:00 List-Id: On Oct 7, 5:40=A0am, Thomas L=F8cke <"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 > =A0 =A0 package IO renames Ada.Text_IO; > =A0 =A0 package D renames Ada.Directories; > > begin > =A0 =A0 IO.Put_Line (Item =3D> "1: " & D.Base_Name (Name =3D> "foo.txt"))= ; > =A0 =A0 IO.Put_Line (Item =3D> "2: " & D.Base_Name (Name =3D> ".foo")); > =A0 =A0 IO.Put_Line (Item =3D> "3: " & D.Base_Name (Name =3D> ".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: > > ++++ > -- =A0Look for the last dot in the file name and return the part of the > -- =A0file name preceding this last dot. If the first dot is the first > -- =A0character 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. =A0: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=AE, 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