similar to: Bash completion file(s) for samba utils...

This implements most of RHBZ#1367738. I didn't bother with virt-v2v-copy-to-local and virt-win-reg, but all the other tools now have full bash completion. Rich.

Just like --long-options, it makes it possible to know which short options are supported by each tool; this can help improving the bash completion, for example. --- align/scan.c | 3 +++ builder/cmdline.ml | 1 + cat/cat.c | 3 +++ cat/filesystems.c | 3 +++ cat/log.c | 3 +++ cat/ls.c | 3 +++

Add new scripts for: - guestunmount - virt-copy-in - virt-copy-out - virt-customize - virt-dib - virt-diff - virt-get-kernel - virt-p2v-make-disk - virt-p2v-make-kickstart - virt-p2v-make-kiwi - virt-tar-in - virt-tar-out Also combine the separate virt-resize script into the general script virt-alignment-scan. There wasn't really any reason to have separate scripts. --- .gitignore

Thanks: Ming Xie --- bash/Makefile.am | 3 ++- bash/virt-v2v-copy-to-local | 42 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+), 1 deletion(-) create mode 100644 bash/virt-v2v-copy-to-local diff --git a/bash/Makefile.am b/bash/Makefile.am index 94a2d48..86fd816 100644 --- a/bash/Makefile.am +++ b/bash/Makefile.am @@ -22,7 +22,8 @@ scripts = \

This only implements long and short options. Thanks: Ming Xie. --- .gitignore | 1 + bash/Makefile.am | 19 +++++++++++++------ bash/virt-v2v-copy-to-local | 21 ++++++++++++++++----- tools/virt-win-reg | 22 ++++++++++++++++++++-- 4 files changed, 50 insertions(+), 13 deletions(-) diff --git a/.gitignore b/.gitignore index c82745e..5c7cd53 100644 ---

The contents are the wip.testme branch currently on salsa. I combined the wip.initscript and wip.oxenstored into this and added more things today. I think this is pretty gtg and it's smoke tested (in several cases by scping files around instead of doing package build), so it needs a final extra review and test round before putting it in master branch (which I don't want to force push). I

Copy over the bash completion machinery from libguestfs, along with the simple completion script; use this script for all the tools. --- .gitignore | 2 + Makefile.am | 3 ++ bash/Makefile.am | 68 +++++++++++++++++++++++++++++++++ bash/README | 6 +++ bash/test-complete-in-script.sh | 40 +++++++++++++++++++

https://bugzilla.netfilter.org/show_bug.cgi?id=1443 Bug ID: 1443 Summary: ipset -bash: syntax error near unexpected token `;;' Product: ipset Version: unspecified Hardware: x86_64 OS: other Status: NEW Severity: minor Priority: P5 Component: default Assignee:

On Thursday, 25 August 2016 13:15:29 CEST Richard W.M. Jones wrote: > Add new scripts for: > > - guestunmount > - virt-copy-in > - virt-copy-out > - virt-customize > - virt-dib > - virt-diff > - virt-get-kernel > - virt-p2v-make-disk > - virt-p2v-make-kickstart > - virt-p2v-make-kiwi > - virt-tar-in > - virt-tar-out > > Also combine the separate

On Wednesday, 22 March 2017 11:30:59 CET Richard W.M. Jones wrote: > Thanks: Ming Xie > --- It does not wrong to me, although couldn't an existing completion be used for virt-v2v-copy-to-local as well? Thanks, -- Pino Toscano

On Wed, Mar 22, 2017 at 11:39:58AM +0100, Pino Toscano wrote: > On Wednesday, 22 March 2017 11:30:59 CET Richard W.M. Jones wrote: > > Thanks: Ming Xie > > --- > > It does not wrong to me, although couldn't an existing completion be > used for virt-v2v-copy-to-local as well? We might have used the 'virt-alignment-scan' one (used by all the other virt-* tools

Hi, In tools/libxl/bash-completion, there's a file that would nicely be put in /etc/bash_completion.d/xl. I'd work on a patch, but the issue is that the xl command is in xen-common, but the source file isn't there. I don't get what's the logic with the xen-common, and I'm unsure how to patch. Why isn't xen-common taken directly from the xen source package? It seems to

On Friday 24 October 2014 09:14:29 Richard W.M. Jones wrote: > Previously we copied the files instead of the symlinks. This series LGTM. On the other hand, given that the symlinks in the builddir are not used at all, why not just create them only at install time? -- Pino Toscano

On 12/7/18 4:23 PM, Richard W.M. Jones wrote: > I don't really know enough on this topic to comment on the patch, > except for a general comment that this sounds like it could be a bug > in either pkg-config or bash-completion. What a shame that neither pkg-config nor bash-completion seem to have a mailing list for bug reports (both projects document that you have to submit github

Hi! I have the following packages installed: freenx-0.4.4-1.centos4.noarch from extras bash-completion-20050721-1.2.el4.rf.noarch from dries/dag bash-3.0-19.2.i386 from base seems to result in a non-working nxserver (the window manager doesn't start up, although X applications can be launched via logging in through a seperate ssh and setting the DISPLAY variable accordingly)... As far as

I just got off a Windows 7 terminal which has rotating tab completion, this means that in the case of completion ambiguity the shell completes one of the possibilities, and subsequent tabs complete to different possibilities. This in contrast to bash's behaviour of simply printing a list of possibilities. Googling I have found that bash can in fact have rotating completion by setting

On 08/28/2018 11:33 PM, wwp wrote: > - it doesn't expand *foo whereas there are *foo-named files in current dir, for instance: > # rm *foo > will show nothing whereas there's a file barfoo in curdir. Tab completion finishes a single word, given a string that appears at the beginning of a list of candidates. Wildcard expansion (Ctrl+x, e) will expand a word containing

On Wed, 29 Aug 2018, wwp wrote: >while bash completion was working great to me in CentOS6, since I'm >using C7 I spend my day stuck on completion not working the way it >should. Since you don't want what it provides you can either remove the bash-completions* packages or append "complete -r" to your ~/.bashrc which turns off all custom completions leaving just

On 08/29/2018 09:22 AM, wwp wrote: > On Wed, 29 Aug 2018 08:27:06 -0700 Gordon Messmer <gordon.messmer at gmail.com> wrote: >> On 08/28/2018 11:33 PM, wwp wrote: >>> - it doesn't expand *foo whereas there are *foo-named files in current dir, for instance: >>> # rm *foo >>> will show nothing whereas there's a file barfoo in curdir.

On 08/30/2018 01:11 AM, wwp wrote: > I well know that to match "1.foo-named", I should use `ls*foo*<TAB>` > (trailing *) and I'm sure that you know that `ls *foo<TAB>` matches > 1.foo. I didn't.? Given a better description of what you're trying to do, I see that the bash's behavior has changed. I also learned about "Alt+g" and