Issue with rm command in omb when autocompleting wrong capitalization

[amrinder-cs]

So i had a bunch of temporary files created in capital letters, named:

ABCD.zip
ABCD-arm.zip
ABCD-X86.zip

etc. I also had:
abcd/
abcd-arm/

I tried to delete those zips, so i did
rm -rf ABCD* while using oh-my-bash, however it also deleted my important folders abcd/ and abcd-arm/
I'd be in great trouble if i hadn't committed to git.

Let bash handle the way it normally does so it doesn't happen with someone else.

an example:

[akinomyoga]

This is related to the following setting in OMB's ~/.bashrc.

oh-my-bash/templates/bashrc.osh-template

Line 18 in e712342

# OMB_CASE_SENSITIVE="true"

This variable is referenced here to set up Bash's option nocaseglob.

oh-my-bash/lib/shopt.sh

Lines 27 to 33 in e712342

	# Case-sensitive globbing (used in pathname expansion) and matching
	# (used in case, [[]], word expansions and command completions)
	if [[ ${OMB_CASE_SENSITIVE:-${CASE_SENSITIVE:-}} == true ]]; then
	shopt -u nocaseglob
	else
	shopt -s nocaseglob
	fi

Your report seems to suggest that turning nocaseglob on by default is not a good idea, but there might be another reason for the current behavior. We need to investigate the background of why we have been turning on nocaseglob by default. In addition, nocaseglob seems to have been turned on by default for a long time, so if we change the default behavior now, it will affect a large number of users.

The setting CASE_SENSITIVE originates in the upstream Oh My Zsh (OMZ):

https://github.com/ohmyzsh/ohmyzsh/blob/62cf1201b031399e7251abeee859e895ee825a48/templates/zshrc.zsh-template#L20

In the upstream OMZ, this variable is used to set the behavior of the completion. It is not used to control the behavior related to the pathname expansions.

https://github.com/ohmyzsh/ohmyzsh/blob/62cf1201b031399e7251abeee859e895ee825a48/lib/completion.zsh#L16-L26

The current behavior in OMB was introduced in #399. Originally, CASE_SENSITIVE only affected the behavior of the completion (bind "set completion-ignore-case on"), but @jjmcdn has extended it to affect also nocaseglob and nocasematch (though nocasematch was reverted in #503). Before that, we had been always turning on nocaseglob. This nocaseglob seems to come from bash-sensible:

https://github.com/mrzool/bash-sensible/blob/89fa380e3d46210a85b4236098ada2c2ae280ac4/sensible.bash#L33-L34

The line was added by @mrzool in the following commit in bash-sensible, which implies that turning on nocaseglob is considered sensible:

mrzool/bash-sensible@e2cabcb

@jjmcdn @mrzool Do you have any thoughts on the default setting for the Bash option shopt -s nocaseglob?

[amrinder-cs]

I mean it is fine at auto-completing case-sensitive stuff, however it should not override the command behavior based on that, it should be limited to just Autocomplete.

Such as:

• Suggesting me based on non case autocomplete: GOOD
• Also acting while ignoring the case: BAD. It should be: "what i see is what i get".

[akinomyoga]

As described above, the story is that even before the setting for the completion started to override the behavior for the pathname expansions in #399, nocaseglob (i.e. the setting for the pathname expansions to ignore the case) had been turned on for a long time. That is, #399 technically opened a way to turn off nocaseglob through OMB_CASE_SENSITIVE.

I kind of agree with you that nocaseglob shouldn't be turned on by default, but it contradicts bash-sensible. We want to check the background.

It should be: "what i see is what i get".

What you see is TEST*, but it is obvious that you don't expect to delete the file of the literal name as if rm -rf 'TEST*'. The meaning of TEST* changes depending on nocaseglob, and this is a feature of Bash.

[akinomyoga]

@mrzool Sorry for bothering you after eight years, but if you have time, do you remember the background of mrzool/bash-sensible@e2cabcb in bash-sensible?

[mrzool]

Hey @akinomyoga, sorry for the delay. That’s a really good question. I tried to recall and checked my notes, but I couldn’t find anything. I also checked my personal configuration and noticed I’m not using that option on my machine. If I ever had a reason to add it, that reason is long forgotten by now, and I’m happy to remove it before anyone risks losing data. Interestingly, I don’t think it’s ever been reported.

[akinomyoga]

@mrzool Thank you for taking the time to check them and reply to us! I understand that it would often be difficult to recall the background of the options after eight years.

Since the native assumption by the users that the glob matching would be case sensitive would cause an actual problem as reported here, if there isn't an obvious breakage by turning off nocaseglob, I'm now thinking of turning off nocaseglob by default and see if any problems are reported by users. If there are problems, we can revert the change.