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

Cosmo Lee wrote: > > jerry sutton wrote: > > > Cosmo Lee wrote: > > > > > > We're running Online 7.23 on Unixware 2.1.2 on a SuperMicro dual- <snip> > > > page to find info on the ulimit "-s" option. (Make it hard to find, why > > > don't you SCO!) > > > > You are barking up the wrong tree here and exposing your own ignorance. > > SCO is NOT responsible for the failure of shell builtins to be visible > > at the man command level. As a bit of an aside, Sun is the only vendor > > I know of ever to have documented the shell builtins in separate > > manual pages ... and built a wrapper around source code control system > > which I personally detest, but that's another issue. If you read the > > plain ksh man page you will note that the underlying C language call > > is not ulimit (though there is such a thing) but rather getrlimit() > > and the matching setrlimit(); to my way of thinking these system calls > > supercede the older ulimit(). SVR4 is FAR more complicated than earlier > > releases in terms of providing control over this kind of thing. > > > > re: ignorance > > That's just about the silliest response I've gotten from a news posting. Of > course I'm exposing my own ignorance - I'm asking a non-rethorical question. > Ignorance is a lack of knowledge. One seeks to remedy that lack by posting a > query. I fail to see a point in your remark other than to snipe and > demonstrate how obviously superior your knowledge is. Or perhaps you are > exposing your own ignorance about what newsgroups are for? > > 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". <snip> OK, let me take another crack at it. Go login at an HP-UX 6.2 machine, an HP-UX 9.05 machine, and an HP-UX 10.x machine. Go login at a Solaris 2.x machine. You can try a SunOS4 machine but there is no ksh supplied by Sun; there you can read the csh man page, then you could read the csh man page on all the other vendor/revision combinations as well. Go login at an SGI IRIX4 machine, an IRIX5.3 machine, an IRIX6.0 machine, some old AT&T 3B10 machine, a really underpowered AT&T 3B1/7300 which comes only with hardcopy man pages which you have to pay for. Go login at a MIPS RISCOS5.0 machine if you can find one. Go login at any machine which has a Korn shell. In each case, read the man page(s) for the specific topic 'ulimit'. I have not done the extensive experiment I describe, but I've done enough of it to strongly believe that you will only find one such man page on each system and it will be 'ulimit(2)', which is not applicable ... the other posts replying to you overnight also miss this point ... it's 'getrlimit(2)'. But I'm straying from the main point I am trying to make first: I have zero lost love for SCO, if anything I just plain find their business practices detestable, but SCO did not create this problem - it's been present on every UNIX system I've ever seen, regardless of which vendor it came from. IMHO it's not SCO's place to fix it either ... that just makes their UNIX different. If the problem is to be fixed XOpen should mandate it so everybody who wants to be called UNIX fixes it. I'm not interested in religious wars about standardization vs. anything else so I would prefer that no one launch into one over my expressed opinion noted as such. One of the hardest first lessons I learned in my early days of UNIX development - oh, yeah, try a MassComp MC500 if you can find one - was that the indent for the command(s) to make a target in a makefile must be an ascii TAB character ... not one or more SPACE characters. I must have read the documentation about thirty seven scadzillion times over the course of a week before it jumped out at me off the screen. If I just give you a packaged solution to this kind of issue I fear you will never learn about it. So let me now pose the following questions in an attempt to get you to understand what is going on: 1. What makes you think that any XXXXX(2) man page in particular is guaranteed to be applicable to something you do from a command line? How can you be sure of the mapping? What would you see if you used truss? 2. Maybe more basic, do you understand the distinction that the suffix would make if there were man pages titled 'ulimit(1)', 'ulimit(2)', and 'ulimit(3)'? 3. What does the term 'shell builtin' mean? Does it imply that no subroutine or system call is invoked? 4. If the reference were made in the man page strictly to ksh, what would some poor soul using sh, csh, or tcsh in his first month using a UNIX box know to do? If you did a 'shell builtins' page like SunOS has for csh only and you were using ksh, how would you be helped? Do any of the vendor/revision combinations in your historical search figure out which shell you are using and give you man pages applicable to the shell you are using? Do any of them have setup options to cause the man(1) command to spray you with all possible man pages having pertinence to each of the possible shells? I believe, speaking strictly from memory and obviously subject to being in error, that a historical review will show that the original bourne shell used ulimit(2) with the associated limitations of whatever was implemented by that vendor for that system call in that revision of the OS. My BSD 4.4 Programmer's Reference says getrlimit was originated in 4.2BSD and doesn't appear to have a ulimit in either section 2 or 3. Well, that's probably pretty fragmented but hopefully it's helpful. If not, please just scrap this message. -- Jerry Sutton jerrys@airmail.net and of course, I don't speak on behalf of my employer