MARCUS@MOLE.PCL.AC.UK (NAME) (10/17/89)
(i) Is there any way to get the actual error status of an invoked shell
command rather than the completion status? (Or to determine it after
receiving the PGM_$WARNING status in pgm_$invoke)
(ii) Is there a quick way to get a file's type-uid/size for inclusion in a
directory listing? Stream_$inquire takes forever and a day.
Thanks in advance,
- m a r c u s -kint@software.org (Rick Kint) (10/18/89)
In article <8910171131.AA01220@umix.cc.umich.edu> MARCUS@MOLE.PCL.AC.UK writes: > >(ii) Is there a quick way to get a file's type-uid/size for inclusion in a > directory listing? Stream_$inquire takes forever and a day. stream_$inquire has the unfortunate characteristic of opening files first (like the name implies), which means it isn't too useful for getting attributes for, say, pty files--it hangs. As anyone who has used Apollos for any length of time will guess, there is an unreleased call which does exactly what he seeks... There is also a legal way of doing this, using a UNIX call. The stat call is used to get information about files. This uses the "struct stat" data structure, defined in /usr/include/sys/stat.h. The size of a file in bytes is in the member st_size (declared as an off_t, which is a long) and the block count is in st_blocks (a long). These are standard UNIX file attributes. The type UID is hidden, since it's not standard UNIX. At SR9.X, the type UID of a file is contained in the member st_spare4 (declared: long st_spare4[2]) and at SR10 the type UID is in st_rfu[0] and st_rfu[1] (declared: long st_rfu4[5]). In both cases the first long (st_spare4[0] and st_rfu[0]) is the high part of the UID. This is observed behavior; it isn't documented in anything that I've seen, but canned type UIDs are pretty distinctive in hex. Three problems arise: first, this is C, but using stat from another language shouldn't be too hard; use the insert files for different languages in /sys/ins to see how things are mapped between languages. UNIX calls don't use the std_$call convention, so you need to make sure that pointers are really pointers. Second, if you're at SR9.X and don't have Domain/IX, this information won't help you. The third is a bigger problem. Inclusion of the type UID in struct stat is undocumented (and therefore unsupported) behavior: stat.h at SR10 explicitly states that st_rfu is "reserved to Apollo". The member containing the type UID changed from SR9.7 to SR10, and may very well change again. Programs using this behavior may break in the future. This is not a criticism; Apollo was between Scylla and Charybdis here. If they were to add a new member st_typeuid to struct stat, someone would use this as further evidence that SR10 isn't "JLRU" and make much ado over nothing. Nonetheless, it would be nice to have a dependable, supported way to access Apollo-specific file attributes. And if anyone from Apollo is listening: just what does the name "rfu" stand for? For some reason, the expression "JLRFU" comes to mind... -- Rick Kint CSNET: kint@software.org Software Productivity Consortium ARPANET: kint%software.org@relay.cs.net Herndon, VA UUNET: ...!uunet!sunny!kint
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (10/20/89)
Well, the file size can be obtained from the MS_$ATTRIBUTES call (which is an Apollo specific call). The type UID can be obtain from IOS_$INQ_TYPE_UID (also an Apollo specific call). I don't know if the combination of these 2 calls is faster than STREAM_$INQUIRE or IOS_$INQUIRE... In any case you probably should use the IOS call rather than the STREAM calls. They are the newer implementation. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)