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,942b3184b8c0c422 X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: Platform portable support of heir. file systems Date: 1996/12/19 Message-ID: <59c7sd$osh@top.mitre.org> X-Deja-AN: 204975370 references: <01bbec7f$453edcd0$24af1486@pc-phw> <1996Dec18.071612.1@eisner> <59b6ea$522@top.mitre.org> <1996Dec19.075644.1@eisner> organization: The MITRE Corporation, Bedford Mass. newsgroups: comp.lang.ada summary: URLs can be used as local file names too Date: 1996-12-19T00:00:00+00:00 List-Id: >> package url_control is >The letters "url" already have a meaning as "universal resource locator" >in HTTP The url_control package is using url as universal resource locator, but is not restricted to being used by http. For example, it is often used for ftp. In addition, it contains a filename, and with certain portions of the url blank, it IS a filename. Thus this package is used both on a local computer and across the net. In other words, the word url is not being overloaded. It Already has the meaning of being a filename. >> function directory_get_first (pattern: urls) return urls; >> function directory_get_next return urls; > "Next" using the last pattern used ? In what context ? How does one > distinguish one directory search from another (comparing the contents > of two directories, for instance)? Sorry, my telepathy did not transmit through well enough. This is a good argument for finding a way to put more semantic information into visible parts before Ada-2005 is created. You only have to give the pattern once. Get_first and get_next are like an interator which continues until the url returned is the null string, which means there are no more entries in the current directory which match the pattern. This is the way DOS provides access to the directories to avoid data structures that force you to read the entire directory into memory at one time so something like an object-oriented iterator would be useable, but at the expense of a large amount of wasted RAM. >> function directory_temp return urls; > Unique to this thread or just to this executable program ? > Shouldn't there be a matching call to delete it ? Again, sorry for the missing semantic information. In DOS the temporary directory, where the users may create subdirectories which will be deleted by the disk manager, say, every Friday, is called \TMP. In Un*x, the temporary directory is called /tmp. The string \TMP, /tmp, or [SYS001.tmp] would be returned by function directory_temp. What would be created and deleted would be subdirectories underneath the temporary directories. if system = dos_system then set_system (unix_system); end if; Code like this would make sense in writing an application like dos2unix. If we are in DOS (which uses carriage return-line feed) and we wish to convert the file to Un*x (which uses line feed only), then we would set_system, so the next file_instantiation.put_line would append the Un*x end_of_line_string to the end of the line instead of the DOS end_of_line_string. >> function end_of_line_string (system: systems := default_system) >> return string; >Since the "url" is an Ada string, I presume this must refer to some >sort of separator within a file. That is a very Unix (or is it C?) >chauvenist approach. By default, VMS files have no such element, >and I would doubt that MVS files do either. A record is a record, >delimited by out-of-band mechanisms private to the operating system. I used and respected VMS for years with the exception of a component called the Record Manager. The Record Manager does not deal with files as arrays of characters; IMO this is a design flaw of the Record Manager. When I used DEC Ada it took quite a bit of effort to bypass the Record Manager, using Starlet channel programs, interfaces to assembler, and other tricks which should not have been necessary, in order to see the files as arrays of characters. Because so many Defense contracts used vaxen (11-780s or LSI-22s), text_io was made to follow the Record Manager, instead of the idea that a file is just and array of bytes. IMO, this is very serious design flaw of text_io, a flaw which irks most newcomers to the language the first time they try to do random access on a text file or rewind standard_input. There is no valid theoretical reason for denying ordinary operations on files just because Record Manager denied them. The packages that import url_control should support files which act like an array of characters, which is the default for operating systems that are DOS, NT, or Posix-compatible; if they support the Record Manager, that should be In Addition To, not instead of the array of characters operations. Is this Un*x- or DOS-chauvenistic? No, to follow the Record Manager would be chavenistic, because I am not restricting any of the Record Manager operations, but it is a great inconvenience to restric file users to Record Manager operations. > I don't see "directory start" or "directory end" characters, VMS requires square brackets around directory names, and that could be accomplished automatically whenever an operation was done with system equal to VMS, which would make the separator a period, and automatically add the square brackets. Externally, the square brackets would not necessarily be stored in a url, because transmitting it across the net would not always work (for example, certain Un*x shells would have problems). > Your Unix is showing :-). Yes, but it is identical in un*x, DOS, NT, etc. Again, the only outlier is VMS. And VMS is now Posix compliant and is capable of running Posix shells at user request. Yes, I realize that this argument can be turned around, and DOS can run a VMS shell, so yes, absolutely yes, my Unix is showing, and I am demonstrating a preference for a syntax that satisfies me on almost all operating system shells, rather than all shells. >> function environment (variable: string) return string; >> procedure set_environment (variable: string; value: string); > Your Unix is showing :-). Presuming the goal is to deal with things > which affect file access, on VMS that would be "logical names", People have remarked that environment variables work differently on VMS and Unix and DOS. I think this is wrong, because only DOS actually has environment variables. Unix has the capability of running a shell that has environment variables which are more powerful than DOS environmental variables, but most Unix shells do not give the programmer this capability. In all operating systems, there is a way to give the programmer a machine independent capability to set global environmental variables, using a shared file and an application (object, TSR, process, or whatever) that manages that shared file. The question is not how we are going to spell the capability in each operating system. The question is how will we provide the programmer with a machine independent capability of sending messages to the other programs in the machine. Stating that something called environmental variables works differently in VMS is not solving the problem. The set_environment and environment together define the interface for a machine independent facility that should be provided. How we provide it is a separate (but important) question. You suggested environment_table and environment_table_levels as interfaces are interesting. What do the levels mean? mikeb@mitre.org