Re: Reintroducing fish, the friendly interactive shell
- From: "liljencrantz@xxxxxxxxx" <liljencrantz@xxxxxxxxx>
- Date: 9 Mar 2006 02:04:09 -0800
Kurt Swanson skrev:
"liljencrantz@xxxxxxxxx" <liljencrantz@xxxxxxxxx> writes:
Kurt Swanson skrev:
Stephane Chazelas <stephane_chazelas@xxxxxxxx> writes:
On 8 Mar 2006 07:52:17 -0800, liljencrantz@xxxxxxxxx wrote:
[...]
4.2.1 was released on 2004-08-13, the latest production release
is 4.2.6, the latest development release is 4.3.2.
zsh su support doesn't include switch completion, only username
completion. 'su -<TAB>' gives you nothing.
su generally doesn't take options. It's a non-standard utility,
and I know of at least 3 different implementations only for
Linux. Some might take options, some not, zsh approach is as
good as any. I guess it could try and parse the man page but
that may be a bit overkill (and slow).
Maybe a better approach would be for commands to declare their options
in a proper format, something like zsh's _gnu_generic, which would
allow commands to declare not only options, but arguments to the
options as well as parameters to the command. Of course getting all
the writers of all the commands to implement this would be infeasible.
It would be great. And something that _all_ shells could use. I've been
thinking about contacting the glibc developers and proposing an
extended getopt_long function, getopt_long_completable or something
like that, which wouls support defining completions in the program.
Don't know what their feelings toward this would be, but it would be a
nice first step towards better tab completions all around.
I would certainly support it. The really nice thing would be the
dynamic nature of it all--shells would merely need to parse/complete
on this output without respect to the platform, state, etc. I.e. no
"if linux do this else if..."
A proper declaration of one's options and arguments would be akin to a
finite state machine. This would still never cover all the quirkiness
of some commands' parameter-options, but would go a long way...
here's what I had in mind. Add two fields to the getopt_long option
struct, namely 'description' containing a description of the
completion, and completion_flags, which is a union of the different
types of completions that the argument should support, e.g. filename
completion, netwrok interface completion, etc. Also, option entrys with
a completion name of 0 is allowed in two cases:
* To specify completions for arguments that are not arguments to a
specific switch, in which case val and flag must also be 0.
* To specify completions for short switches that have no equvalent long
switches, in which case flag must be 0 and val must be the name of the
short switch.
#define COMPLETE_FILE 1
#define COMPLETE_USER 2
#define COMPLETE_DIRECTORY 4
#define COMPLETE_HOST 8
#define COMPLETE_PACKAGE 16
#define COMPLETE_NETWORK_INTERFACE 32
#define COMPLETE_COMMAND 64
struct option_comp
{
const char *name;
int has_arg;
int *flag;
int val;
const char *description;
int complete_flag;
};
extern int getopt_long_comp (int argc, char *const *argv, const char
*shortopts,
const struct option_comp *longopts, int *longind);
An example of this interface in use, parsing the arguments for su:
static const option_comp *long_opt =
{
{"login", no_argument, 0, 'l', "Make the shell a login shell", 0},
{"command", required_argument, 0, 'c', "Command to execute",
COMPLETE_COMMAND},
{"fast", no_argument, 0, 'f', "Pass f to the shell", 0},
{"preserve-environment", no_argument, 0, 'm', "Do not reset
environment variables", 0},
{0, no_argument, 0, 'p', "Do not reset environment variables", 0},
{"shell", required_argument, 0, 's', "Run specified shell if
/etc/shells allows it", COMPLETE_COMMAND},
{"help", no_argument, 0, '', "Display help and exit", 0},
{"version", no_argument, 0, '', "Display verion and exit", 0}
{0, required_argument, 0, 0, "Specify new user", COMPLETE_USER},
};
while(1)
{
int opt_intex=0;
int opt = getopt_long_comp( argc, argv, "lc:fmps:", long_opt,
&opt_index );
switch( opt )
{
case 'l':
....
}
}
In order to get this information out, one would simply use 'su
--print-completions', in which case the above could get printed to
stdout in a format that is easy to parse for both humans and machines,
perhaps as a tab separated list.
--
© 2006 Kurt Swanson AB
--
Axel
.
- References:
- Reintroducing fish, the friendly interactive shell
- From: liljencrantz@xxxxxxxxx
- Re: Reintroducing fish, the friendly interactive shell
- From: bsh
- Re: Reintroducing fish, the friendly interactive shell
- From: Stephane CHAZELAS
- Re: Reintroducing fish, the friendly interactive shell
- From: bsh
- Re: Reintroducing fish, the friendly interactive shell
- From: liljencrantz@xxxxxxxxx
- Re: Reintroducing fish, the friendly interactive shell
- From: Jordan Abel
- Re: Reintroducing fish, the friendly interactive shell
- From: liljencrantz@xxxxxxxxx
- Re: Reintroducing fish, the friendly interactive shell
- From: Stephane Chazelas
- Re: Reintroducing fish, the friendly interactive shell
- From: liljencrantz@xxxxxxxxx
- Re: Reintroducing fish, the friendly interactive shell
- From: Stephane Chazelas
- Re: Reintroducing fish, the friendly interactive shell
- From: liljencrantz@xxxxxxxxx
- Re: Reintroducing fish, the friendly interactive shell
- From: Stephane Chazelas
- Re: Reintroducing fish, the friendly interactive shell
- From: liljencrantz@xxxxxxxxx
- Reintroducing fish, the friendly interactive shell
- Prev by Date: fixed-size records
- Next by Date: Re: fixed-size records
- Previous by thread: Re: Reintroducing fish, the friendly interactive shell
- Next by thread: Re: Reintroducing fish, the friendly interactive shell
- Index(es):
Relevant Pages
|