PATCH: new shells completion type

PATCH: new shells completion type

[Doug Kearns]

Here is a new completion type for shells. It seems to me that if we're
going to complete shells from /etc/shells then it should be restricted
_only_ to shells listed there. This will change the behaviour of useradd
completion which always included /bin/false.

Any objections?

Regards,
Doug

Index: Completion/Unix/Command/_screen
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_screen,v
retrieving revision 1.10
diff -u -r1.10 _screen
--- Completion/Unix/Command/_screen	11 Jun 2005 12:28:17 -0000	1.10
+++ Completion/Unix/Command/_screen	22 Jun 2005 12:36:08 -0000
@@ -76,7 +76,7 @@
   '-q[quiet startup, exit with non-zero return code if unsuccessful]' \
   '-r[reattach to a detached screen process]: :->detached-sessions' \
   '-R[reattach if possible, otherwise start a new session]: :->detached-sessions' \
-  '-s[shell to execute rather than $SHELL]:shell name: _command_names -e' \
+  '-s[shell to execute rather than $SHELL]:shell:_shells' \
   '-S[name this session <pid>.sockname instead of <pid>.<tty>.<host>]:session name' \
   "-t[set title (window's name)]:title" \
   '-T[use term as $TERM for windows, rather than "screen"]:terminal type:_terminals' \
Index: Completion/Unix/Command/_user_admin
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_user_admin,v
retrieving revision 1.6
diff -u -r1.6 _user_admin
--- Completion/Unix/Command/_user_admin	8 Jun 2005 12:45:35 -0000	1.6
+++ Completion/Unix/Command/_user_admin	22 Jun 2005 12:36:08 -0000
@@ -6,12 +6,6 @@
 redhat=$?
 
 if [[ $service = user* ]]; then
-  if [[ -r /etc/shells ]]; then
-    shells=( ${${(f)"$(</etc/shells)"}:#\#*} )
-  else
-    shells=( ${(M)commands:#*/(|[abckz]|tc|ba)sh} )
-  fi
-
   args=(
     '(-D)-c+[comment]:comment'
     "(-D)-${home}+[home directory]:home directory:_directories -W /"
@@ -19,7 +13,7 @@
     '(-D)-f+[specify inactive days]:inactive days'
     '(-D)-g+[initial group]:initial group:_groups'
     '(-D)-G+[supplementary groups]:supplementary group:_groups -S,'
-    "(-D)-s+[shell]:shell:( $shells /bin/false )"
+    "(-D)-s+[shell]:shell:_shells"
     '(-D -M)-m[create home directory]'
     '(-D)-u[uid]:uid'
     '(-D)-o[allow non unique uid]'
Index: Completion/Unix/Type/_shells
===================================================================
RCS file: Completion/Unix/Type/_shells
diff -N Completion/Unix/Type/_shells
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ Completion/Unix/Type/_shells	22 Jun 2005 12:36:08 -0000
@@ -0,0 +1,11 @@
+#compdef -value-,SHELL,-default-
+
+local expl shells
+
+if [[ -r /etc/shells ]]; then
+  shells=( ${${(f)"$(</etc/shells)"}:#\#*} )
+else
+  shells=( ${(M)commands:#*/((|[abckz]|tc|ba)sh|false)} )
+fi
+
+_wanted shells expl shell compadd -a "$@" - shells

Re: PATCH: new shells completion type

[Oliver Kiddle]

Doug Kearns wrote:
> Here is a new completion type for shells. It seems to me that if we're
> going to complete shells from /etc/shells then it should be restricted
> _only_ to shells listed there. This will change the behaviour of useradd
> completion which always included /bin/false.

With useradd/usermod, it's very useful to have /bin/false as a match. If
the user account won't need to login then that's a common way to ensure
it can't.

> -  '-s[shell to execute rather than $SHELL]:shell name: _command_names -e' \
> +  '-s[shell to execute rather than $SHELL]:shell:_shells' \

I don't use screen but does that option only get used with actual
shells?

> +  shells=( ${(M)commands:#*/((|[abckz]|tc|ba)sh|false)} )

That branch is still adding /bin/false. If screen's -s option is
commonly used, you may want to expand this a bit.

Oliver


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Re: PATCH: new shells completion type

[Stephane Chazelas]

On Wed, Jun 22, 2005 at 11:11:58PM +1000, Doug Kearns wrote:
> Here is a new completion type for shells. It seems to me that if we're
> going to complete shells from /etc/shells then it should be restricted
> _only_ to shells listed there. This will change the behaviour of useradd
> completion which always included /bin/false.
> 
> Any objections?

Hi.

One sometimes wants to set a command that is not in /etc/shells
as the login shell on purpose (like /bin/false) to disable FTP
access. That could be "nologin", a script, whatever...


> diff -u -r1.10 _screen
> --- Completion/Unix/Command/_screen	11 Jun 2005 12:28:17 -0000	1.10
> +++ Completion/Unix/Command/_screen	22 Jun 2005 12:36:08 -0000
> @@ -76,7 +76,7 @@
>    '-q[quiet startup, exit with non-zero return code if unsuccessful]' \
>    '-r[reattach to a detached screen process]: :->detached-sessions' \
>    '-R[reattach if possible, otherwise start a new session]: :->detached-sessions' \
> -  '-s[shell to execute rather than $SHELL]:shell name: _command_names -e' \
> +  '-s[shell to execute rather than $SHELL]:shell:_shells' \

As far as screen is concerned, that doesn't need to be a shell,
one might prefer to use "mc" or "elinks" or "emacs" for instance.

[...]
> +else
> +  shells=( ${(M)commands:#*/((|[abckz]|tc|ba)sh|false)} )
> +fi

What about dash (debian ash), rc, es...

regards,
Stephane

Re: PATCH: new shells completion type

[Peter Stephenson]

Sounds like there should be a style shell-commands which gets added
to the list of shells in the current context.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: PATCH: new shells completion type

[Oliver Kiddle]

Peter wrote:
> Sounds like there should be a style shell-commands which gets added
> to the list of shells in the current context.

There's a perfectly good fake style for adding matches to a particular
context. The following would work for me but it seemed a useful thing to
do out of the box:
  zstyle ':completion:*:user(mod|add):option-s-1:*' fake /bin/false

Where we have styles like hosts and users, they replace matches instead
of adding to them.

Oliver



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Re: PATCH: new shells completion type

[Doug Kearns]

On Wed, Jun 22, 2005 at 03:59:20PM +0200, Oliver Kiddle wrote:
> Doug Kearns wrote:
> > Here is a new completion type for shells. It seems to me that if we're
> > going to complete shells from /etc/shells then it should be restricted
> > _only_ to shells listed there. This will change the behaviour of useradd
> > completion which always included /bin/false.
> 
> With useradd/usermod, it's very useful to have /bin/false as a match. If
> the user account won't need to login then that's a common way to ensure
> it can't.

Right, but it was my understanding that these commands were supposed to
check /etc/shells, if it existed, and fail if the shell arg isn't listed
there. Also, that /bin/false was generally added to this file if it was
required. However, a quick check on my system suggests that although
chsh does behave as described above useradd/usermod do not...
 
> > -  '-s[shell to execute rather than $SHELL]:shell name: _command_names -e' \
> > +  '-s[shell to execute rather than $SHELL]:shell:_shells' \
> 
> I don't use screen but does that option only get used with actual
> shells?

I think you're right the definition of 'shell' may well be less strict
than that - I'll have a look.
 
<snip>

Regards,
Doug

Re: PATCH: new shells completion type

[Doug Kearns]

On Wed, Jun 22, 2005 at 03:07:21PM +0100, Stephane Chazelas wrote:
> On Wed, Jun 22, 2005 at 11:11:58PM +1000, Doug Kearns wrote:

<snip>
 
> One sometimes wants to set a command that is not in /etc/shells
> as the login shell on purpose (like /bin/false) to disable FTP
> access. That could be "nologin", a script, whatever...

OK, thanks. It looks like the useradd man page makes no mention of
/etc/shells. Is it mostly, or was it originally, just for chsh? Which
commands actually make use of /etc/shells?

<snip>
 
> As far as screen is concerned, that doesn't need to be a shell,
> one might prefer to use "mc" or "elinks" or "emacs" for instance.
 
Yes, I'll leave that as is...

> > +else
> > +  shells=( ${(M)commands:#*/((|[abckz]|tc|ba)sh|false)} )
> > +fi
> 
> What about dash (debian ash), rc, es...

The Debian system I have access to adds:

/usr/bin/es
/usr/bin/rc
/bin/sash
/usr/bin/esh
/bin/dash

and, possibly overkill, but sendmail/conf.c lists:

static char     *DefaultUserShells[] =
{
        "/bin/sh",              /* standard shell */
# ifdef MPE
        "/SYS/PUB/CI",
# else /* MPE */
        "/usr/bin/sh",
        "/bin/csh",             /* C shell */
        "/usr/bin/csh",
# endif /* MPE */
# ifdef __hpux
#  ifdef V4FS
        "/usr/bin/rsh",         /* restricted Bourne shell */
        "/usr/bin/ksh",         /* Korn shell */
        "/usr/bin/rksh",        /* restricted Korn shell */
        "/usr/bin/pam",
        "/usr/bin/keysh",       /* key shell (extended Korn shell) */
        "/usr/bin/posix/sh",
#  else /* V4FS */
        "/bin/rsh",             /* restricted Bourne shell */
        "/bin/ksh",             /* Korn shell */
        "/bin/rksh",            /* restricted Korn shell */
        "/bin/pam",
        "/usr/bin/keysh",       /* key shell (extended Korn shell) */
        "/bin/posix/sh",
        "/sbin/sh",
#  endif /* V4FS */
# endif /* __hpux */
# if defined(_AIX3) || defined(_AIX4)
        "/bin/ksh",             /* Korn shell */
        "/usr/bin/ksh",
        "/bin/tsh",             /* trusted shell */
        "/usr/bin/tsh",
        "/bin/bsh",             /* Bourne shell */
        "/usr/bin/bsh",
# endif /* defined(_AIX3) || defined(_AIX4) */
# if defined(__svr4__) || defined(__svr5__)
        "/bin/ksh",             /* Korn shell */
        "/usr/bin/ksh",
# endif /* defined(__svr4__) || defined(__svr5__) */
# ifdef sgi
        "/sbin/sh",             /* SGI's shells really live in /sbin */
        "/usr/bin/sh",
        "/sbin/bsh",            /* classic Bourne shell */
        "/bin/bsh",
        "/usr/bin/bsh",
        "/sbin/csh",            /* standard csh */
        "/bin/csh",
        "/usr/bin/csh",
        "/sbin/jsh",            /* classic Bourne shell w/ job control*/
        "/bin/jsh",
        "/usr/bin/jsh",
        "/bin/ksh",             /* Korn shell */
        "/sbin/ksh",
        "/usr/bin/ksh",
        "/sbin/tcsh",           /* Extended csh */
        "/bin/tcsh",
        "/usr/bin/tcsh",
# endif /* sgi */
        NULL
};


Any others?

Regards,
Doug