nelson@ohlone.UUCP (Bron Nelson) (10/16/87)
In article <3126@ames.arpa>, msf@amelia (Michael S. Fischbein) writes: > [On] most machines, a fork/exec does not impose the huge overhead it does > on a Cray (well, I don't know abou XMPs or 1's, but the overhead on > the 2 is awfully big compared to other UNIX boxes). True enough; but then YOU try implementing vfork on a machine whose idea of "memory management" is one pair of base/bounds. > One major complaint > about typing > ls | pr -4 -t instead of > ls -C (the -C is needed in UNICOS) > is the extra typing involved and the additional requirements it places > on the (perhaps naive) user. One major complaint about the list of > options approach is the size and complexity of each utility. > [...] > Ls doesn't have to develop and debug a column routine; a ["system"] > call to pr will work. That doesn't involve creating a new Pipeline > Composer, either. Building in functionality via the "system" call does not cut down on the fork/exec/read/write etc. My reading of the discussion was that people were complaining about the size of utilities like ls, and other people were of the opinion that linking to other utilities via pipes or "system" was too slow to be an acceptable option, and the increased size of e.g. ls, is not unreasonable. If your system can indeed run fork/exec/open/dup/read/write fast enough so that your major complaint is the amount of typing, then you can get all the functionality you want and still keep the utilities small by using shell scripts and/or aliases. ----------------------- Bron Nelson {ihnp4, lll-lcc!lll-tis}!ohlone!nelson Not the opinions of CrayY)!J!Bb-!$