On Tue, May 06 2025, Tom Rini <tr...@konsulko.com> wrote:
> On Tue, May 06, 2025 at 09:07:05PM +0200, Rasmus Villemoes wrote:
>> On Tue, May 06 2025, Tom Rini <tr...@konsulko.com> wrote:
>>
>> > On Tue, May 06, 2025 at 10:49:31AM -0600, Tom Rini wrote:
>> >> On Tue, May 06, 2025 at 04:10:25PM +0200, Rasmus Villemoes wrote:
>> >>
>> >> > Currently, the only way to make use of regex matching in the shell is
>> >> > by using "setexpr [g]sub" command. That's rather awkward for asking
>> >> > whether a string matches a regex. At the very least, it requires
>> >> > providing setexpr with a dummy target variable, but also, the return
>> >> > value of setexpr doesn't say whether any substitutions were done, so
>> >> > one would have to do some roundabout thing like
>> >> >
>> >> > env set dummy "${string_to_test}"
>> >> > setexpr sub dummy '<some regex>' ''
>> >> > if test "${dummy}" != "${string_to_test}" ; then ...
>> >> >
>> >> > When CONFIG_REGEX is set, teach the test command a new operator, =~,
>> >> > which will allow one to more naturally write
>> >> >
>> >> > if test "${string_to_test}" =~ '<some regex>' ; then ...
>> >> >
>> >> > Signed-off-by: Rasmus Villemoes <r...@prevas.dk>
>> >>
>> >> We should also mention here (and then in docs) that this the same as the
>> >> =~ operator in bash, which I only learned about now as part of answering
>> >> my own question of "Are people going to expect =~ to do something
>> >> else?".
>> >>
>> >> With that,
>> >>
>> >> Reviewed-by: Tom Rini <tr...@konsulko.com>
>> >
>> > Oh, and we should update doc/usage/cmd/setexpr.rst at least and we
>> > should have one for test as well, but don't, yet.
>>
>> Yes, if test.rst had already existed I would have updated it, but I
>> didn't feel like writing the whole thing from scratch until I had a
>> sense of whether these were going anywhere. I'll take a stab at it,
>> including the bash ref, but I'm not sure what you want to put in
>> setexpr.rst? Perhaps a reference to test.rst for an overview of what
>> regex features are available so they don't need to be repeated?
>
> Yeah, for setexpr.rst I would go for (a) making sure it's correct and
> without subtle bugs (as you just fixed a number of them) and then (b)
> noting that the =~ operator exists and link to the new test.rst
See the patch I just sent. As for subtle bugs, IDK, I've made sure that
the setexpr test suite passes throughout my series, so I don't think
I've changed anything that affects those tests, but I also don't know
how comprehensive those tests are or if they even exercise
e.g. character classes.
>> Another thing I considered was to have the 'test foo =~ ...' thing
>> populate shell variables $1, $2, ... with the capture groups, if any;
>> and possibly even $0 with "what matched the whole thing", as U-Boot
>> doesn't really have anything sensible for that.
>
> I would ask what bash does here first (are things saved anywhere?)
Yes, but bash also has array variables, and it stores the capture groups
in the array variable BASH_REMATCH, so capture group 2 would be
"${BASH_REMATCH[2]}". If $n is too subtle, we could certainly make it
REMATCHn instead for analogy with bash.
> as I assume you use this feature there.
Yes, I do occasinally use [[ =~ ]], but no, I rarely find myself needing
to extract capture groups in that setting. But that's probably partly
due to bash's string expansion features that make a lot of string
munging quite easy; e.g. to get the basename of a file one simply does
${file##*/} ; there's really never any reason to do "$(basename
"$file")".
> And then a second of how useful the captured output is likely to be
> outside of debugging a script you're writing.
Well, I had half a use case some time ago when I first started thinking
about having regex matching in U-Boot shell in the first place, but then
I got distracted, did the whole thing some other way, and now I can't
even remember what it was. I'm just floating the idea, and I won't push
it until there is a real use case.
As for the use case for the regex matching itself, this is at first for
some sanity checking/verification of data related a secure boot setup;
if it doesn't match some strict checks, I'll throw it away and use sane
defaults.
Rasmus
