Created attachment 1452239 [details] My inputrc file Description of problem: Note, that this might not be a problem specific to coreutils ..but I wasn't sure which component to file this against precisely. I recently upgraded from Fedora 27 to 28 and noticed that on hitting tab for completion on the command prompt, in UI terminals (including terminator, xterm and gnome-termninal), the uncompleted text was being displayed in *blinking* red background color -- this was quite distracting and moreover different than the previous default. Note the additional important information: a. I have the setting "set skip-completed-text on" in my ~/.inputrc b. This seems to be the problem only for completion of bash functions and their argument, not for filename, dir completion. I know, I can go around poking thru' DIR_COLORS and find what's changed and reset this back to being less annoying, but a. it would be great to know whether this is a intentional change for a specific reason or just because this color scheme was just the maintainer's preference. b. would like to preferably save others from being surprised by this change. So filing this bug as a attempt to right this hideous wrong. Version-Release number of selected component (if applicable): coreutils-8.29-7.fc28.x86_64 How reproducible: Every time, in UI terminals (checked on terminator, gnome-terminal, xterm), afaict. Does not happen on the console. Steps to Reproduce: 1. Install and enable bash-completion 1.5 Add "set skip-completed-text on" to ~/.inputrc 2. In bash, excuete rpm -q core<tab><tab> 3. At the bash prompt, execute the following: $ function reproduce_the_blinkyblinky { > : > } $ function reproduce_the_blinkyblinky_again { > : > } $ reproduce_<tab><tab> Actual results: The suggested completion text is shown in blinking red background Expected results: The suggested completion text should not be shown in blinking red background Additional info:
OK, a couple of corrections/observations: a. The foreground text is blinking not the background b. Appears to happen for everything that is /not/ a filename completion -- for instance 'dnf<tab><tab> ' & 'y' confirmation This is quite ugly. *Please* don't do this to your users by default.
This bug (for me) appears to be related to this feature: https://bugzilla.gnome.org/show_bug.cgi?id=579964 And although gnome-terminal does offer a preference option to turn off the blinking in the terminal, other vte based terminals don't. I'm still filing this against vte tho, because it seems like the command setterm --blink off is not being recognized and I am assuming compliance to this would be vte responsibility ?
Note: vte is the old, dead, no longer maintained upstream, gtk2 based thing. The only terminals still using it are lilyterm, lxterminal and termit (as far as I can tell). Most likey you want vte291, which is the new, still maintained thing that gnome-terminal and tons of others use. Can you list what "other vte based terminals" you are using?
You filed it upstream against VTE at https://gitlab.gnome.org/GNOME/vte/issues/10. As per my response over there, this is not VTE's (package: vte291) problem. The blinking feature is newly available there, but uses the very same escape sequence that other terminal emulators have supported for ages. Also, "setterm --blink on/off" is supported as expected, but you misunderstand how it should behave. Whoever unintentionally emits blinking text (presumably bash-completion) should be fixed not to do so.
(See also https://bugs.launchpad.net/ubuntu/+source/byobu/+bug/1752352.)
Closing this since it isn't really a bug. Just a regression in terminal text appearance between different Fedora versions. I found a workaround (I've put in a hack in the terminator source to set the vte blinking text option to 'Never').
Please don't close, please reopen and reassign (or let developers reassign) to the appropriate component. This _is_ a bug. There's no sane reason that text should be blinking, and it's obviously freaking annoying. It's just not a bug in VTE or Terminator. It's a bug in the component which (presumably accidentally; or if not then by terrible design) emits the blinking text here. (Blinking text should be used to denote some truly alarming information, which TAB completion results are obviously not.)
/etc/DIR_COLORS and /etc/DIR_COLORS.256color (package: coreutils-common) both contain a line: MISSING 01;05;37;41 # ... and the files they point to This is pretty suspicious. It says bold and/or bright (01), blinking (05), white foreground (37) and red background (41), exactly as seen in the screenshot you posted in the VTE bug. Could you please verify whether modifying this line, rather than patching Terminator, also has the desired effect? (You probably need to start a new shell.) If so then we're on the right track and this entry is relevant. Also please try what happens if you create a file with such a name. E.g. create a file named "bisect" and then see whether "git" followed by a TAB completion shows the suggestion "bisect" in different, regular colors (I assume so). If my suspection is still correct then I guess the next question is why does bash treat bash-completion's suggestions as filenames; or how to tell bash that the suggestions aren't filenames in this case and why doesn't git's (and reproduce_the_blinkyblinky's) completion tell so. We'd need a bash + bash-completion guru to continue from here. (Also note that I'm not using Fedora or Red Hat, and I cannot reproduce the problem on my Ubuntu 18.04, so I won't be able to continue the investigation from this point. If my assumptions above are correct then I recommend to change the bug's component to bash or bash-completion, most likely one of these two (I don't know which one) is the culprit.) Thanks!
(In reply to Egmont Koblinger from comment #8) > /etc/DIR_COLORS and /etc/DIR_COLORS.256color (package: coreutils-common) > both contain a line: > > MISSING 01;05;37;41 # ... and the files they point to This is an entry for broken symlinks (symbolic links with non-existing targets), which are expected to be printed as blinking text when the color output of ls is enabled.
(In reply to Kamil Dudka from comment #9) > This is an entry for broken symlinks (symbolic links with non-existing > targets), which are expected to be printed as blinking text when the color > output of ls is enabled. I'd argue that broken (dangling) symlinks shouldn't blink. It's absolutely okay to have dangling symlinks. It doesn't mean anything's broken, it's not an alarming condition. In a similar manner, what IMO should be blinking is the "?" in the first column in the output of "ls -l", in place of the inode type, as that typically refers to a corrupted file system. But let's put this aside for now. One could open another bugreport for this. The main question here is: Why are the completions after a "git" treated as if they were files? On my Ubuntu they aren't, they aren't colored at all. A non-blinking, but bold white on red would still be pretty bad for these.
(In reply to Egmont Koblinger from comment #10) > I'd argue that broken (dangling) symlinks shouldn't blink. It's absolutely > okay to have dangling symlinks. It doesn't mean anything's broken, it's not > an alarming condition. It is a matter of taste IMO. Fell free to raise your argument at GNU coreutils upstream mailing list. I was just explaining what the DIR_COLORS entry is for.
(In reply to Kamil Dudka from comment #11) > Fell free to raise your argument at GNU coreutils upstream mailing list. It's a downstream Red Hat patch created by you that adds blinking :)
Indeed. I was confused by Gentoo Linux using a similar patch to make dangling symlinks in the output of ls blink by default. Sorry for the confusion. I think that Fedora devel list would be the appropriate channel to discuss it: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/