svn commit: r209221 - head/bin/sh

[Jilles Tjoelker]

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.

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

It beeps first, then asks with the second tab. As said elsewhere in the
thread, it may be useful to allow initial tabs to indent, like zsh and
ksh93 do, to allow pasting script fragments indented with tabs.

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

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

A somewhat related consideration is that this widens the interface
between sh and libedit. Currently, sh only relies on _el_fn_sh_complete
being a libedit key action function for its completion support; all the
magic is in libedit.

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

Adding a few interactive features does not mean I want sh(1) to be a
bash or zsh clone. Rather, I think that they can improve the sh(1)
interactive user experience considerably while adding little code. This
is useful for installations where it is desirable to minimize the number
of ports installed and make buildenv type shells, for instance.

More demanding users will want to use a more powerful interactive shell,
and I think most operating systems based on FreeBSD should provide some
(this does not mean they should be in the base system).

-- 
Jilles Tjoelker