Regex in shell fails to evaluate

Continuing the discussion from Regex in shell fails to evaluate:

The thread was marked 'solved' but further diagnostic information disputes the 'answer'.
Exhibit #1 (taken from hostname pWPW10-1)

BusyBox v1.36.1 (2025-10-19 16:37:45 UTC) built-in shell (ash)

root@pWPW10-1:~# [[ 2 =~ [0-4] ]] && echo T || echo F
F
root@pWPW10-1:~# set -x
root@pWPW10-1:~# [[ 2 =~ [0-4] ]] && echo T || echo F
+ '[[' 2 '=~' 1 ]]
+ echo F
F
root@pWPW10-1:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='24.10.4'
DISTRIB_REVISION='r28959-29397011cc'
DISTRIB_TARGET='ath79/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt 24.10.4 r28959-29397011cc'
DISTRIB_TAINTS=''

Exhibit #2 (taken from hostname pWPW10-2)

BusyBox v1.36.1 (2025-10-19 16:37:45 UTC) built-in shell (ash)

root@pWPW10-2:~# [[ 2 =~ [0-4] ]] && echo T || echo F
T
root@pWPW10-2:~# set -x
root@pWPW10-2:~# [[ 2 =~ [0-4] ]] && echo T || echo F
+ '[[' 2 '=~' '[0-4]' ]]
+ echo T
T
root@pWPW10-2:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='24.10.4'
DISTRIB_REVISION='r28959-29397011cc'
DISTRIB_TARGET='ath79/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt 24.10.4 r28959-29397011cc'
DISTRIB_TAINTS=''

Quoting the range expression within the bracket expression on hostname pWPW10-1 results in the expected (and identical to that from hostname pWPW10-2) evaluation and exit status -

root@pWPW10-1:~# [[ 2 =~ "[0-4]" ]] && echo T || echo F
+ '[[' 2 '=~' '[0-4]' ]]
+ echo T
T

As can be seen in the cat output of the OWRT release information, both devices execute the same OWRT installation.

Comments / suggestions from shell experts are solicited and very welcome.

I think the issue may be related to pathname expansion (globbing) occurring before the regex is evaluated.

I was able to reproduce the same behavior on my OpenWrt 25.12.2 system:

echo [0-4]
[0-4]

[[ 2 =~ [0-4] ]] && echo T || echo F
T

However, after creating a file named 1 in the current working directory:

touch 1

echo [0-4]
1

set -x
[[ 2 =~ [0-4] ]] && echo T || echo F
+ '[[' 2 '=~' 1 ]]
F

This looks very similar to the trace from pWPW10-1, where [0-4] appears to be expanded to 1 before [[ evaluates the expression.

Could you check whether the current working directory (pwd) on pWPW10-1 contains a file or directory named 1 (or any filename matching [0-4])?

It would also be useful to compare the output of:

pwd
echo [0-4]
ls -la

on both systems.

Right in one!

root@pWPW10-1:~# ls -l
-rw-r--r--    1 root     root           857 Jun  7 09:25 1
root@pWPW10-1:~#

The (b)ash documentation states that globbing AKA file expansion does not occur -

[[…]]

[[ expression ]]

Evaluate the conditional expression expression and return a status of zero (true) or non-zero (false). Expressions are composed of the primaries described below in Bash Conditional Expressions. The words between the [[ and ]] do not undergo word splitting and filename expansion. The shell performs tilde expansion, parameter and variable expansion, arithmetic expansion, command substitution, process substitution, and quote removal on those words. Conditional operators such as ‘-f’ must be unquoted to be recognized as primaries.

Good catch. The presence of the file named 1 explains the different behavior perfectly.

One thing worth noting is that the documentation quoted above applies specifically to Bash:

echo $0
-bash

whereas OpenWrt normally uses BusyBox ash:

echo $0
-ash

Although ash supports many Bash-like constructs, it does not necessarily implement them with identical parsing and expansion rules. In this case, the set -x output shows that the RHS of =~ is being expanded before the comparison:

+ '[[' 2 '=~' 1 ]]

which is consistent with pathname expansion occurring due to the file named 1.

So the Bash documentation is correct for Bash, but it should not be assumed to describe BusyBox ash behavior. When investigating shell-specific behavior on OpenWrt, it is usually safest to refer to ash/BusyBox documentation or to verify the behavior directly with small test cases.

In any case, quoting the pattern:

[[ 2 =~ '[0-4]' ]]

avoids the pathname expansion and gives consistent results regardless of the contents of the current directory.

Even it could sound rude, but please do your research and homework of over 40 years of shell history, posix, and what not.
As already stated the default shell on OpenWrt comes from BusyBox which uses ash.

The documentation of the compound conditional as implemented in BB/sh is, AFAICT, 'documented' in the C code (BASH_TEST2) which is to say, it does not state if file expansion is performed. It not documented in any text that ones with weak DDG-foo are capable of unearthing.
Should @_bernd have the force and deigns to paste a link, well then all too happy to RTFW!

Aren't you barking up the wrong tree ?

Openwrt uses BB, it didn't write it.

@frollic - no one is assigning responsibility. This is a polite request for documentation on a topic what is apparently, obscure if not rare read, non-existent.

No worries.

You can log on to the Openwrt wiki using a GitHub account, feel free to add text where ever you think it's needed.

Unless it's should be provided by BB themselves.

I would assume to look at BusyBox and ash then?
And don't you are able to imagine that 40+ years of shell behavior and standards are no short tale to tell?
Tldr best is to stick to defined posix behavior if you need robust and or portable scripts.

@_bernd - 'reliable' read, documented, is applicable here, not 'robust' nor 'portable' (definitely unnecessary when a script contains proprietary OWRT PROCD, UCI and jshn.sh commands).
Then again, perhaps Claude can tell a better 'tale' than what is currently 'on offer' through this forum. The mounting evidence indicates that ash documentation does not, beyond its 1990s version, exist.

What is your issue? You complained about [[ and [ and test.

@_bernd - the 'issue' is a request for help in the form of definitive ash / sh documentation. At present, the request is unanswered and in all probability will remain so.

Do you have access to a document that describes the expansion behaviour of ash where the compound conditional ([[) is concerned? I believe all involved here hold the view that it should be available from the BB/sh git and it is not.

That OWRT has chosen ash (via BB) for its size is understandable. It then serves to reason that the level of knowledge (from extensive coding of scripts for ash) should be widely available in the OWRT forums. And yet, that does not appear to hold true as indicated by answers amounting to 'it is not bash'.

The behaviour of ash is completely acceptable when it complies with the documentation. I think everyone can agree with this statement. Guessing at its behaviour creates urban legends.

Now that @ncompact has identified and described the behaviour, I think it best to move on.