Xen 4.4 in jessie uses xl, not xm, however bash-completion only works
for xm.

This would've been great to have for the jessie release.

The lack of completion for xl makes using this command quite annoying.


Since most of the commands are the same as with xm, we could start with
cloning the completion file for xm and work out the differences from there.

 If they can actually share some common functions, you can put
both handlers in the same file, and symlink one to the other.

 Or use _xfunc() to call a function from the other file (which checks
if the function you want to call is already defined, else source and
then call.)

 Or maybe put something at the global level of completions/xl, so when
that file is loaded, it makes sure completions/xm is loaded, by
checking for something that xm defines.  Then the function definitions
that stick around in RAM after things are loaded are smaller and
simpler (no _xfunc, just direct calls).

 I don't use xen, so I have no plans to write completions for xen
commands myself, but patches usually get looked at eventually when
sent in to the bash-completion mailing list.  (It receives mail from
debian bugs on the bash-completion package.)

Hi!

This kind of annoyed me too for a long time. xen-utils-common provides a
rudimentary bash completion that completes all commands from it gets from
parsing 'xl help' but none of the more advanced completions of the xm
completion worked.
Find attached a version of xl completion that is mainly a copy of the xm
completion with the following changes:
* used the command expansion from /usr/share/bash-completion/completions/xl.sh
* adapted the create command to use the full path to the config file.

I'd very much apprechiate if that could be added to either bash-completion
or xen-utils-common...

best regards,
    Adi Kriegisch

reassign 768005 src:xen 4.11.1-1
thanks

Hi,

I was browsing the bash-completion package bug list before filing a bug
to remove the obsolete 'xm' file, and then I ran into this one.

Reassigning to Debian Xen team, since I that makes more sense. We
totally missed this on our (release) radar.

And indeed, we're shipping the upstream completion file now. Adi, I see
how you're improving it, and I like it.

So, we should probably ship this instead, but at the same time, the
right (tm) place to move this is upstream. We're activetly trying to get
rid of "adjusted copies of upstream stuff" in the packaging.

Would you mind making an upstream patch out of this? I can help with
that if needed. Then it gets proper review, and upstream can maintain it
when commands are added/changed etc.

Thanks,
Hans

Hi!
I'm happy you like it...
I think it would be great if you could ship that for Buster because I don't
think upstream will merge it within the next month... ;-)
Find the patch attached; it is based on upstream's repository[1]. Feel free
to submit it upstream (no need to credit me; this is just copied together
from xm and upstream's command list).

best regards,
    Adi

[1] https://xenbits.xen.org/git-http/xen.git

Hi,

Well, there's the "two sides of the coin"... There's getting credits for
doing work, but you'll also get blame because the work is never good enough.

It's nice that this improved completion script is adding things on top
of simple first-level commands, but when reviewing this, the first
command I looked at is xl create. My first question would be: did you
compare the actual current result to the xl man page?

For example, I see that xl create has options like -q, --quiet, -f=FILE,
--defconfig=FILE, -p, -F, -V, --vncviewer, -A, --vncviewer-autopass, -c,
and (whoa!!) even key=value "It is possible to pass key=value pairs on
the command line to provide options as if they were written in the
configuration file"... Ok, that last one is probably a bit too much to
ask completion to have an opinion about, but...

You get the picture. Your completion file just has options='-c'.

What do you think would be the best to do with this? Have a thorough
review and comparison and add all possible options and test them? Or,
take a step back and pretend it can do less, like the upstream one?

I can't just submit a patch upstream with myself as "credit" in this
state, because I know these are the questions that upstream developers
will be throwing at me immediately.

:)

Hans

Hi,

Initially, I thought that this file was already converted to xl, but
that seems not to be the case. I do not think it's a good idea to
include this, since it's simply doing an incorrect thing in many places,
e.g. suggesting phy: obsolete syntax, but also the options just don't
match xl.

So, this needs someone who actually uses bash completion a lot, and
wants to take ownership of this task, converting and testing everything
and taking it upstream first.

I'm not going to do that now, sorry.

Hans

Control: retitle -1 Please add bash-completion support for xl commands