Improvement Of Bash To Support Dynamic Command Completion
Dear Sir, I (Soumyadip Das Mahapatra, India, Calcutta), being a frequent user of bash shell, have got it lacks an advanced feature dynamic command completion. As for example, latest ides ( e.g- Netbeans for Java) support dynamic auto-completion. We, the most frequent users, always like this kind of facility and now we want it to be in the bash shell. The auto-completion facility of current bash shell (use of TAB button) does not seem to be the most productive way. So, on behalf of the well wishers of bash shell, i request you to consider this kind of feature and kindly do some improvement of the most used unix shell ever. Thank you.
Re: Improvement Of Bash To Support Dynamic Command Completion
On Tuesday 08 April 2008, Soumyadip Das Mahapatra wrote: > I (Soumyadip Das Mahapatra, India, Calcutta), being a frequent user of bash > shell, have got it lacks an advanced feature dynamic command completion. As > for example, latest ides ( e.g- Netbeans for Java) support dynamic > auto-completion. We, the most frequent > users, always like this kind of facility and now we want it to be in the > bash shell. > The auto-completion facility of current bash shell (use of TAB button) does > not seem to be the most productive way. > So, on behalf of the well wishers of bash shell, i request you to consider > this kind of feature and kindly do some improvement of > the most used unix shell ever. this sort of stuff probably already exists with the bash-completion package. just google for "bash completion". -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] command-not-found-handle
On Sun, Apr 04, 2004 at 05:23:36PM +0200, Michael Vogt wrote:
> Dear Friends,
> I attached a small patch that adds a "command-not-found-handle" for
> bash 2.05b.0(1)-release. If a given command is not found and the
> function "command-not-found-handle" is definied, it is called with the
> faild comand as parameter. If it's not defined the behaviour is
> unchanged.
>
> Please tell me what you think about the patch and if there is a chance
> for it to get integrated into bash. See [1] for some rational why this
> might be usefull.
>
> thanks,
> Michael
>
> [1] http://www.geocrawler.com/mail/msg.php3?msg_id=2795796&list=342
This patch (or very similar) was accepted into debian's bash some time
ago, though apparently not upstream. I'm interested in extending this
patch to include the command arguments; currently only the command
string itself is passed to the "hook" function.
In the patch, shell variables f and v are declared, but v is not used;
my guess is that that may have been intended for the argument list, but
for some reason was dropped. I haven't yet figured out how to make this
work, but will keep trying...
The referenced link [1] to some rational hasn't aged well, and I'd be
interested in seeing any discussions of this feature.
My interest is to "extend" bash to support object oriented commands,
which I currently have to explicitly run through a handler; e.g., to use:
$ object.do_something args...
instead of:
$ tob object.do_something args...
where the tob script parses object and method, resolves the method to
some executable via path-like information associated with the object,
and then executes the equivalent of
$ $class_path/do_something object args...
I think this should be relatively safe, since there are probably few
executables which include a dot in their name.
Finally, I thought it should be possible to find the command line with
arguments under /proc/$pid, but no joy there either; if that was the
case, the command_not_found_handle function could perhaps reconstruct
the full command in order to pass to the tob handler. I'm running debian
stable and unstable systems, e.g.,
$ uname -a
Linux hayes 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux
Thanks for any thoughts, ridicule, etc., on this.
Ken
> --- execute_cmd.c.orig2004-04-04 15:40:18.0 +0200
> +++ execute_cmd.c 2004-04-04 16:41:33.0 +0200
> @@ -3270,8 +3270,23 @@
>
>if (command == 0)
> {
> - internal_error ("%s: command not found", pathname);
> - exit (EX_NOTFOUND); /* Posix.2 says the exit status is 127 */
> +SHELL_VAR *f, *v;
> +WORD_LIST *cmdlist;
> +WORD_DESC *w;
> +int fval;
> +f = find_function ("command-not-found-handle");
> +if (f == 0) {
> + internal_error ("%s: command not found", pathname);
> + exit (EX_NOTFOUND); /* Posix.2 says the exit status is 127
> */
> +}
> +w = make_word("command-not-found-handle");
> +cmdlist = make_word_list(w, (WORD_LIST*)NULL);
> +
> +w = make_word(pathname);
> +cmdlist->next = make_word_list(w, (WORD_LIST*)NULL);
> +
> +fval = execute_shell_function (f, cmdlist);
> +exit(fval);
> }
>
>/* Execve expects the command name to be in args[0]. So we
--
Ken Irving, [EMAIL PROTECTED], http://sourceforge.net/projects/thinobject/
Hi=~/lib/thinob/Try/Hi; mkdir -p $Hi; ln -s /usr/local/lib/thinob $Hi/^
hi=$(tob Try/Hi.tob hi); echo -e '#!/bin/sh\nshift\necho Hello $*!'>$hi
chmod +x $hi; mkdir say; ln -s $Hi say/^; tob say.hi world
read builtin function keeps trailing white space
*Configuration Information* [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 uname output: Linux bighorn 2.6.9-67.0.4.ELsmp #1 SMP Sun Feb 3 07:08:57 EST 2008 i686 i686 i386 GNU/Linux Machine Type: i686-redhat-linux-gnu Bash Version: 3.0 Patch Level: 15 Release Status: release * Description:* read builtin function keeps trailing white space when the default variable REPLY is used. This is specially bad when using the -e option because readline puts and extra space after pressing a the tab key to autocomplete a word. The IFS that delimits a word shouldn't be assigned to the variable. * Repeat-By:* Type the following: read type something with one trailing space echo "|$REPLY|" REPLY keeps the trailing white space Then try this other variant: read VAR type something with one trailing space echo "|$VAR|" VAR doesn't keep the trailing white space. This last behavior is the correct because "read" should parse everything by words (IFS are the delimiters and are not included). *Additional comments:* This behavior cases problems, for example, if you then try to check the existence of a file: if [ -e "$REPLY" ]; then fails because of the trailing white space. The quotes are necessary to check for null. *Fix:* None Thank you very much.
Re: read builtin function keeps trailing white space
Eduardo Sanz Garcia wrote: > Description:* >read builtin function keeps trailing white space when the default > variable REPLY is used. >This is specially bad when using the -e option because readline puts > and extra space after pressing a the tab key to autocomplete a word. >The IFS that delimits a word shouldn't be assigned to the variable. > * > Repeat-By:* >Type the following: >read >type something with one trailing space >echo "|$REPLY|" >REPLY keeps the trailing white space > >Then try this other variant: >read VAR >type something with one trailing space >echo "|$VAR|" >VAR doesn't keep the trailing white space. >This last behavior is the correct because "read" should parse > everything by words (IFS are the delimiters and are not included). This behaviour is IMHO intended and documented. Using one or more variable name(s) makes read assigning "every word" to the variable(s); using no variable name (fallback to REPLY) makes it assigning "the line" (!) to REPLY. It's a bit hidden in documentation, you need to see the difference between "words" and "line" in manpage. J.
