There was a thread about C7 bash completion back in August last year, but it doesn't have answers for this problem.
Example: "yum install /path/to/local/package" works fine with tab completion to fill in the path and package bits.
However, "yum --debuglevel="1" install ..." just gets stuck and doesn't offer anything. The only option is to type everything out, or type enough to use a wildcard. After more testing, I found that any option argument that is quoted breaks completion. Which in turn makes me think this is not even specific to yum but bash completion in general.
Bug? Upstream bug?
I am going to take a really wild guess and say "Try replacing the outermost quotes with single quotes or escape the double quotes around the numeral 1". Your second example has double quotes within double quotes and I'm wondering if that's getting rendered as "yum --debuglevel=" 1 " install ..." (extra space added for emphasis).
________________________________ From: CentOS centos-bounces@centos.org on behalf of isdtor isdtor@gmail.com Sent: Thursday, May 23, 2019 9:47:20 AM To: CentOS mailing list Subject: [EXTERNAL] [CentOS] Bash completion thrown by quoted option args?
There was a thread about C7 bash completion back in August last year, but it doesn't have answers for this problem.
Example: "yum install /path/to/local/package" works fine with tab completion to fill in the path and package bits.
However, "yum --debuglevel="1" install ..." just gets stuck and doesn't offer anything. The only option is to type everything out, or type enough to use a wildcard. After more testing, I found that any option argument that is quoted breaks completion. Which in turn makes me think this is not even specific to yum but bash completion in general.
Bug? Upstream bug?
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Harriscomputer
Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com
[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.comhttp://www..com
This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed herehttp://subscribe.harriscomputer.com/.
If you prefer not to be contacted by Harris Operating Group please notify ushttp://subscribe.harriscomputer.com/.
This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
Leroy Tennison writes:
I am going to take a really wild guess and say "Try replacing the outermost quotes with single quotes or escape the double quotes around the numeral 1". Your second example has double quotes within double quotes and I'm wondering if that's getting rendered as "yum --debuglevel=" 1 " install ..." (extra space added for emphasis).
The outermost quotes are not part of the command, they were only a means to set off the command typed from the surrounding text.
Single quotes around the option arg don't work either.
Hello isdtor,
On Fri, 24 May 2019 09:33:55 +0100 isdtor isdtor@gmail.com wrote:
Leroy Tennison writes:
I am going to take a really wild guess and say "Try replacing the outermost quotes with single quotes or escape the double quotes around the numeral 1". Your second example has double quotes within double quotes and I'm wondering if that's getting rendered as "yum --debuglevel=" 1 " install ..." (extra space added for emphasis).
The outermost quotes are not part of the command, they were only a means to set off the command typed from the surrounding text.
Single quotes around the option arg don't work either.
In that specific example (--debuglevel="1"), you don't need the quotes. But, if that's just an example and you really use command-line arguments that need to be quoted, for instance because they contain spaces, maybe you could just use \ to protect spaces like: # command "a b" c would become: # command a\ b c (2 params) which is different from: # command a b c (3 params) just escaping the space to prevent bash from considering "a\ b" as two words).
Also, maybe it's bash completion for yum that is your problem, did you try disabling yum-specific completion? That would let you still the ability to use path completion.
Regards,
wwp writes:
Hello isdtor,
On Fri, 24 May 2019 09:33:55 +0100 isdtor isdtor@gmail.com wrote:
Leroy Tennison writes:
I am going to take a really wild guess and say "Try replacing the outermost quotes with single quotes or escape the double quotes around the numeral 1". Your second example has double quotes within double quotes and I'm wondering if that's getting rendered as "yum --debuglevel=" 1 " install ..." (extra space added for emphasis).
The outermost quotes are not part of the command, they were only a means to set off the command typed from the surrounding text.
Single quotes around the option arg don't work either.
In that specific example (--debuglevel="1"), you don't need the quotes. But, if that's just an example and you really use command-line arguments that need to be quoted, for instance because they contain spaces, maybe you could just use \ to protect spaces like: # command "a b" c would become: # command a\ b c (2 params) which is different from: # command a b c (3 params) just escaping the space to prevent bash from considering "a\ b" as two words).
Also, maybe it's bash completion for yum that is your problem, did you try disabling yum-specific completion? That would let you still the ability to use path completion.
In my case, the argument being quoted (different option) is a "*". Your method of escaping instead of quoting works.
I couldn't find anything yum-specific in bash-completion.
[root@localhost ~]# rpm -ql bash-completion |grep yum [root@localhost ~]#
isdtor wrote:
wwp writes:
On Fri, 24 May 2019 09:33:55 +0100 isdtor isdtor@gmail.com wrote:
Leroy Tennison writes:
I am going to take a really wild guess and say "Try replacing the outermost quotes with single quotes or escape the double quotes around the numeral 1". Your second example has double quotes within double quotes and I'm wondering if that's getting rendered as "yum --debuglevel=" 1 " install ..." (extra space added for emphasis).
The outermost quotes are not part of the command, they were only a means to set off the command typed from the surrounding text.
Single quotes around the option arg don't work either.
In that specific example (--debuglevel="1"), you don't need the quotes. But, if that's just an example and you really use command-line arguments that need to be quoted, for instance because they contain spaces, maybe you could just use \ to protect spaces like: # command "a b" c would become: # command a\ b c (2 params) which is different from: # command a b c (3 params) just escaping the space to prevent bash from considering "a\ b" as two words).
Also, maybe it's bash completion for yum that is your problem, did you try disabling yum-specific completion? That would let you still the ability to use path completion.
In my case, the argument being quoted (different option) is a "*". Your method of escaping instead of quoting works.
I couldn't find anything yum-specific in bash-completion.
[root@localhost ~]# rpm -ql bash-completion |grep yum [root@localhost ~]#
I really haven't been following this thread, but if it's about yum, it's always been perfectly happy with $ yum update package* with no quotes at all.
mark
Hello isdtor,
On Fri, 24 May 2019 14:33:29 +0100 isdtor isdtor@gmail.com wrote:
wwp writes:
Hello isdtor,
On Fri, 24 May 2019 09:33:55 +0100 isdtor isdtor@gmail.com wrote:
Leroy Tennison writes:
I am going to take a really wild guess and say "Try replacing the outermost quotes with single quotes or escape the double quotes around the numeral 1". Your second example has double quotes within double quotes and I'm wondering if that's getting rendered as "yum --debuglevel=" 1 " install ..." (extra space added for emphasis).
The outermost quotes are not part of the command, they were only a means to set off the command typed from the surrounding text.
Single quotes around the option arg don't work either.
In that specific example (--debuglevel="1"), you don't need the quotes. But, if that's just an example and you really use command-line arguments that need to be quoted, for instance because they contain spaces, maybe you could just use \ to protect spaces like: # command "a b" c would become: # command a\ b c (2 params) which is different from: # command a b c (3 params) just escaping the space to prevent bash from considering "a\ b" as two words).
Also, maybe it's bash completion for yum that is your problem, did you try disabling yum-specific completion? That would let you still the ability to use path completion.
In my case, the argument being quoted (different option) is a "*". Your method of escaping instead of quoting works.
Glad that it works! Escaping is often an alternate method to quoting, makes things less readable but saves you in some conditions.
I couldn't find anything yum-specific in bash-completion.
[root@localhost ~]# rpm -ql bash-completion |grep yum [root@localhost ~]#
Bash allows modular completion, this is why is may suggest command-line arguments (switches) to `yum` or other commands, see: # yum up<TAB> update upgrade It proposes update and upgrades, because bash completion has been told how yum works.
Unfortunately I don't have any pointers that would document all this properly, but to say that it's all in /etc/bash_completion.d and: # rpm -qf /etc/bash_completion.d/yum-utils.bash yum-utils-1.1.31-50.el7.noarch and # rpm -qa|grep bash-completion bash-completion-extras-2.1-11.el7.noarch bash-completion-2.1-6.el7.noarch
Here I disabled app-specific completion in my ~/.bash_profile 'cause it might slow down user interaction and sometimes simply cause issues. To get the expanding of paths only (as in bash 2 at least, IIRC): # complete -D -o default See `man bash` and look for the `complete` command to know more.
Regards,
On May 24, 2019, at 09:33, isdtor isdtor@gmail.com wrote:
[root@localhost ~]# rpm -ql bash-completion |grep yum [root@localhost ~]#
The yum bash completion configuration is in the ‘yum’ package.
-- Jonathan Billings
Hello Jonathan,
On Fri, 24 May 2019 10:28:54 -0400 Jonathan Billings billings@negate.org wrote:
On May 24, 2019, at 09:33, isdtor isdtor@gmail.com wrote:
[root@localhost ~]# rpm -ql bash-completion |grep yum [root@localhost ~]#
The yum bash completion configuration is in the ‘yum’ package.
It's yum-utils, isn't it?
Regards,
On May 24, 2019, at 10:48, wwp subscript@free.fr wrote:
On Fri, 24 May 2019 10:28:54 -0400 Jonathan Billings billings@negate.org wrote:
On May 24, 2019, at 09:33, isdtor isdtor@gmail.com wrote:
[root@localhost ~]# rpm -ql bash-completion |grep yum [root@localhost ~]#
The yum bash completion configuration is in the ‘yum’ package.
It's yum-utils, isn't it?
The ‘yum-utils’ package does have completions for the tools it packages, such as repoquery, but the ‘yum’ package itself has its completion configuration. At least on CentOS 7. Oddly enough, yum-utils puts files in /etc/bash_completion.d rather than in /usr/share/bash-completion/completions/. Overrides?
— Jonathan Billings billings@negate.org
-
isdtor -
Jonathan Billings -
Leroy Tennison -
mark -
wwp