aburt@koala.uucp (Andrew Burt) (08/10/84)
Someday, when I have nothing to do for a very long time, I'm going to drag out my old ideas and implement them. Like windows for vi. While I've been twidling with the history editor alias, I thought about the little note in csh(1) BUGS: > Alias substitution is most often used to clumsily simulate shell > procedures; shell procedures should be provided rather than aliases. In principle I agree with this; indeed, I have a number of little (Bourne) scripts of the form "exec foo -my_favorite_options $*". On the other hand, there are a lot of things that you want done to your current csh: setting or unsetting environment or shell variables, making or deleting aliases, changing directories, sourcing files, using/abusing history, job control, etc. Csh scripts are also slow to start up, no doubt because of all the aliases I have... Yet it's nice to use csh constructs instead of sh sometimes. So I thought: wouldn't it be nice if there was another form of file, call it a "source file" ("sourcable file"? "macro script"? "in-line script"?) which has these properties: 1) It sits somewhere on your $path like a normal executable file; 2) It looks and feels like a shell script; 3) The csh 'sources's it when it sees it, instead of forking and reading it. I propose the characters "#@" begin such a file, parallel to "#!" for an exec'able one. The csh already has to check for # at the beginning to see if it's a csh script, so #@ isn't much harder. It already knows how to source a file. All we need is to get the two together. Is there any interest in this? On the matter of short command names. I, for one, like single character abbreviations for the most common commands: l for ls, m for more, h for history, and so on. On top of that I have the programmable function keys on my terminal set to the most common ones of these (|m<CR> for instance). They save time. They save finger stress. They are more accurate. (Granted a slip and 'rn' (for readnews) becomes 'rm'; but with no arguments nothing terrible happens. Admittedly you have to watch for these sorts of possible slips. But I maintain that they happen far less often than a typo in a long command name, particularly when you're tired.) Someone suggested here that people who like short names should just learn to type faster. Given that I type in the neighborhood of 110 wpm, I doubt I could ever type "readnews" faster than "rn". 440 wpm would be nice, sure, but... Furthermore, computers are supposed to save you effort, not require you to learn to type faster. It's not really a question of how fast I type it. Frankly the time doesn't bother me. What does is that commonly performed operations should be lengthy to write. You don't see anyone going around writing "three plus three" over "3 + 3" do you? When there IS a better way to do something, why should I stick with the worse way on the grounds that someone looking over my shoulder might understand better? (At that, I don't have to stop typing to say, "rn means readnews".) The philosophy I practice is that any command I execute interactively SHOULD be short to type. Anything I put in a script should be written out completely. It's the same difference between talking casually with friends using your own personal phrases and presenting a technical proposal before a group of non-technical salespeople, bureaucrats, or investors. While you're logged in to your own account, doing your own work, the rules are off -- if you like typing "blt" for "whopper with cheese, no mayo" I say more power to you. -- Andrew Burt Sigma Design, Inc. {allegra,amd,hao,ucbvax}!nbires!koala!aburt