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
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
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
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'.