Re: Unixware 2.1.2/Informix Online 7.23: Online won't boot: ulimit '-s': mystery error

Bob Farmer (ucs_brf@unx1.shsu.edu) wrote: : In article <352DCB74.D3AA3D35@echonyc.com>, : Cosmo Lee <*NO-SPAM*cosmo@echonyc.com> wrote: : >[.........] : >re: SCO : > : >I disagree with your opinion on SCO's responsibility. If they are to include : >a man page for `ulimit`, it makes no sense to document only a single option : >(-f) of many, and omit all the other ones as if they don't exist. This is : >surely misleading. How is one to even know that other options exist? Why : >should one have to look in multiple places to find all the options? Is one to : >assume for every command that somewhere, some place else, there are other : >options floating around which are not shown in the man entry? Then what's the : >point of having a *reference* manual? Either put all the options on the : >`ulimit` man page, or don't put them there at all ,and write "see options : >under ksh93". : >[.........] : Well, the "ulimit" program is actually just a shell script that uses the : "ulimit" shell builtin command. (more /usr/bin/ulimit) : Shell builtin commands aren't normally documented in man pages at all. : The proper place to look for documentation on "ulimit" would be in the : shell's man page. I see full info on ulimit in "man sh". Why they chose : to create a man page for it at all is the real question. Or why they : mentioned "-f" and nothing else. May I, about a month late ;-), comment on some of these questions? Yes, the original ulimit command built into the Bourne shell of yesteryear only dealt with the filesize limit, i.e., with the modern ulimit -f (ulimit still defaults to the -f option). Later SVR4 ulimit commands dealt with the full set of possibilities documented for the getrlimit and setrlimit system calls, which superceded the older ulimit(2) system call. In any case, a man page did not then exist, and one had to know to look up the properties of ulimit in sh(1) or ksh(1), just like for the other built-ins such as cd, echo (on System V), or read (the command, not the system call). All this changed with XPG4, the precursor to the UNIX95 specification ("spec1170"). Technically, it moved all of these built-ins out of the shell into utility commands, and in fact demanded that they must exist as separate commands (such as "/usr/bin/cd" for what that may be worth!), even if they are also implemented as built-ins. Correspondingly, these commands now had separate entries in the XPG4 documents, which very much look like man-pages. How they are implemented is not specified, and having a script in /usr/bin call the built-in is perfectly legitimate. Moreover, the specification sets a minimum standard, allows the vendor to add extra options, and only documents the standard options. In the case of ulimit, anything other than ulimit -f is System V Release 4 specific. This meant that the entry in XPG4 only mentions the -f option, and consequently ulimit(1), the man page, also only has the -f option, because it is taken from XPG4. The command itself is richer, and its full features are still disclosed in the shell man page. SCO's fault (or rather, Novell's ;-), is that they took the man page lock stock and barrel from XPG4, without adding the vendor specific features that are actually implemented by /usr/bin/ulimit. That's probably because the technical writer charged with doing this was not familiar with the subject matter. -- ******************************************************************* Martin F. Sohnius zfbuavhf@abiryy.pb.hx Novell IS & T, Bracknell, England +44-1344-724031 ******************************************************************* * if (status = UNDER_NUCLEAR_ATTACK) * * launch_full_counterstrike(); * ******************************************************************* (C) 1998 M.F.Sohnius -- free distribution on USENET (Not a spokesperson -- just a cyclist!)