On Thu, May 05, 2005 at 03:45:24PM -0400, Greg A. Woods wrote:
> [ On Tuesday, May 3, 2005 at 17:38:50 (-0500), Richard Rauch wrote: ]
> > Subject: Re: Tab completion in /bin/sh
> >
> > As for removing /bin/ksh altogether: Well, I've been toying with
> > the idea of setting my default shell to /bin/sh...
> 
> Before you do that you might want to consider that (pd)ksh is smaller
> (at least on some platforms, like this alpha):
> 
> 	$ size /bin/*sh
> 	text    data    bss     dec     hex     filename
> 	420304  22400   24212   466916  71fe4   /bin/ksh
> 	457546  17976   21604   497126  795e6   /bin/sh
> 
> (that's from 1.6.x, btw, and of course they're both static-linked)

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 probably have about a dozen shell windows on my current display.
xterm in each case was told to carry about 1000 lines of scrollback
(and two of them have character widths of about 180 cells; all
normally have at least 80 columns; I don't know how efficient xterm
is with scrollback memory...)


 [...]
> > since it is no
> > longer actually required for anything (it used to be that the
> > external "which" command was a csh script
> 
> Yes, because "which" is a csh feature that ((pd)k)sh users should not be
> using ever at all -- the proper true sh equivalent is "type".

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.


> > But, getting back to /bin/ksh: How can you get arbitrary commands
> > to run in your prompt in /bin/sh?
> 
> Probably, but you shouldn't -- there are better ways to get useful
> information about your current session status.  :-)

Are you saying that customizing the prompt shouldn't be done?

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.  (^&)

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.  In
that case, I would just hook up a terminal (if not already attached)
and login as root.  Root's account is pretty vanilla on my systems.


> (and keep in mind that arbitrary length prompts screw up command-line
> editing somewhat too)

IMHO, in NetBSD, both /bin/sh and /bin/ksh handle this reasonably
well.  It does tend to cause problems with /bin/csh (and, I think,
with BASH).  It basically depends on whether the shell actually
tries to deal with this.  (^&


> For example see all the fun in my ksh setup files in:
> 
> 	ftp://ftp.weird.com/pub/local/dotfiles.tar.gz

I'll peruse them, thanks.

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