You are not logged in.
bash 5.3.3-2
bash-completion 2.16.0-1
I could've sworn I had been autocompleting fine, then just now, out of the blue:
$ sudo systemctl bash: [[: invalid regular expression `^(\$(\{[!#]?)?)([A-Za-z0-9_]*)$': Invalid range end
bash: [[: invalid regular expression `^(\$\{[#!]?)([A-Za-z0-9_]*)\[([^]]*)$': Invalid range end
bash: [[: invalid regular expression `^\$\{[#!]?[A-Za-z0-9_]*\[.*]$': Invalid range end
bash: [[: invalid regular expression `^([^\'"$`;&|<>()!]|\\.|'[^']*'|\$?"([^\"$`!]|\$([_a-zA-Z][_a-zA-Z0-9]*|[-*@#?$!0-9_])|\$\{[!#]?([_a-zA-Z][_a-zA-Z0-9]*(\[([0-9]+|[*@])\])?|[-*@#?$!0-9_])\}|\\.)*"|\$'([^\']|\\.)*'|\$([_a-zA-Z][_a-zA-Z0-9]*|[-*@#?$!0-9_])|\$\{[!#]?([_a-zA-Z][_a-zA-Z0-9]*(\[([0-9]+|[*@])\])?|[-*@#?$!0-9_])\})*$': Invalid range end$ set -x
+ (( 0 ))
+ _comp_compgen_variables
+ [[ / =~ ^(\$(\{[!#]?)?)([A-Za-z0-9_]*)$ ]]
bash: [[: invalid regular expression `^(\$(\{[!#]?)?)([A-Za-z0-9_]*)$': Invalid range end
+ [[ / =~ ^(\$\{[#!]?)([A-Za-z0-9_]*)\[([^]]*)$ ]]
bash: [[: invalid regular expression `^(\$\{[#!]?)([A-Za-z0-9_]*)\[([^]]*)$': Invalid range end
+ [[ / =~ ^\$\{[#!]?[A-Za-z0-9_]*\[.*]$ ]]
bash: [[: invalid regular expression `^\$\{[#!]?[A-Za-z0-9_]*\[.*]$': Invalid range end
+ return 1
+ [[ / == @(?(+([0-9])|{[a-zA-Z_]*([a-zA-Z_0-9])})@(>?([>|&])|<?([>&])|<<?([-<]))|&>?(>))* ]]Found "/usr/share/bash-completion/bash_completion:_comp_compgen_variables()"
I've (un/re)installed bash-completion to test it. No completion without the package. Error persists with it reinstalled.
Last edited by vindicator (2025-10-23 15:14:36)
Offline
To clarify your example, you try to autocomplete
sudo systemctl<TAB>and it then gives you the output shown? Does this happen with all autocompletions or only with that one in particular?
Can you share your shell configuration i.e. .profile and .bashrc ?
Have you tried with a clean profile?
env -i bash --norc --noprofile
. /usr/share/bash-completion/bash_completionEdit: The clean profile does not load the system config in /etc/bash.bashrc so you have to load it explicitly.
Last edited by lmn (2025-10-23 13:04:41)
Offline
I had just rebooted, and now instead of that error, bash straight crashes...
Process 6374 (bash) of user 0 dumped core.
Stack trace of thread 6374:
#0 0x00007fc37835074b kill (libc.so.6 + 0x3e74b)
#1 0x0000557bdbd31ca3 n/a (/usr/bin/bash + 0x86ca3)
#2 0x0000557bdbd357c8 termsig_handler (/usr/bin/bash + 0x8a7c8)
#3 0x0000557bdbd3591d termsig_sighandler (/usr/bin/bash + 0x8a91d)
#4 0x00007fc378350540 n/a (libc.so.6 + 0x3e540)
#5 0x00007fc378347e31 n/a (libc.so.6 + 0x35e31)
#6 0x00007fc378410303 n/a (libc.so.6 + 0xfe303)
#7 0x00007fc3784105ce n/a (libc.so.6 + 0xfe5ce)
#8 0x00007fc3784108c6 n/a (libc.so.6 + 0xfe8c6)
#9 0x00007fc37840f18e n/a (libc.so.6 + 0xfd18e)
#10 0x00007fc378410680 n/a (libc.so.6 + 0xfe680)
#11 0x00007fc3784108c6 n/a (libc.so.6 + 0xfe8c6)
#12 0x00007fc3784116ac n/a (libc.so.6 + 0xff6ac)
#13 0x00007fc378412e5a regcomp (libc.so.6 + 0x100e5a)
#14 0x0000557bdbd8eb34 sh_regmatch (/usr/bin/bash + 0xe3b34)
#15 0x0000557bdbce77e5 n/a (/usr/bin/bash + 0x3c7e5)
#16 0x0000557bdbcece11 execute_command_internal (/usr/bin/bash + 0x41e11)
#17 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#18 0x0000557bdbceb6dd execute_command_internal (/usr/bin/bash + 0x406dd)
#19 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#20 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#21 0x0000557bdbceae21 execute_command_internal (/usr/bin/bash + 0x3fe21)
#22 0x0000557bdbcfc493 n/a (/usr/bin/bash + 0x51493)
#23 0x0000557bdbcea0a4 n/a (/usr/bin/bash + 0x3f0a4)
#24 0x0000557bdbceb553 execute_command_internal (/usr/bin/bash + 0x40553)
#25 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#26 0x0000557bdbcead9c execute_command_internal (/usr/bin/bash + 0x3fd9c)
#27 0x0000557bdbcecf16 execute_command_internal (/usr/bin/bash + 0x41f16)
#28 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#29 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#30 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#31 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#32 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#33 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#34 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#35 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#36 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#37 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#38 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#39 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#40 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#41 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#42 0x0000557bdbceae21 execute_command_internal (/usr/bin/bash + 0x3fe21)
#43 0x0000557bdbcfc493 n/a (/usr/bin/bash + 0x51493)
#44 0x0000557bdbcea0a4 n/a (/usr/bin/bash + 0x3f0a4)
#45 0x0000557bdbceb553 execute_command_internal (/usr/bin/bash + 0x40553)
#46 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#47 0x0000557bdbcead9c execute_command_internal (/usr/bin/bash + 0x3fd9c)
#48 0x0000557bdbcecf16 execute_command_internal (/usr/bin/bash + 0x41f16)
#49 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#50 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#51 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#52 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#53 0x0000557bdbceda54 execute_command (/usr/bin/bash + 0x42a54)
#54 0x0000557bdbceceb7 execute_command_internal (/usr/bin/bash + 0x41eb7)
#55 0x0000557bdbceae21 execute_command_internal (/usr/bin/bash + 0x3fe21)
#56 0x0000557bdbcfc493 n/a (/usr/bin/bash + 0x51493)
#57 0x0000557bdbcfd30d execute_shell_function (/usr/bin/bash + 0x5230d)
#58 0x0000557bdbd58952 n/a (/usr/bin/bash + 0xad952)
#59 0x0000557bdbd5914c gen_compspec_completions (/usr/bin/bash + 0xae14c)
#60 0x0000557bdbd59bdc n/a (/usr/bin/bash + 0xaebdc)
#61 0x0000557bdbd59cfc programmable_completions (/usr/bin/bash + 0xaecfc)
#62 0x0000557bdbd4c4c0 n/a (/usr/bin/bash + 0xa14c0)
#63 0x00007fc37853d7ac n/a (libreadline.so.8 + 0x187ac)
ELF object binary architecture: AMD x86-64Even for the root user, for which I had not changed that profile/rc.
A clean profile DOES work (which makes it all the more odd for the root user).
sudo systemctl<TAB><TAB>worked for the root user, but not my regular user.
ls<TAB><TAB>failed for the root user. There is no profile/rc for root.
Note that I rebuilt my system over the past day due to an unrecoverable error (I may post about it sometime regarding luks integrity claiming a hardware issue (re-encrypted with integrity fine)), so this is all pretty fresh and bare.
Maybe it's the crashes hinting that it is the sdcard/hardware (will reinstall bash and reboot for good measure)...
EDIT0: Nope, even a reboot after reinstall made no difference.
Also, it's "sudo systemctl<TAB><TAB>" that crashes for the regular user. Without sudo, it works.
Last edited by vindicator (2025-10-23 13:53:25)
Offline
https://man.archlinux.org/man/kill.2.en - looks like the signal handler emits a signal - what's the actual signal causing the coredump?
Can you
[[ / =~ ^(\$(\{[!#]?)?)([A-Za-z0-9_]*)$ ]] && echo fooin an interactive shell?
A clean profile DOES work (which makes it all the more odd for the root user).
What does that mean?
New user or "env -i bash --norc --noprofile"?
In case of the latter test "env -i bash", "env -i bash --norc" and "env -i bash --noprofile" separately - the problem could easily be in /etc/profile or some existing environment set by your log shell.
Offline
Yeah, that "foo" line also caused the crash for both regular/root users:
Process 6903 (bash) of user 0 dumped core.
Stack trace of thread 6903:
#0 0x00007f0a8192174b kill (libc.so.6 + 0x3e74b)
#1 0x0000556f638ffca3 n/a (/usr/bin/bash + 0x86ca3)
#2 0x0000556f639037c8 termsig_handler (/usr/bin/bash + 0x8a7c8)
#3 0x0000556f6390391d termsig_sighandler (/usr/bin/bash + 0x8a91d)
#4 0x00007f0a81921540 n/a (libc.so.6 + 0x3e540)
#5 0x00007f0a81918e31 n/a (libc.so.6 + 0x35e31)
#6 0x00007f0a819e1303 n/a (libc.so.6 + 0xfe303)
#7 0x00007f0a819e15ce n/a (libc.so.6 + 0xfe5ce)
#8 0x00007f0a819e18c6 n/a (libc.so.6 + 0xfe8c6)
#9 0x00007f0a819e018e n/a (libc.so.6 + 0xfd18e)
#10 0x00007f0a819e1680 n/a (libc.so.6 + 0xfe680)
#11 0x00007f0a819e18c6 n/a (libc.so.6 + 0xfe8c6)
#12 0x00007f0a819e26ac n/a (libc.so.6 + 0xff6ac)
#13 0x00007f0a819e3e5a regcomp (libc.so.6 + 0x100e5a)
#14 0x0000556f6395cb34 sh_regmatch (/usr/bin/bash + 0xe3b34)
#15 0x0000556f638b57e5 n/a (/usr/bin/bash + 0x3c7e5)
#16 0x0000556f638bae11 execute_command_internal (/usr/bin/bash + 0x41e11)
#17 0x0000556f638bba54 execute_command (/usr/bin/bash + 0x42a54)
#18 0x0000556f638b8d9c execute_command_internal (/usr/bin/bash + 0x3fd9c)
#19 0x0000556f638bba54 execute_command (/usr/bin/bash + 0x42a54)
#20 0x0000556f638a41f2 reader_loop (/usr/bin/bash + 0x2b1f2)
#21 0x0000556f638969a0 main (/usr/bin/bash + 0x1d9a0)
#22 0x00007f0a8190a675 n/a (libc.so.6 + 0x27675)
#23 0x00007f0a8190a729 __libc_start_main (libc.so.6 + 0x27729)
#24 0x0000556f638975a5 _start (/usr/bin/bash + 0x1e5a5)
ELF object binary architecture: AMD x86-64I meant that "env" line does not cause any crashing when autocompleting within that fresh/bare environment sourced with the bash-completion environment.
The expanding tests will use "ls<TAB><TAB>" to initiate a crash...
"env -i bash": good for both regular/root users
"env -i bash --norc": good for both
"env -i bash --noprofile": good for both
I'm not sure why those tests were needed. I would understand being for my regular user, where I DO have a .shinit that I made.
But the issue also exists for the root user that has no sourced env file. Only ". .. .bash_history .cache .config .lesshst .ssh set test"
The "test" file contained the shell commands for me to read from and type it out.
The "set" file is the output from "set" to see if anything stands out. There's a ton in there, mostly the compgen stuff (2535 lines).
Found it I do believe... It seems I neglected to run "locale-gen".
I had noticed messages like "man: can't set the locale; make sure $LC_* and $LANG are correct" or "Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8. Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead."
Last edited by vindicator (2025-10-23 15:13:01)
Offline
I'm not sure why those tests were needed.
Divine commandment…
printenvIs
env -i bash -lalso bad?
PS: it's to narrow down on the cause, spoiler (maybe): what terminal emulator do you use? Also anything like screen/tmux (though your printenv should tell both as well)
Offline
Thanks Seth and lmn, but I think I got it.
I was updated my previous reply when I saw yours come in.
Marked as solved (if I'm right, and tests show it to be so so far).
Offline