svn commit: r209221 - head/bin/sh

[Doug Barton]

On 06/17/10 03:03, Andrey Chernov wrote:
> On Thu, Jun 17, 2010 at 02:34:41AM -0700, Brian Somers wrote:
>> On Wed, 16 Jun 2010 03:30:45 +0200 Dag-Erling Sm??rgrav<des at des.no>  wrote:
>>> Jilles Tjoelker<jilles at FreeBSD.org>  writes:
>>>> Log:
>>>>    sh: Add filename completion.
>>>
>>> Wonderful!  Now I'll never have to use csh again :)
>>
>> Is there a plan to change root's shell from csh to sh?  If not, should there be?
>> I've been doing this locally for 17 years.

Me too (as in, always changing it), but every time this is discussed 
it's the bikeshed from $CULTURALLY_RELEVANT_PLACE_OF_TORMENT. FWIW, what 
I actually do is set the shell for both root and my unprivileged user to 
sh, compile bash static, and put a copy of the static shell in /root. 
Then my .profile tests for the existence of bash and execs it if available.

> sh completion works very strange at now moment.

These are basically bourne-type shell behaviors that are different from 
*csh.

> Just two things:
>
> 1) $^I
> Display all 973 possibilities? (y or n)
> (tcsh - beep)

bash also beeps here, FWIW, although I think there is a knob to twist to 
make it do what sh is doing here.

> 2) $ll^I
> beep
> second ^I
> completion, including non-program files.

This is a libedit thing. libreadline (which is what bash uses) has a 
flag to control this behavior that you can add to ~/.inputrc which makes 
it show all of the options the first time. The inclusion of non-program 
files in the current directory as input to a command is a feature, since 
it allows you to do things like:
cd /etc
vi make^I

Having the shell include non-{program|alias} stuff as the first 
completion is dubious (bash does not do this).

> (tcsh - completeion, programs&  aliases only)
>
> I don't remember other strange places right now. Verdict - not usable yet.

I've been very supportive of Jilles work up to this point, and I think 
he's done a great job of making our sh functional and compliant as a 
scripting shell. However in my mind adding completion (and his suggested 
inclusion of the kill builtin) tips the balance from "good system shell" 
to more of an interactive shell, and that makes me wonder if this is the 
right direction to go in. If we want a good interactive bourne-based 
shell in the base I'd rather have the discussion about which one to 
import, rather than trying to have our sh catch up with the last 15 
years of development in this area.


Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/