Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hostname completion fails terribly when IFS is set to some unusual value #723

Closed
3 tasks
calestyo opened this issue Apr 5, 2022 · 3 comments
Closed
3 tasks

Comments

@calestyo
Copy link
Contributor

calestyo commented Apr 5, 2022

Describe the bug

Not sure whether this is kinda expected respectively simply unsupported, but when IFS is set to e.g. x, then completing hostnames (and possibly other completions, too) fails terribly.

To reproduce

  1. IFS=x
  2. ssh <tab tab>
  3. Gives e.g.
$ ssh bash: set -o noglob: command not found
bash: set -o noglob: command not found
bash: set +o noglob: command not found
bash: set -o noglob: command not found
bash: set -o noglob: command not found
bash: set -o noglob: command not found

amundsen.example.org^Jamundsen ssh-ed25519 AAAAC3NzaC
...
...
...

Expected behavior

Catch unusual IFS at some top level for all bash-completions?

Versions (please complete the following information)

  • Operating system name/distribution and version: Debian sid
  • bash version, echo "$BASH_VERSION": 5.1.16(1)-release
  • bash-completion version, (IFS=.; echo "${BASH_COMPLETION_VERSINFO[*]}"): 2.11

Cheers,
Chris.

@calestyo
Copy link
Contributor Author

calestyo commented Apr 6, 2022

Any I think it also fails when set -e is in effect.

@scop
Copy link
Owner

scop commented Apr 9, 2022

IFS issues are generally ones we've wanted to fix. And we've already done a bunch, for example this particular case no longer fails that way in current master. (Not sure it produces useful/wanted results there either, though.)

set -e on the other hand I'm not entirely sure we want or "need" to support. No objections if we find a clean and sustainable way to do it, but having that setting in effect in interactive shells is quite rarely desirable in the first place.

The two mentioned issues are different, so in a sense they would be better off reported and handled separately. But on the other hand, if we can figure out a general way to set the shell in a desired state wrt various settings like these at start of a completion and reset them back to their previous state at end, in that way they are related. For example the return hook mechanism in #720 (comment) could lead towards a way to restore the state, and perhaps there was already some related work in another issue/PR, I forget.

@calestyo
Copy link
Contributor Author

calestyo commented Apr 9, 2022

Ah then it's probably just because of Debian's older bash-completion. Guess you can close that ticket then?

With set -e,... also not sure whether it's needed to support that or not (which is also why I didn't open a separate ticket)... just wanted to let you know :-D

@scop scop closed this as completed Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants