Subject: Re: bin/4167: WIBNI sh supported file/command/etc completion?
To: John Nemeth <firstname.lastname@example.org>
From: Dustin Sallings <email@example.com>
Date: 09/27/1997 16:14:24
> On Sep 26, 8:33pm, der Mouse wrote:
> } >>> [sh already links with libedit]
> } >> It does? Hm, maybe that explains the major bloat in file size I
> } >> encountered recently while recompiling. Makes me want to submit a
> } >> PR to compile it _out_.
> } > Like I said, I think command editing/history is a POSIX
> } > requirement...
> } So?
> I have to agree with der Mouse here. Just ask me how much I care
> about POSIX...
> In any event, not only is /bin/sh statically linked, it must go
> on install/ERD's (Emergency Recovery Disk). It really needs to be as
> lean and mean as possible. People that want all the fancy command
> line type things that make interactive usage nicer can always use
> bash. Personally, I still use a csh for interactive usage.
I agree here, /bin/sh is used much more commonly for writing shell
scripts than playing the role of an interactive shell in my experience. Most
of the time, it's tcsh or bash for people who want to hang out in a shell.
To me, adding command editing and history features are about as useful as
adding them to the perl or tcl binaries. I'd much rather have a small, fast
loading script interpreter. Does the POSIX requirement actually say that
there has to be a /bin/sh with all these features? It'd be nicer to have
/bin/sh that's a normal /bin/sh (no job control, no editing, etc...) and
maybe another one (even bash) for people who want to hang out in it.