I was looking at this for some other reason (I want to add an "interpreter-complete console" type command), and I noticed that "complete" and the complete_line function that it relies on don't work when the input text is a filename, and contains more that just the filename. You can see this easily, do: (gdb) file /usr/ X11R6 etc info local share bin games kerberos lost+found src dict i386-glibc21-linux lib man tmp doc include libexec sbin (gdb) complete file /usr/ (gdb) That isn't right, you should get: (gdb) complete file /usr/ file /usr/X11R6 file /usr/bin file /usr/dict file /usr/doc file /usr/etc file /usr/games file /usr/i386-glibc21-linux file /usr/include file /usr/info file /usr/kerberos file /usr/lib file /usr/libexec file /usr/local file /usr/lost+found file /usr/man file /usr/sbin file /usr/share file /usr/src file /usr/tmp The attached patch fixes the bug. The case works because readline advances the first argument of complete_line past the initial command. But "complete" always passes both TEXT and LINE_BUFFER as the whole command. This patch actually does what the comment about file completers above it says it intends, namely that we should go to the cursor, and then back up to the first file-wordbreak we find. The old code clearly didn't do that... Both the case and the complete case work now. This also makes emacs behave a little better when you try to complete files. I added a test case for this failure. ChangeLog 2003-09-24 Jim Ingham * completer.c (complete_line): For filename completions, when you look for the last word before the cursor, actually start from the cursor & work backwards, rather than starting from the word you were handed. Starting from the word doesn't work if the input contains more than one word - as it does in the complete command. testsuite/ChangeLog 2003-09-24 Jim Ingham * completion.exp: Test that "complete file ./gdb.base/compl" agrees with the result from sending a tab.