Backslash in unquoted variable for glob expansion

Question

Given these six files:

$ touch  'sec*et'  'sec\*et'  'sec\et'   secet   secret  'sec\ xxx et'

Why backslash in unquoted variable for glob expansion matches only the sec\*et file?

$ v="sec\*et" ; ls $v
'sec\*et'
$ v='sec\*et' ; ls $v
'sec\*et'

Related to this SO answer, the POSIX definition:

The < backslash > shall retain its special meaning as an escape character ... only when followed by one of the following characters when considered special:

$ ` " \ <newline>

and the Bash manual:

The backslash retains its special meaning only when followed by one of the following characters: ‘$’, ‘`’, ‘"’, ‘\’, or newline. Within double quotes, backslashes that are followed by one of these characters are removed. Backslashes preceding characters without a special meaning are left unmodified.

I understand that the backslash (before an asterisk) in the variable is a literal backslash:

$ v='sec\*et' ; printf '%s' "$v" | hexdump -C
00000000  73 65 63 5c 2a 65 74                              |sec\*et|
00000007

But I do not understand why the wildcard character * loses it special meaning after a literal backslash.

---

Three things I understand:

(A) An asterisk * in an unquoted variable has its special meaning in glob expansion. They are equivalent:

$ v='sec*et' ; ls $v
'sec*et'  'sec\*et'  'sec\et'   secet   secret  'sec\ xxx et'
$ ls sec*et
'sec*et'  'sec\*et'  'sec\et'   secet   secret  'sec\ xxx et'

(B) An asterisk * loses its special meaning after a backslash:

$ ls sec\*et
'sec*et'

(C) A literal backslash cannot make the asterisk * loses its special meaning:

$ v='sec\\*et' ; ls $v
'sec\*et'  'sec\et'  'sec\ xxx et'
$ ls sec\\*et
'sec\*et'  'sec\et'  'sec\ xxx et'

---

This is what I do not understand:

However it is weird that, the asterisk loses its special meaning, but the backslash is not discarded, in this case:

$ v='sec\*et' ; ls $v
'sec\*et'

Somehow it is equivalent to a literal backslash followed by a literal asterisk:

$ ls sec\\\*et
'sec\*et'

But why? Consider:

1. If special characters in quotes become literal, (A) does not hold.

2. If the asterisk becomes literal because of following a backslash, why the backslash is not discarded, and matches the file sec*et, like in (B)?

---

In application, other than using Bracket Expression [*], how to define a string variable that matches a literal asterisk when used in glob expansion?

$ v='sec < what what what > et' ; ls $v
'sec*et'

Answer 1

$ v="sec\*et"
$ v='sec\*et'

Either of these sets the variable to sec\*et, and the way the variable got its value doesn't affect how globbing behaves.

The way Bash appears to treat the consequent unquoted expansion appears to be that since it has no unescaped glob characters, the string sec\*et is not treated as a glob at all. It doesn't trigger e.g. failglob, and the backslash is not removed. Instead, it's just printed as-is. (It's not a pattern matching itself: you get the string back even if there is no file of that name.)

This is unlike sec[*]et, which is a glob.

Also, if you were to have sec\*et* instead, it would be a glob and would match filenames that start with sec*et (that is, with the backslash removed).

As far as I can tell, that's how it works for most versions of Bash. The exception being Bash 5.0 where that sec\*et is taken as a glob and where it triggers e.g. failglob.

$ ./bash-4.4/bash    -c 'shopt -s failglob; v="sec\*et"; echo $v'
sec\*et
$ ./bash-5.0/bash    -c 'shopt -s failglob; v="sec*et"; echo $v'
./bash-5.0/bash: no match: sec*et
$ ./bash-5.1.16/bash -c 'shopt -s failglob; v="sec*et"; echo $v'
sec*et
$ ./bash-5.2.15/bash -c 'shopt -s failglob; v="sec*et"; echo $v'
sec*et

(I didn't test all shell versions for all the cases.)