[ On Thursday, May 5, 2005 at 17:52:23 (-0500), Richard Rauch wrote: ]
> Subject: Re: Tab completion in /bin/sh
>
> But I'm not running them on machines where that size difference
> will matter much.  (And what are the actual working set sizes for
> "normal" interactive use?)

I don't have enough plain /bin/sh processes running long enough to tell,
let alone any shell sessions using /bin/sh, especially since now even
root's shell is /bin/ksh on all my systems.  :-)

> I don't know how efficient xterm
> is with scrollback memory...

Not very....  :-)


> 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?"

(and finding the location of a binary executable as more of a
side-effect to telling you that it is a binary executable :-)


> 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] $ 


> 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:

	20:12 [2365] $ type setban        
	setban is a function
	20:12 [2366] $ typeset -f setban
	function setban {
	    if [ "$uid" = "$LOGNAME" ] 
	    then
	        eval TBANNER="\"\${WBANNER:-sh}://\$UUNAME/\$PWD | \$uid[\$LEV]:\$TTYN\"" 
	    else
	        eval TBANNER="\"\${WBANNER:-sh}://\$UUNAME/\$PWD | \$uid(\$LOGNAME)[\$LEV]:\$TTYN\"" 
	    fi 
	    print "\033]0;$TBANNER\007\c" 
	    WBANNER="" 
	} 
	20:12 [2367] $ 

(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
only count raw characters in the prompt too -- and thus long prompts
including $PWD, or variable-length prompts, or especially prompts
including escape sequences or tabs, get to be too unwieldy for me.

Worst of all though /bin/ksh pretty much fails completely if the prompt
length ever appropaches the window width.


> 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....

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>