programmable completion: completing filenames with default Readline behavior
I'm writing a completion where, in some cases, I'd like to use
COMPREPLY=() to indicate that no more arguments to a command are
expected, but in other cases, I'd like to offer the default Readline
behavior for filename completions.
So, if I have a directory 'foo', I'd like the shell to first complete
with 'foo/' and then offer to complete files under 'foo'. But if I do
something like COMPREPLY=($(compgen -f -- "$cur")), then I simply get
a completion of 'foo' (with a space appended).
I know I can pass "-o default" to get Readline's default filename
completion when COMPREPLY is empty, but then that seems to preclude
using COMPREPLY=() to deny completions.
I've tried a number of different workarounds, none of which I was
completely happy with (or I probably wouldn't be asking this
question). The closest I got was setting "-o default", and then using
COMPREPLY=("") to semi-deny completion, and COMPREPLY=() to get
filename completion.
Can anyone offer a better approach?
Thanks,
Jeremy
bash built-ins `true' and `false' undocumented
I guess there is not too much one can say about the bash built-ins `true' and `false'. Nonetheless, I suggest that the info pages should list these built-ins individually like other built-ins. Currently, the only hint on their existence is buried in the info node on Shell Builtin Commands saying that The `:', `true', `false', and `test' builtins do not accept options and do not treat `--' specially. Or am I missing something? (I don't know whether these commands should be listed in the info node on Bourne Shell Builtins or under Bash Builtins.) I am using GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu). Also, I have Edition 4.2, last updated 28 December 2010, of `The GNU Bash Reference Manual', for `Bash', Version 4.2. Roland
Re: bash built-ins `true' and `false' undocumented
On Fri, Sep 27, 2013 at 03:50:09PM +0530, Roland Winkler wrote: > I guess there is not too much one can say about the bash built-ins > `true' and `false'. Nonetheless, I suggest that the info pages > should list these built-ins individually like other built-ins. > Currently, the only hint on their existence is buried in the info > node on Shell Builtin Commands saying that > > The `:', `true', `false', and `test' builtins do not accept options and > do not treat `--' specially. $ help true true: true Return a successful result. Exit Status: Always succeeds. $ help false false: false Return an unsuccessful result. Exit Status: Always fails.
Re: bash built-ins `true' and `false' undocumented
On Fri Sep 27 2013 Greg Wooledge wrote: > $ help true > true: true > Return a successful result. > > Exit Status: > Always succeeds. > $ help false > false: false > Return an unsuccessful result. > > Exit Status: > Always fails. Thanks, I did not know that. Yet I think that the info pages are supposed to provide the definitive information about GNU software. So I still believe that it would be useful to list these builtins in the info pages, too. Certainly, the info pages are more useful for getting an overview. `help foo' only helps if you already have some idea of what you are looking for.
Re: bash built-ins `true' and `false' undocumented
On 2013-09-27 20:19, Roland Winkler wrote: > Yet I think that the info pages are supposed to provide the definitive > information about GNU software. So I still believe that it would be > useful to list these builtins in the info pages, too. Certainly, > the info pages are more useful for getting an overview. `help foo' > only helps if you already have some idea of what you are looking for. Well, they're directly part of the POSIX spec. I'm not sure there's a need to reiterate absolutely everything that is already required by POSIX. pgpa2LYJnRALH.pgp Description: PGP signature
