On Thu, May 05, 2005 at 08:20:13PM -0400, Greg A. Woods wrote:
> [ On Thursday, May 5, 2005 at 17:52:23 (-0500), Richard Rauch wrote: ]
 [...]
> > I use "which" because it's what my fingers know.  "type" is what the
> > Amiga used as the equivalent of UNIX (to "type out" a file, of course),
> > so my fingers just don't want to pick up "type" to do what "which"
> > does.
> 
> Perhaps you can think of it as:  "What _type_ of command is this?"

Maybe it should be renamed to "what", then.  (^&

$ what cat
Stress reliever.
$ what man
Feeds cat.
$ what dog
Dog not found.
$ what strip
What kind of computer do you think I am?
$ 


 [...]
> > Are you saying that customizing the prompt shouldn't be done?
> 
> No, on the contrary -- you'll find that I put useful info in my own
> prompt too:
> 
> 	20:11 [2362] $ echo $PS1 
> 	${_x[(_m=_mm)==(_h=_hh)]}$_h:$_m [!] $
> 	20:11 [2363] $ 

My problem is that you're stuck to the "clip art" effect here: Only
things that someone thought to build into the shell already are available.
(Of course, you can modify the shell source, but the average user can't
rebuild /bin/ksh...)


> > Or that having a program or two run everytime I get a prompt is
> > bad?  (I don't find my systems brought to their knees in building
> > a prompt.  (^&)
> 
> Well executing commands on every prompt should simply not be necessary
> since most useful information either remains static or is too variable
> in length to "safely" put in a prompt:

I have no problem with long information in my prompt.


> (in my interactive sessions "cd" is also an alias for "_cd", which is a
> function that, among other things, eventually calls "setban")
> 
> In my opinion neither /bin/sh nor /bin/ksh (on NetBSD) are sufficiently
> capable at screen management to properly handle long command editing in
> the first place (they don't even try to do wrap-around), and they can

/bin/sh seems to do line-wrap.  /bin/ksh does side-to-side scrolling.
Both seem to work.  (At least in approx. 2.0; maybe 1.6 was different.)


> > I guess if something happened such that trying to exec the code in
> > those files would cause the process to freeze forever, then it
> > would prevent me from getting a prompt or doing anything else.
> 
> That's another very important issue to think about too!  ;-)
> 
> And then there was that thread the other day about keeping track of
> exit codes too....

Yeah, but I don't use those interactively.  So that's not a loss for
me.  (^&


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/