svn commit: r209221 - head/bin/sh

[Doug Barton]

On 06/17/10 14:55, Jilles Tjoelker wrote:
> On Thu, Jun 17, 2010 at 12:36:51PM -0700, Doug Barton wrote:
>> On 06/17/10 03:03, Andrey Chernov wrote:
>>>>> Jilles Tjoelker<jilles at FreeBSD.org>   writes:
>>>>>> Log:
>>>>>>     sh: Add filename completion.
>
>> 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.
>
> Hmm, I see no problems with setting the shell of my unprivileged user to
> something dynamically linked in /usr/local/bin.

I use the same profile/bashrc/etc. for my local users, root, remote 
users, etc. Starting with sh and only exec'ing bash if it's viable has 
solved the occasional problem of something going screwy that prevents 
bash from running (and thereby preventing me from logging in remotely). 
It also helps when I'm in single user mode.

> Yes, many other shells complete command names at appropriate places in
> the line. However, at this time, it doesn't really fit in my idea of
> what sh(1) should be.

If I'm understanding the other comments and various other feedback 
correctly, at this point I think it would be worthwhile for you to post 
your plans to -arch and let people comment before proceeding with more 
changes.

> Listing all possible command names is a fair bit
> of functionality not present yet (sh only caches command pathnames that
> have been used, it does not readdir all of $PATH like tcsh does).

This is a perfect example of why I'm concerned about adding incompletely 
implemented features of an interactive shell to our sh. I'd prefer that 
there be a separation, but if you do post your plans to -arch I'd like 
to hear what others have to say as well.

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


-- 

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