ecarroll@csvax1.cs.tcd.ie (Eddy Carroll) (09/12/89)
In article <13557@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > Why can't the computer > clerisy come up with idiot-proof arguments lists!? My favorite is "strcpy;" > I can *never* remember the order for the arguments. And getting them wrong > will fry your code as bad as shorting any op-amp. For what it's worth, I remember strcpy, memcpy etc. by mentally sticking an '=' between the two arguments. I forget where I read this, but it's never confused me since. :-) As I recall, ADA lets you specify procedure/function parameters in any order you like, as long as you remember to qualify them with the formal name of the parameter. So do most of the CLI commands, for that matter. -- Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until INTER: ecarroll@vax1.tcd.ie | you've died in MUD!" UUCP: {..uunet}!mcvax!ukc!vax1.tcd.ie!ecarroll | -- Richard Bartle
charles@hpcvca.CV.HP.COM (Charles Brown) (09/26/89)
>> Actually, the feature *can* save you lots of disk space. eg: >> compress. Compress, uncompress, and zcat all use enough of the same >> code that they are designed to look at argv[0] and decide how to act. > The trouble with programs whose behavior depends on (a) the command > line entry or (b) the filename is that they are a bit tricky for an > environment that is as "uncontrolled" as the Amiga's. There is too > much risk of my wanting to have two different but closely related > programs from different authors around at the same time with "naming" > conflicts for me to be happy with behavior that depends on a > hard-coded name. This is why aliases should not change argv[0]. If the program does check its identity (and whether you like it or not, several important existing programs already do) it should get the appropriate answer. If you want to call it by another name to keep it distinct in your mind, then aliases are completely appropriate. Of course the alias can specify the full path, so the fact that both programs have the same name is no problem. > For example, there was a period earlier this year > when I found myself wanting to have two different versions of > "execute" handy. If our concern is with redundant code in the > "system", we should use libraries. > --William F. Hammond Dept. of Mathematics & Statistics This only addresses a fraction of the utility of links. Links are useful for ALL FILES, not just executables. I can link font directories from several places into a central repository. I can link several sets of libraries to make them accessible from one location. Granted this could also be done by changing the OS to search a path for L: LIBS: FONTS: DEVS: etc etc etc. In fact I would also like to see that done. But I still want links. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer. "You can lead a horticulture, but you can't make her think."