Subject: Re: bin/4167: WIBNI sh supported file/command/etc completion?
To: Todd Vierling <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/27/1997 18:30:57
In message <Pine.SUN.3.96.970927210316.5965Afirstname.lastname@example.org>
Todd Vierling writes:
>If you want job control, line editing, history, why not just _use_bash_?
>It's not called the Bourne Again Shell for no reason. No commercial unixen
>that I know of have extensive line editing and other features in sh, csh, or
>ksh--you're typically "expected" to install your own shell for the added
Not so. A decade ago, Pyramid OSx dualport Unix shipped with a
/bin/tcsh in the BSD universe. Several commercial systems ship a csh
where you can do `set lineedit'. Maybe your definition of `extensive'
exclude those systems?
Personally, I would be happy to see less bloaed binaries in root
filesystems because it makes installation and `rescue' systems easier.
But the targets I'd go for are things like RPC /YP libraries. (why
include those in a binary that must run in single-user, when there's
no damn portmapper available then? :)
However, creations like POSIX and Single Unix stipulate that certain
progams must be present (at given absolute pathnames, AFAIK) and must
have certain feature sets. Providing two versions of commands (one
for single-user use, one for multi-user) is non-conformant, and
non-conformance with those standards is Just Not Worth It.
OTOH, WTF do we need to have both /bin/sh *and* a /bin/sh with line
editing, job control, etc? Are the semantics really that different?
(I'm a longtime tcsh user, so I have no clue here.)