* Platform portable support of heir. file systems @ 1996-12-18 0:00 Paul Whittington 1996-12-18 0:00 ` Larry Kilgallen ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Paul Whittington @ 1996-12-18 0:00 UTC (permalink / raw) I was just working on one of our support packages that interfaces to the host OS to do file I/O and can't find any support in the Ada Annex set for a portable way of accessing heir. file systems. I need things like "MakeDirectory", "RemoveDirectory", etc. Am I missing something, or is it the case that there is no Ada Annex covering this very common need? If there is no Annex support, is the ARA working on some kind of industry agreement about such things? TTFN Paul ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-18 0:00 Platform portable support of heir. file systems Paul Whittington @ 1996-12-18 0:00 ` Larry Kilgallen 1996-12-18 0:00 ` Tarjei T. Jensen ` (2 more replies) 1996-12-19 0:00 ` Robert Dewar 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 3 replies; 19+ messages in thread From: Larry Kilgallen @ 1996-12-18 0:00 UTC (permalink / raw) In article <01bbec7f$453edcd0$24af1486@pc-phw>, "Paul Whittington" <paul@sage.inel.gov> writes: > I was just working on one of our support packages that interfaces to the > host OS to do file I/O and can't find any support in the Ada Annex set for > a portable way of accessing heir. file systems. I need things like > "MakeDirectory", "RemoveDirectory", etc. On VMS: Directories can only be nested 8 deep or so if you want the files they contain to be backed up. Directories cannot be removed until all their contents are removed, regardless of how much privilege you have. Directories are always created with nobody having delete permission, regardless of what the caller specifies (this is independent of the previous rule). Directories have a "version limit" attribute which would logically be set by a creator to get a desired behaviour, even if only to override the default for the default of inheriting from the parent. The directory from which you read might be different from the directory to which you write, given identical specifications, if the device specified is a rooted directory rather than a real device. (Come to think of it, Unix users creating a directory don't even specify the device separately, do they>?) I am certain that other operating systems have quirks as well, especially when one gets into permissible name lengths and character sets (which are _not_ necessarily the same as for files). A common package for directory manipulation would not seem to be very "portable" if the rules differ on each operating system. Larry Kilgallen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-18 0:00 ` Larry Kilgallen @ 1996-12-18 0:00 ` Tarjei T. Jensen 1996-12-18 0:00 ` Larry Kilgallen 1996-12-20 0:00 ` Robert Dewar 1996-12-19 0:00 ` Michael F Brenner 1996-12-23 0:00 ` David J. Fiander 2 siblings, 2 replies; 19+ messages in thread From: Tarjei T. Jensen @ 1996-12-18 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > > On VMS: > > Directories can only be nested 8 deep or so if you want > the files they contain to be backed up. > > Directories cannot be removed until all their contents > are removed, regardless of how much privilege you have. > > Directories are always created with nobody having delete > permission, regardless of what the caller specifies (this > is independent of the previous rule). > > Directories have a "version limit" attribute which > would logically be set by a creator to get a desired > behaviour, even if only to override the default for > the default of inheriting from the parent. > > The directory from which you read might be different from > the directory to which you write, given identical specifications, > if the device specified is a rooted directory rather than a > real device. (Come to think of it, Unix users creating a > directory don't even specify the device separately, do they>?) > > I am certain that other operating systems have quirks as well, > especially when one gets into permissible name lengths and > character sets (which are _not_ necessarily the same as for files). > > A common package for directory manipulation would not seem to be > very "portable" if the rules differ on each operating system. Don't be silly! Exactly this behaviour would be very nice to encapsulate. Much of what you think is VMS specific is specific to other operating systems. Regardless of what is the underlying operating system it is a general requirement for some file maintenance primitives. That is why they appear in the standard C library. If C programmers think these things important then I'm pretty confident that Ada programmers want the same facilities. It is trivial to construct a set of primitives that easily can cope with file systems of the most common operating systems (I have a paper somewhere around here on this theme). The point is not to capture all the fine points, but enough to keep the programmers comfortable. Greetings, ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-18 0:00 ` Tarjei T. Jensen @ 1996-12-18 0:00 ` Larry Kilgallen 1996-12-20 0:00 ` Robert Dewar 1 sibling, 0 replies; 19+ messages in thread From: Larry Kilgallen @ 1996-12-18 0:00 UTC (permalink / raw) In article <32B8508F.2B7D@online.no>, "Tarjei T. Jensen" <tarjei@online.no> writes: > somewhere around here on this theme). The point is not to capture all > the fine points, but enough to keep the programmers comfortable. My choice of Ada is to drive the errors to compile-time (on my machine) rather than run-time (on my customer's machine). If a program I write in Ada cannot deal with a directory structure created from some other language, that is a defect. To the extent that a common package hides from me the differences between operating systems, it may assist me in adding defects to my programs. Quite frankly, I can do well enough on my own, thank you :-). Larry Kilgallen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-18 0:00 ` Tarjei T. Jensen 1996-12-18 0:00 ` Larry Kilgallen @ 1996-12-20 0:00 ` Robert Dewar 1996-12-21 0:00 ` Tarjei T. Jensen 1 sibling, 1 reply; 19+ messages in thread From: Robert Dewar @ 1996-12-20 0:00 UTC (permalink / raw) Interesting, I guess I must be silly too, since I tend to agree with ken on this. Tarjei says "It is trivial to construct a set of primitives that easily can cope with file systems of the most common operating systems (I have a paper somewhere around here on this theme). The point is not to capture all the fine points, but enough to keep the programmers comfortable." Hmm trivial is always a word I find dubious. Will your set of primitives cover mainframe IBM systems (certainly one of the most common operating systems around). How about some of the other systems used in the information systems world, how about real time systems with very limited file systems. Ah! perhaps you meant Unix-like systems when you said common operating systems, that could be it ..... Once you restrict yourself to Unix-like systems, it seems to be that the Posix interfaces are quite appropriate. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-20 0:00 ` Robert Dewar @ 1996-12-21 0:00 ` Tarjei T. Jensen 1996-12-21 0:00 ` Larry Kilgallen 1996-12-22 0:00 ` Robert Dewar 0 siblings, 2 replies; 19+ messages in thread From: Tarjei T. Jensen @ 1996-12-21 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Will your set of primitives cover mainframe IBM systems (certainly > one of the most common operating systems around). How about some of > the other systems used in the information systems world, how about > real time systems with very limited file systems. IBM mainframes have disks and directories if my memory serves me right. The main difference is that the number of levels in the file hiarchy is one (or was it two). One could simulate more levels, but it might not be worth the effort. Greetings, -- // Tarjei T. Jensen // tarjei@online.no || voice +47 51 62 85 58 // Support you local rescue centre: GET LOST! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-21 0:00 ` Tarjei T. Jensen @ 1996-12-21 0:00 ` Larry Kilgallen 1996-12-22 0:00 ` Tarjei T. Jensen 1996-12-22 0:00 ` Robert Dewar 1996-12-22 0:00 ` Robert Dewar 1 sibling, 2 replies; 19+ messages in thread From: Larry Kilgallen @ 1996-12-21 0:00 UTC (permalink / raw) In article <32BC1A02.3DAA@online.no>, "Tarjei T. Jensen" <tarjei@online.no> writes: > IBM mainframes have disks and directories if my memory serves me > right. The main difference is that the number of levels in the file > hiarchy is one (or was it two). One could simulate more levels, but it might > not be worth the effort. If that is the mapping you would propose for DASD, how would you handle partitioned data sets ? Also note that a lot of existing MVS data is quite dependent upon the hardware support for variable length disk records. This seems quite at odds with the "stream of bytes" view someone advocated earlier in this thread. Even though we might all _wish_ there was an easy answer, wishing does not make it so. Posix provides an approach for those running under Unix-emulating subsystems, including MVS Open Edition, but it does not provide transparent access to the bulk of existing data on non-Unix systems. I do not mean to slight the Posix committee(s), some tasks are just too hard. Larry Kilgallen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-21 0:00 ` Larry Kilgallen @ 1996-12-22 0:00 ` Tarjei T. Jensen 1996-12-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 19+ messages in thread From: Tarjei T. Jensen @ 1996-12-22 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > Also note that a lot of existing MVS data is quite dependent > upon the hardware support for variable length disk records. > This seems quite at odds with the "stream of bytes" view > someone advocated earlier in this thread. I have said nothing yet of the datastream. However I think it would be reasonable for Ada to support the concept of variable sized records on architectures that have special support for it (IBM systems, VMS - there must be more of them). However that should not be at the expense of removing the existing support for "stream of byte". I think it would be a good idea for those vendors who sell Ada implementations and their customers to try to hammer out an annex that cover their needs. > Even though we might all _wish_ there was an easy answer, > wishing does not make it so. Posix provides an approach > for those running under Unix-emulating subsystems, including > MVS Open Edition, but it does not provide transparent access > to the bulk of existing data on non-Unix systems. I do not > mean to slight the Posix committee(s), some tasks are just > too hard. I think one should concentrate on one thing at a time. e.g. navigation and simple file system maintenance. A standard way of navigating and being able to reason about a file system is a big plus if you have to keep a piece of software running on several architectures. Once this has been done one can start to worry about other things. The point is to not try to cover everything at once. Divide and conquer! Greetings, -- // Tarjei T. Jensen // tarjei@online.no || voice +47 51 62 85 58 // Support you local rescue centre: GET LOST! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-21 0:00 ` Larry Kilgallen 1996-12-22 0:00 ` Tarjei T. Jensen @ 1996-12-22 0:00 ` Robert Dewar 1996-12-23 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 19+ messages in thread From: Robert Dewar @ 1996-12-22 0:00 UTC (permalink / raw) Larry said "Even though we might all _wish_ there was an easy answer, wishing does not make it so. Posix provides an approach for those running under Unix-emulating subsystems, including MVS Open Edition, but it does not provide transparent access to the bulk of existing data on non-Unix systems. I do not mean to slight the Posix committee(s), some tasks are just too hard." Actually, I think the Posix approach is just fine. Note that you do not have to "emulate Unix" to be Posix compliant, just provide a set of interfaces (which by the way is certainly not full Unix in any case). Manufacturers then make the choice of whether to try to be compliant with this standard or not. So using this apporach you meet half way at an abstract set of interfaces representing a desired set of functionalities. If it is possble to map an OS to this interface, then you do so, rather than trying to make the top level abstraction handle direcly the quirks of every possible operating system. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-22 0:00 ` Robert Dewar @ 1996-12-23 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 19+ messages in thread From: Larry Kilgallen @ 1996-12-23 0:00 UTC (permalink / raw) s In article <dewar.851276907@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Larry said > > "Even though we might all _wish_ there was an easy answer, > wishing does not make it so. Posix provides an approach > for those running under Unix-emulating subsystems, including > MVS Open Edition, but it does not provide transparent access > to the bulk of existing data on non-Unix systems. I do not > mean to slight the Posix committee(s), some tasks are just > too hard." > > > Actually, I think the Posix approach is just fine. Note that you do not > have to "emulate Unix" to be Posix compliant, just provide a set of > interfaces (which by the way is certainly not full Unix in any case). > > Manufacturers then make the choice of whether to try to be compliant > with this standard or not. By "emulate Unix", I meant that portion of Unix which must be emulated to comply with the Posix standards. Restricting this to a very narrow area of file name cases (for purposes of discussion), manufacturers of non-Unix operating systems tend to add a separate file system emulation in order to be able to support case-sensitive filenames. In general (VMS Posix, MVS Open Edition) the full Posix user has a separate little universe for storing and retrieving files, but does _not_ have the ability to access other files stored according to the traditions of the operating system in this fashion. There may be special utilities to do so, but they are not at all standard between manufacturers. This separate-but-compliant approach will work for some application purposes, but by no means all. (Consider a program to read all the traditional files on a system and check for some special trait.) > So using this apporach you meet half way at an abstract set of > interfaces representing a desired set of functionalities. If it is > possble to map an OS to this interface, then you do so, rather than > trying to make the top level abstraction handle direcly the quirks > of every possible operating system. Yes, and the Posix approach handles some cases well. I do not believe going further with a generalized approach would be fruitful. Those who need os-specific access (including me) will just have to do os-specific coding. Larry Kilgallen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-21 0:00 ` Tarjei T. Jensen 1996-12-21 0:00 ` Larry Kilgallen @ 1996-12-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 1996-12-22 0:00 UTC (permalink / raw) "IBM mainframes have disks and directories if my memory serves me right. The main difference is that the number of levels in the file hiarchy is one (or was it two). One could simulate more levels, but it might not be worth the effort." your memory serves you wrong ..... there is no file hierarchy in this sense .. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-18 0:00 ` Larry Kilgallen 1996-12-18 0:00 ` Tarjei T. Jensen @ 1996-12-19 0:00 ` Michael F Brenner 1996-12-19 0:00 ` Larry Kilgallen 1996-12-23 0:00 ` David J. Fiander 2 siblings, 1 reply; 19+ messages in thread From: Michael F Brenner @ 1996-12-19 0:00 UTC (permalink / raw) Paul Whittington said: > I was just working on one of our support packages that interfaces to the > host OS to do file I/O and can't find any support in the Ada Annex set for > a portable way of accessing heir. file systems. I need things like > "MakeDirectory", "RemoveDirectory", etc. Larry Kilgallen said: > On VMS: > Directories can only be nested 8 deep or so if you want > the files they contain to be backed up. ... (and other limitations) > I am certain that other operating systems have quirks as well, > especially when one gets into permissible name lengths and > character sets (which are _not_ necessarily the same as for files). > A common package for directory manipulation would not seem to be > very "portable" if the rules differ on each operating system. Yes there are differences in the limitations of heirarchical file systems. That does NOT lead me to the conclusion that we should not standardize a common subset. When a url, server name, drive name, directory name, filename, or query exceeds the permissions, number of levels, name length, character set, or permissible operations, then raise one of the exceptions url_could_not_be_created, url_could_not_be_located, url_could_not_be_read, url_could_not_be_written, url_could_not_be_deleted, url_could_not_be_made_the_default_directory, or url_is_too_complicated_for_the_target_system. Mike Brenner says: IMO we should standardize a set of machine independent operations on URLs that are equally applicable to all major operating systems, yet raise the correct exceptions when, for example, someone puts spaces in the middle of a filename on a system that prohibits unquoted spaces, such as during ftp to Windows NT or Macintoshes. The facts (VMS has generational datasets while NT does not, various systems have different limitations, DOS is limited to 8.3 characters, devices are handled differently, and quotation characters are incompatible: double quotes versus backslash versus single quotes) do not prevent standardization of a URL object that will handle the common aspects of file systems. The following is a strawman proposal to start discussion of such a standard visible part, (whose body would be implemented using existing Ada-95 facilities, annexes, and interfaces). package url_control is subtype urls is string; -- Example of a URL: -- -- http://email:port/disk:file1/file2/.../filen#anchor?arg1?arg2?...?argk -- -- @ Separators (://, :, /, #, ?) -- @ Words (protocol, email, port, disk, file, anchor, arg) -- @ Nonquoted words may contain alphanumerics, ~, _, !, @, -, and periods -- @ Quoted words may contain anything, doubling the quotes procedure url_break_apart (url: urls; protocol_start: out natural; protocol_finish: out natural; internet_start: out natural; internet_finish: out natural; port_start: out natural; port_finish: out natural; disk_start: out natural; disk_finish: out natural; file_start: out natural; file_finish: out natural; anchor_start: out natural; anchor_finish: out natural; args_start: out natural; args_finish: out natural); procedure directory_changeto (name: urls); procedure directory_create (name: urls); function directory_current return urls; procedure directory_remove (name: urls); function directory_get_first (pattern: urls) return urls; function directory_get_next return urls; function directory_temp return urls; type systems is (default_system, compatible_system, fruit_system, open_system, vegetable_system); procedure set_system (system: systems); function system return systems; function end_of_line_string (system: systems := default_system) return string; function file_name_separator (system: systems := default_system) return character; -- File name separator might be a period or slash depending on -- the operating system. function environment (variable: string) return string; procedure set_environment (variable: string; value: string); procedure delete (url: urls); procedure rename (old_url, new_url: urls); procedure low_level_display_without_loading_text_io (message: string); end url_control; with url_control; package net_control is -- Send and receive files, messages, or queries across the net. procedure transfer (source, destination: url_control.urls); end net_control; Mike Brenner mikeb@mitre.org ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-19 0:00 ` Michael F Brenner @ 1996-12-19 0:00 ` Larry Kilgallen 1996-12-19 0:00 ` Michael F Brenner 0 siblings, 1 reply; 19+ messages in thread From: Larry Kilgallen @ 1996-12-19 0:00 UTC (permalink / raw) In article <59b6ea$522@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes: > IMO we should standardize a set of machine independent operations on > URLs that are equally applicable to all major operating systems, yet > raise the correct exceptions when, for example, someone puts spaces > in the middle of a filename on a system that prohibits unquoted spaces, > such as during ftp to Windows NT or Macintoshes. The facts (VMS has > generational datasets while NT does not, various systems have different > limitations, DOS is limited to 8.3 characters, devices are handled > differently, and quotation characters are incompatible: double quotes > versus backslash versus single quotes) do not prevent standardization > of a URL object that will handle the common aspects of file systems. > > The following is a strawman proposal to start discussion of such > a standard visible part, (whose body would be implemented using > existing Ada-95 facilities, annexes, and interfaces). OK with me, but someone else may kick us off c.l.a due to bandwidth consumption. > package url_control is The letters "url" already have a meaning as "universal resource locator" in HTTP, and although on some Unix systems they may correspond to a file system structure that is by no means required in the HTTP world. The only requirement is that retrieval of information "works" according to the HTTP rules. Thus, I feel overloading the term "url" with something which _does_ correspond to real OS files is a bad idea. > 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)? > 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 ? (Purists would say creating it in the first place is not an acceptable side-effect for a function.) > type systems is (default_system, > compatible_system, > fruit_system, > open_system, > vegetable_system); > > procedure set_system (system: systems); > function system return systems; Hmmm: if system = dos_system then set_system (mvs_system); end if; > 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. > function file_name_separator (system: systems := default_system) > return character; > > -- File name separator might be a period or slash depending on > -- the operating system. Ok, but I don't see "directory start" or "directory end" characters, ([,],<,> on VMS but always matched) such as: DISK$QUENTIN_73:<LARRY.ADA_STUFF.DISCUSSIONS.FILES>PROPOSAL.TXT;24 or $213$DUA7:[ADA$PREDEFINED_ROOT.SYSCOMMON.SYSLIB.][ADALIB]$STANDARD_.ADC;1 > 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", so expanding those routines to support VMS semantics without introducing VMS terminology, how about: type level is (innermost, inner, outer, outermost); function environment ( variable : in String; variable_index : in Natural; case_sensitive : in Boolean; environment_table : in String; environment_table_level : in level ) return string; procedure set_environment ( variable : in string; value : <this really needs to be an array-of-strings>; environment_table : in String; environment_table_level : in level; copy_on_spawn : in Boolean; susceptible_to_outer_level_alias : in Boolean; conceal_contents : in Boolean; terminate_recursive_translation : in Boolean); Larry Kilgallen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-19 0:00 ` Larry Kilgallen @ 1996-12-19 0:00 ` Michael F Brenner 1996-12-19 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 19+ messages in thread From: Michael F Brenner @ 1996-12-19 0:00 UTC (permalink / raw) >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-19 0:00 ` Michael F Brenner @ 1996-12-19 0:00 ` Larry Kilgallen 1996-12-20 0:00 ` Robert A Duff 0 siblings, 1 reply; 19+ messages in thread From: Larry Kilgallen @ 1996-12-19 0:00 UTC (permalink / raw) By the way, I agree with another poster's sentiment "If you want Portable, use Posix". There have been committees hashing out the Posix specifications for years, and it seems infeasible to reinvent the wheel in comp.lang.ada. Nonetheless: In article <59c7sd$osh@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes: >>> 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. No, that is just the point. It "looks like" a filename for certain operating systems, but it need not be implemented that way. If one were to specify that this Ada package used that URL syntax, then there could be two different files with identical URLs, depending on whether one used http or this new package. >>> 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 stash_into (a, directory_get_first ("directory_a")); stash_into (b, directory_get_first ("directory_b")); Now how do I tell directory_get_next which of those two simultaneously active directory iterations I want ? > 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. I can understand that DOS programmers might not bother with separate contexts simultaneously active, but Ada covers a wider range of operating systems than DOS. >>> 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, And what if two copies of my program should need such a facility at the same time? Why make the individual programmer fight over the uniqueness issues, which are, after all, highly OS-dependent ? >>> 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. In the opinion of others, it is an advantage. It is particularly an advantage in the minds of those who prefer VMS to Unix. Saying (implicitly) to programmers that "we are going to stuff restrictions of some other operating system down your throat" while trying to impress them with Ada is not a winning posture. >> Your Unix is showing :-). > Yes, but it is identical in un*x, DOS, NT, etc. Again, the only outlier is > VMS. I think MVS and OS/400 are likewise not following your Unix model, and Microsoft _pretends_ to have invented the world by putting slashes in the other direction :-). As for Macintosh, well one could view the data fork as a stream of bytes, but the resource fork is something entirely different, with capabilities richer than VMS and on the file level even richer than OS/400. > And VMS is now Posix compliant and is capable of running Posix shells > at user request. And Ada is capable of calling Posix services at programmer request :-). > 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. I believe, rather, that it is crucial to support communications with non-Ada programs as well. > You suggested environment_table and environment_table_levels as > interfaces are interesting. What do the levels mean? I think that is _way_ beyond the scope of comp.language.ada, but suffice it to say that the VMS logical name mechanism is _much_ more complex than what would be supported by the simple sequence you proposed. Operating systems are different, and that is a fact of life. Posix shells have been provided on Windows NT, VMS, MVS, etc., but most Ada programmers do not have the luxury of saying to a would-be user of their work "Yes, I can write that in Ada, so long as users all run in the Posix environment." As an example, I would point to the use of the C programming language on VMS, which is almost always done _outside_ the Posix environment, calling real VMS system services, etc. If the C bandwagon (image of wagon rattling downhill out of control, with contents falling out) cannot change VMS culture (despite heavy use), Ada will not either. Larry Kilgallen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-19 0:00 ` Larry Kilgallen @ 1996-12-20 0:00 ` Robert A Duff 0 siblings, 0 replies; 19+ messages in thread From: Robert A Duff @ 1996-12-20 0:00 UTC (permalink / raw) In article <1996Dec19.164901.1@eisner>, Larry Kilgallen <kilgallen@eisner.decus.org> wrote: > stash_into (a, directory_get_first ("directory_a")); > stash_into (b, directory_get_first ("directory_b")); > >Now how do I tell directory_get_next which of those two simultaneously >active directory iterations I want ? And don't forget that Ada has tasks. - Bob ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-18 0:00 ` Larry Kilgallen 1996-12-18 0:00 ` Tarjei T. Jensen 1996-12-19 0:00 ` Michael F Brenner @ 1996-12-23 0:00 ` David J. Fiander 2 siblings, 0 replies; 19+ messages in thread From: David J. Fiander @ 1996-12-23 0:00 UTC (permalink / raw) kilgallen@eisner.decus.org (Larry Kilgallen) writes: > In general (VMS Posix, MVS Open Edition) the full Posix user has a > separate little universe for storing and retrieving files, but does > _not_ have the ability to access other files stored according to the > traditions of the operating system in this fashion. There may be > special utilities to do so, but they are not at all standard between > manufacturers. In particular, OpenEdition MVS has been branded by the X/Open group as Unix. It passes all the tests associated with demostrating conformance to the Single Unix Specification. Oh yeah, and OS/390 Unix also allows any application (OS/390 or POSIX) to access the files in the "other" filesystem relatively simply. - David, who's spent more time in Poughkeepsie than he'd prefer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-18 0:00 Platform portable support of heir. file systems Paul Whittington 1996-12-18 0:00 ` Larry Kilgallen @ 1996-12-19 0:00 ` Robert Dewar 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 19+ messages in thread From: Robert Dewar @ 1996-12-19 0:00 UTC (permalink / raw) Paul asked "I was just working on one of our support packages that interfaces to the host OS to do file I/O and can't find any support in the Ada Annex set for a portable way of accessing heir. file systems. I need things like "MakeDirectory", "RemoveDirectory", etc. Am I missing something, or is it the case that there is no Ada Annex covering this very common need? If there is no Annex support, is the ARA working on some kind of industry agreement about such things? " This is obviously operating system dependent, and not something that one would expect in an OS independent language definition (as a point of comparison, ANSI C does not support these operations either). So you expect to find these operations supported in standard libraries. In the case of Ada 95, there are two possibilities. You can either use a standard Posix interface if one is available, or you can call the C library routines directly using appropriate Import pragmas. Either approach will lead to well defined, portable code. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Platform portable support of heir. file systems 1996-12-18 0:00 Platform portable support of heir. file systems Paul Whittington 1996-12-18 0:00 ` Larry Kilgallen 1996-12-19 0:00 ` Robert Dewar @ 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 19+ messages in thread From: Robert I. Eachus @ 1996-12-19 0:00 UTC (permalink / raw) In article <01bbec7f$453edcd0$24af1486@pc-phw> "Paul Whittington" <paul@sage.inel.gov> writes: > I was just working on one of our support packages that interfaces to the > host OS to do file I/O and can't find any support in the Ada Annex set for > a portable way of accessing heir. file systems. I need things like > "MakeDirectory", "RemoveDirectory", etc. > Am I missing something, or is it the case that there is no Ada Annex > covering this very common need? > If there is no Annex support, is the ARA working on some kind of industry > agreement about such things? There is a standard interface for such things: P1003.5 the POSIX Ada Binding. Not all OSes can support it, but it would be counterproductive to have another "standard." On the other hand complete standard Ada bindings to APIs are a very good idea, but don't belong in the Ada standard since they are OS specific. There exist good thin Ada bindings to most standard operating systems. Programs which use those thin bindings in instead of the POSIX binding are of course less portable. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~1996-12-23 0:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-12-18 0:00 Platform portable support of heir. file systems Paul Whittington 1996-12-18 0:00 ` Larry Kilgallen 1996-12-18 0:00 ` Tarjei T. Jensen 1996-12-18 0:00 ` Larry Kilgallen 1996-12-20 0:00 ` Robert Dewar 1996-12-21 0:00 ` Tarjei T. Jensen 1996-12-21 0:00 ` Larry Kilgallen 1996-12-22 0:00 ` Tarjei T. Jensen 1996-12-22 0:00 ` Robert Dewar 1996-12-23 0:00 ` Larry Kilgallen 1996-12-22 0:00 ` Robert Dewar 1996-12-19 0:00 ` Michael F Brenner 1996-12-19 0:00 ` Larry Kilgallen 1996-12-19 0:00 ` Michael F Brenner 1996-12-19 0:00 ` Larry Kilgallen 1996-12-20 0:00 ` Robert A Duff 1996-12-23 0:00 ` David J. Fiander 1996-12-19 0:00 ` Robert Dewar 1996-12-19 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox