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!g22g2000prf.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 08:10:30 -0700 (PDT) Organization: http://groups.google.com Message-ID: 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 1254928230 19409 127.0.0.1 (7 Oct 2009 15:10:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 7 Oct 2009 15:10:30 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: g22g2000prf.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:8605 Date: 2009-10-07T08:10:30-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) 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=3D1.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