beech@ms.uky.edu (Wayne Beech) (11/22/89)
I think some people missed the point of my letter since the only responses i have gotten back have been on the order of "but not all operating systems have hierarchal file systems". this was my original letter: > Does anyone know the rationale behind not specifically defining a set of > functions to work with directories in ansi C; things like opendir(), > next_dir_entry(), isdir(), etc. if you are writing a program that works > with directories that is expected to run on unix and non-unix machines how > do you handle this? with a bunch of #ifdef UNIX #elif SOMEOTHERMACHINE ....? the names i made up were just examples.....if you were on a system such as cms then isdir() would be easy to write since it would also return FALSE. what i was getting at was most programs perform their work on files so it looks like there would have been something mentioned in the standard about handling routine actions on file systems, things like how do you get the names of files in a directory( or on a minidisk). -- ============================================================================= UUCP : !ukma!beech BITNET: beech@ukma DOMAIN: beech@ms.uky.edu
chris@mimsy.umd.edu (Chris Torek) (11/23/89)
Directory operations would be useful. But so would other things: `Aye, there's the rub.' Where should they stop? An operation to check the status of another process would be useful. MS-DOS (which has no processes) would always say `no such process'. Coroutines (another recurring, ah, thread, in comp.lang.c) would be useful too. So would standard routines for manipulating the robot arm. (If you have no robot arm, these simply return an error.) We should not slight the temperature-and-humidity environment control routines, either. And then there are the radar missile-detector routines, and . . . . Some would say that the C standard should not even describe *any* `file' operations; fortunately, it allows such implementations, as what amounts to a subset of the standard (though it is not called that). In any case, directory operations were clearly beyond the scope of the standard at the time it was begun---opendir &c. were nowhere near universal in 1985. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
mike@ntmtka.mn.org (Mike Tietel) (11/23/89)
In article <13295@s.ms.uky.edu>, beech@ms.uky.edu (Wayne Beech) writes: > what i was getting at was most programs perform their work on files so it > looks like there would have been something mentioned in the standard about > handling routine actions on file systems, things like how do you get the > names of files in a directory( or on a minidisk). I think you may be overgeneralizing to say that "most programs perform their work on files...". Perhaps most programs you design and implement perform their work on files, however, I am certain that there are more than a few programs that do not perform their work on files. Perhaps you could write your own interface library to provide the needed functionality. For the given program, the process of porting to a new machine then consists of updating the interface library... int isdir(name) char *name; { #ifdef SYSTEMV ... #endif SYSTEMV #ifdef BSD ... #endif BSD #ifdef MSDOS ... #endif MSDOS } just a thought... mjt -- Mike Tietel Northern Telecom, Inc. (612) 932-8017 9701 Data Park, S-100 mike@ntmtka.mn.org Minnetonka, MN 55343 uunet!rosevax!ntmtka!mike
minow@mountn.dec.com (Martin Minow) (11/23/89)
In article <20881@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >In any case, directory operations were clearly beyond the >scope of the standard at the time it was begun---opendir &c. were >nowhere near universal in 1985. Decus C supported directory operations in its first public release in 1981. The code ran on a half-dozen operating systems. I even wrote Unix-specific variants of the functions around that time, but I cheated by implementing the directory scan operation by opening a pipe and forking a subprocess that executed the 'ls' command, then parsing the results. (A classic Unix hack if there ever was one.) So, there was prior art, even if it wasn't politically correct. Martin Minow minow@thundr.enet.dec.com The above does not represent the position of Digital Equipment Corporation
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/25/89)
In article <1848@ntmtka.mn.org> mike@ntmtka.mn.org (Mike Tietel) writes: >In article <13295@s.ms.uky.edu>, beech@ms.uky.edu (Wayne Beech) writes: >> what i was getting at was most programs perform their work on files so it >> looks like there would have been something mentioned in the standard about >> handling routine actions on file systems, things like how do you get the >> names of files in a directory( or on a minidisk). Although I have reasonable, standard functions for accessing directories, I find that it is quite rare for programs to use them. The main reason for this seems to be that pathnames are generally provided as arguments to programs, so they have no need to rummage around in directories. The exception is for user interface programs (shells, desktop finders, etc.) which of course are expected to be able to display contents of directories, perhaps via menus. Thus, while it is quite important for C applications to be able to access files by name, it is much less important for them to be able to access the contents of directories. Also, many systems either do not HAVE directories (although they do have named files) or their directories contain much important information that is too system- specific to allow for in the universal C standard. IEEE Std 1003.1-1988 (POSIX system interface) does specify a set of standard directory access functions that work reasonably well in most UNIX-like contexts. Kirk McKusick of UCB published an earlier, not quite POSIX-compatible, implementation and I've been providing a fully POSIX-compliant public-domain implementation for UNIX variants. Others have adapted these or provided equivalents for non-UNIX systems. Thus, the POSIX directory access functions are about as standard as you can get.
peter@ficc.uu.net (Peter da Silva) (11/25/89)
In article <20881@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > Directory operations would be useful. But so would other things: > `Aye, there's the rub.' Where should they stop? Good question. How about the subset of operations that are available in UNIX, MS-DOS, VMS, VM/whatever...? > An operation to > check the status of another process would be useful. MS-DOS (which > has no processes) would always say `no such process'. This one makes sense, because there's no consensus on what a process is. > Coroutines > (another recurring, ah, thread, in comp.lang.c) would be useful too. This is a hardware independent capability... anything that can implement a useful 'C' can implement coroutines. (counterexamples are left to Henry Spenser... I'm sure he'll come up with one). The lack of prior art is the best defense against this yawning lacuna. > So would standard routines for manipulating the robot arm. (If you > have no robot arm, these simply return an error.) We should not > slight the temperature-and-humidity environment control routines, > either. And then there are the radar missile-detector routines, > and . . . . And these depend on the existance of rare and expensive hardware. Any hosted implementation has a file system. If anyone's interected in the design of a wider "standard" environment, send mail to me and join the C-FUTURES mailing list. Let's fill the gap between ANSI and POSIX. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
henry@utzoo.uucp (Henry Spencer) (11/26/89)
In article <11681@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Although I have reasonable, standard functions for accessing >directories, I find that it is quite rare for programs to use them. >The main reason for this seems to be that pathnames are generally >provided as arguments to programs, so they have no need to rummage >around in directories... As an example of this, consider C News. This is a non-trivial software package with a lot of different functions. Our informal early releases included Doug's directory routines. We left them out of the production release, because nothing ever used them. (Actually, there is now one optional program that uses directory functions. It's a speeded-up version of something we also supply as a shell file.) -- That's not a joke, that's | Henry Spencer at U of Toronto Zoology NASA. -Nick Szabo | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jfh@rpp386.cactus.org (John F. Haugh II) (11/26/89)
In article <7100@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >And these depend on the existance of rare and expensive hardware. Any hosted >implementation has a file system. i've worked on enough strange o/s's that i can safely say the number of operations common to all hosted implementations directories is the empty set. >If anyone's interected in the design of a wider "standard" environment, >send mail to me and join the C-FUTURES mailing list. Let's fill the gap >between ANSI and POSIX. vm/cms file names don't include spaces, but have three parts. ms/dos file names do include spaces, but limit the type specifier to three mono-case characters. rt/11 has radix-50 file names packed into 6 bytes each with a very limited set of characters. somehow i don't think there is much room left in there for a standard. oh - i forgot about vax/vms where you get two parts, plus some strange directory name format =and= version numbering that may make file names totally ambiguous =and= you might even be able to squeeze a logical name, dec-net node, disk device and probably even a moon-phase in for good measure. hell, my hp-41cv didn't even have a directory, i think. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of IBM is ... InterNet: jfh@rpp386.cactus.org | ... I've Been to a Meeting. UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--Yea!--
peter@ficc.uu.net (Peter da Silva) (11/27/89)
In article <17359@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: > i've worked on enough strange o/s's that i can safely say the number of > operations common to all hosted implementations directories is the > empty set. The only operating systems I know of that wouldn't support "Open current directory", "Next file in current directory", and "Close current directory" are either obsolete (one person brought up CDC NOS) or are required to hide file names for security reasons. Given your security background I would expect such operating systems would loom pretty large, of course. [ long description of weird file name conventions ] Yes, but that's not relevant. Nobody said that the standard had to specify what a file name looks like. All these apply equally to "fopen", etc... > hell, my hp-41cv didn't even have a directory, i think. Didn't have files, either. And probably can't run C. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
mcdonald@uxe.cso.uiuc.edu (11/27/89)
>vm/cms file names don't include spaces, but have three parts. ms/dos >file names do include spaces, but limit the type specifier to three >mono-case characters. rt/11 has radix-50 file names packed into 6 >bytes each with a very limited set of characters. somehow i don't >think there is much room left in there for a standard. >[plus VMS oddities - JDM] *****THEN WHY IS THERE SUPPORT FOR FILES IN STANDARD C???????******* You haven't even MENTIONED directories - only files. Doug McDonald
tarvaine@tukki.jyu.fi (Tapani Tarvainen) (11/27/89)
Irrelevant though it really is to the discussion at hand, I can't let these pass by: In article <17359@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: > hell, my hp-41cv didn't even have a directory, i think. In article <7108@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Didn't have files, either. And probably can't run C. The HP-41 most definitely has both files and directories. (Not subdirectories, though: Each disk/cassette/ramdisk has a single-level directory. File names consist of 7 characters, types are coded separetely and you can't have two files with the same name but different type.) What comes to running C, well, I don't think a C compiler for it exists, or is likely to -- but impossible it wouldn't be. Not even a full hosted implementation, I think. (Perhaps I should try writing one. Sounds like fun, and probably would be a good contender for the "weirdest machine ever to run C" contest: Two separate address spaces, one 10-bit words with 16-bit addresses, the other 56-bit words with 10-bit addresses, CPU registers 56 bits wide; the OS doesn't know the concept of "command line", though it could be faked; etc.) -- Tapani Tarvainen (tarvaine@tukki.jyu.fi, tarvainen@finjyu.bitnet)
seanf@sco.COM (Sean Fagan) (11/27/89)
In article <7108@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >The only operating systems I know of that wouldn't support "Open current >directory", "Next file in current directory", and "Close current directory" >are either obsolete (one person brought up CDC NOS) or are required to hide >file names for security reasons. Hey! NOS *would* support these! Since you have nothing *other* than "current directory," and you certainly can have files, it kinda falls through. However, I'm not sure it would be worth it (memory limits and the like). It's possible that opendir / readdir et al should have been included. I'm still fuzzy on the idea, however. -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
tainter@cbnewsd.ATT.COM (johnathan.tainter) (11/28/89)
In article <225800244@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >> [ discussion of varied file name conventions ] somehow i don't >>think there is much room left in there for a standard. >*****THEN WHY IS THERE SUPPORT FOR FILES IN STANDARD C???????******* Because operations on the CONTENTS of files are sufficient common enough to impose some very weak standards. >You haven't even MENTIONED directories - only files. Actually, he has described the CONTENTS of directories. There is no well defined set of operations which will cover these. Some of the more problematic things he hasn't even covered. Like the fact that UNIX divides its "directory" information into distinct components and can share the i-node portion. That some systems maintain multiple versions of a file with version information not in the name but in the directory or encoded in the structure of the directory. That protection/access schemes very widely, that interesting and wildly different archiving schemes are encode in directories and so on. Yes, an all things to everyone scheme could have been defined to cover all known (at the moment) cases, but the code which would handle it would be wildly system dependent anyway. At least, dependent on which combination of schemes is chosen, almost the same thing with the huge matrix of combinations we would get. And it would be problematic for porting C to a new sytem using some other never before seen scheme. If you mean lets put in mkdir(), rmdir() (maybe a mvdir()? lndir()?) what does this buy us? How useful to the common user is such a facility? What does portability in the function interface buy you if you have to have conditional code anyway to handle the differences in directory schemes? >Doug McDonald --johnathan.a.tainter-- att!ihlpb!tainter
peter@ficc.uu.net (Peter da Silva) (11/29/89)
In article <3332@cbnewsd.ATT.COM> tainter@cbnewsd.ATT.COM (johnathan.tainter,ih,) writes: > Because operations on the CONTENTS of files are sufficient common enough > to impose some very weak standards. So, what should the first argument to fopen() be on an Unisys 1100? -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/30/89)
In article <7127@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >So, what should the first argument to fopen() be on an Unisys 1100? A filename, whose mapping to file access is defined by the implementation. X3J11 tried to identify a minimal "portable filename" subset for use in applications as header file names. There almost wasn't any common subset. I think we figured out that five monocase alphabetics followed by ".h" would be all that could be guaranteed across all the C implementation environments we knew of, and there were problematic aspects of even such a minimal guarantee. That hardly seemed worth the trouble.
peter@ficc.uu.net (Peter da Silva) (12/01/89)
In article <11707@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > In article <7127@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >So, what should the first argument to fopen() be on an Unisys 1100? > A filename, whose mapping to file access is defined by the implementation. Good. We've established that. Now why can't the same semantics be defined for directory reading utilities? -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
chad@csd4.csd.uwm.edu (D. Chadwick Gibbons) (12/02/89)
In article <7156@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: |In article <11707@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: |>In article <7127@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: |>>So, what should the first argument to fopen() be on an Unisys 1100? |> A filename, whose mapping to file access is defined by the implementation. |Good. We've established that. Now why can't the same semantics be defined |for directory reading utilities? I'm sure the concept of a file is more inherit to operating systems than is the concept of a directory. It wouldn't be appropriate for the standard to cover directories. Of course, X3J11 did include system() within the standard, so who knows what they think at times. The whole concept of the system() call won't work on many operating systems, and even though it isn't required to do anything, it seems to be one of those functions that is ignored if not implemented. Neat.
randall@uvaarpa.virginia.edu (Randall Atkinson) (12/03/89)
People looking for a standard way to access files and directories should be looking at the standard for the C language bindings of the portable operating system interface for computer environments (POSIX). It is IEEE 1003.1-1988 and is available from the IEEE Standards Office [ +1 (212) 371-0101 by telephone]. ANSI C specifies the C Language not full OS interfaces. There is a standard for the OS interfaces and POSIX is it. The IEEE POSIX committee and the ANSI C committee did a good job of coordinating their efforts and the result is usable. Questions about POSIX should be redirected to comp.std.unix and questions about ANSI C should really be placed in comp.std.c Can we let this die in comp.lang.c now ?? (rhetorical question) Ran randall@Virginia.EDU
peter@ficc.uu.net (Peter da Silva) (12/03/89)
> |>>So, what should the first argument to fopen() be on an Unisys 1100? > |> A filename, whose mapping to file access is defined by the implementation. > |Good. We've established that. Now why can't the same semantics be defined > |for directory reading utilities? > I'm sure the concept of a file is more inherit to operating > systems than is the concept of a directory. In any system for which files have names, there is at least one directory. Thus a routine that returns the names of files in at least the current directory is more generally portable than system(). And, as you pointed out, system() is in the standard. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
peter@ficc.uu.net (Peter da Silva) (12/04/89)
In article <1666@uvaarpa.virginia.edu> randall@uvaarpa.Virginia.EDU (Randall Atkinson) writes: > ANSI C specifies the C Language not full OS interfaces. There is > a standard for the OS interfaces and POSIX is it. Wrong. POSIX is a standard for the UNIX OS interface. It is not implementable on most personal computers, for example. There is a huge gap between what ANSI specifies and what's useful on most systems, and nother huge gap between that and POSIX. > Questions about POSIX should be redirected to comp.std.unix and > questions about ANSI C should really be placed in comp.std.c And pepole really trying to bridge the gap should get into the C-FUTURES mailing list. *AND* comp.lang.c. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
jbeard@quintus.UUCP (Jeff Beard) (12/05/89)
> >> I'm sure the concept of a file is more inherit to operating >> systems than is the concept of a directory. > >In any system for which files have names, there is at least one directory. > >`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. Sorry Peter, IBM MVS and DOS/VSE both have file names without resorting to a directory file structure. We have a name clash on 'DIRECTORY'. Files must be anchored somehwere and sometimes it is in an object called a directory. This may or may not be the same as a file system that is implemented as a hierarchal directory (as in Unix). In the MVS and DOS/VSE cases cited, each physical disk contains a VTOC in which all file names on that volume are recorded. File names may *appear* is if in a hierarchy but this is not the case. File names may also be 'catalog'ed in a system index. The information recorded allows deduction of the disk volume required to find a specific file name, with the restriction that there is no duplicates allowed. ====== Opinions are the possession of the speaker and to assert otherwise is plagiarism. Jeff Beard, Quintus Computer Systems, Inc. e-mail ...!amdahl!sun!quintus!jbeard phone (415) 965-7700
gwyn@smoke.BRL.MIL (Doug Gwyn) (12/05/89)
In article <7193@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In any system for which files have names, there is at least one directory. Not necessarily one that could be opened by name. >Thus a routine that returns the names of files in at least the current >directory is more generally portable than system(). The concept of "current directory" is also not portable. >And, as you pointed out, system() is in the standard. system() was in the library Base Document; the dirent stuff wasn't.
peter@ficc.uu.net (Peter da Silva) (12/05/89)
In article <1289@quintus.UUCP> jbeard@quintus.UUCP () writes: > >> I'm sure the concept of a file is more inherit to operating > >> systems than is the concept of a directory. > >In any system for which files have names, there is at least one directory. > Sorry Peter, IBM MVS and DOS/VSE both have file names without resorting to > a directory file structure. They have a directory. It may be flat, but it's a directory. A directory is just a thing you can ask for a list of names. Sometimes it's called a catalog, or a table of contents, or a volume, or whatever. It's still a directory. > We have a name clash on 'DIRECTORY'. I guess. What do you call the thing you get when you type "dir" in CP/M? -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "If you want PL/I, you know where to find it." -- Dennis
peter@ficc.uu.net (Peter da Silva) (12/05/89)
In article <11738@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > In article <7193@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >In any system for which files have names, there is at least one directory. > Not necessarily one that could be opened by name. Doesn't have to. Surely you can see a way around that. Have a default that's used when you specify a file name of NULL. > >Thus a routine that returns the names of files in at least the current > >directory is more generally portable than system(). > The concept of "current directory" is also not portable. Sure it is. It's where the system looks up the file names you give it. > >And, as you pointed out, system() is in the standard. > system() was in the library Base Document; the dirent stuff wasn't. Pity. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "If you want PL/I, you know where to find it." -- Dennis
tanner@cdis-1.uucp (Dr. T. Andrews) (12/07/89)
In article <11738@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > system() was in the library Base Document; the dirent stuff wasn't. Prototypes weren't in the language base document. -- Mulroney: "Cut trains. Drive in | {bpa,uunet}!cdin-1!cdis-1!tanner Canada. We need the acid rain." | {attctc gatech!uflorida}!ki4pv!cdis-1!tanner