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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-08 03:42:07 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!crtntx1-snh1.gtei.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) Newsgroups: comp.lang.ada Subject: A Directory package for Ada (was: How Ada could have prevented) Date: 8 Aug 2001 05:40:29 -0500 Organization: Berbee Information Networks Corporation Message-ID: References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <9kbvsr$a02@augusta.math.psu.edu> <3B69DB35.4412459E@home.com> <3B6F312F.DA4E178E@home.com> <9kpa4f$j2n$1@nh.pace.co.uk> In article , "David Starner" writes: > "Larry Kilgallen" wrote in message > news:On2kQeHwm8CK@eisner.encompasserve.org... >> In article , "David Starner" > writes: >> > >> > I think GNAT.Directory_Ops is portable to all the systems GNAT is, which >> > includes those three. For a basic directory operations package, you need >> > function Is_Directory (File : Filename) return Boolean and procedure >> > Directory_List (Directory : in Filename; Directory_List : > Filename_List). It >> > seems that anything with directories is going to work with that, and > it's a >> > usable mix. (It would work for music123, a program of mine that uses >> > GNAT.Directory_Ops.) >> >> On VMS those two subprograms would not seem to offer control of whether >> one wants all versions or just the latest version of a file. > > What does the directory accessing API (for C, Pascal, or any existing Ada > implementation) look like? There is typically an input string (or three) giving the specification of the desired file. Wildcard characters "*" and "%" within the string provide for subsetting the group of files. Important to this discussion (and I never thought of this until now) they also allow specification of a trailing ";" to indicate that only the most recent version should be taken. Some FTP servers on VMS include or exclude the trailing ";" in response to a binary control, and also suppress the version portion of the output string in response to a separate binary control (to help programs on other systems that do not know how to handle a version string properly). > A Interfaces.* scheme starts to get ugly; you're almost forced to use some > sort of preprocessor or source constructor to go cross platform. Offering a > common scheme lets you not worry about differences in many cases. I understand that as a goal of a common scheme. I have run into too many C programs on VMS imported from other operating systems that took the simplistic approach and botched the job by leaving those two binary controls in whatever state happened to naturally occur to the author. As an example, to read a particular file in the directory would need just the latest version if you are writing a compiler but would need all versions if you are writing an archiving program. To construct the filespec for the modified copy of the file you are about to write would require no version in the string, whereas to reliably be able to reopen the file you just learned about (and not a subsequent version) would require a version in the string. Parsing the filenames, incidentally, is not a simple exercise in string handling. Besides [].; there are [].. <>.; and <>.. forms of separators, and if the VMS disk in question happens to be the newer ODS-5 format, there can be dots and other strange characters scattered throughout the filename, but not significant for dividing the filespec. One really needs to call a system service to get this right. On a simpler scale, I recently ran into a "portable" C program that relied upon inserting a system-specific character to separate the next level of subdirectory. On VMS that would be the . characters in the partial filespec [sub1.sub2.sub3] for an arbitrary example. But this program was written (for Windows and Unix) under the presumption that one merely inserted the special character and the subdirectory name to advance to the next subdirectory level. That would produce something like [sub1.sub2.sub3].sub4 which is not exactly the requires [sub1.sub2.sub3.sub4]. You can easily say you don't care about VMS, but if you decide to not make the package general you will run into problems on some operating system you don't know about. OS400 and MVS are examples of two operating systems I don't know about. (I leave to another day the discussion of "or three" in my first sentence above. It gets complicated.)