How should we deal with actual hush odd behavior?

[Simon Glass]

Hi Francis,

On Fri, 20 Aug 2021 at 10:12, Francis Laniel
<francis.laniel at amarulasolutions.com> wrote:
>
> Hi.
>
>
> I hope you are fine and the same for your family and friends.
>
> In July, a proposal to add a new shell for U-Boot was posted on the mailing
> list [1].
> The community discussed a lot about this changes, some people did not agree
> with it because the new shell is not compatible with the actual one (hush)
> [2].
> So, a proposal to update U-Boot actual hush to follow what they currently have
> in Busybox was made [3].
>
> Porting 2021 Busybox hush to U-Boot seems, for me, to be a good idea as we
> would benefit from Busybox bug fixes as well as being compatible with actual
> hush (in theory).
> We could also add new features to U-Boot hush, like functions, as they were
> added to Busybox.
>
> Nonetheless, the idea of this port is to be compatible.
> In practice, I noted some cases when this is actually not the case.
> The first one can be related to how && and || operators were handled in hush.
> So, the following: false && false || true
> Returns 0 on Busybox 2021 hush and 1 on U-Boot.
> The behavior of 2021 is coherent with the definition of these operators [4]:
> >    The return status of AND and OR lists is the exit
> >    status of the last command executed in the list.
> An other example concerns variable expansion, where foo='bar "quux" is
> expanded to bar quux in U-Boot and bar "quux in Busybox.
>
> I do not have a real opinion on the second one, as I think local variable set
> in U-Boot scripts are quite simple as people do not try to do: foo="bar \"quux
> 'quuz' \"\"\"corge".
> The first one is maybe more problematic.
> Grepping "if test" shows me that the more complex if condition seems to be
> under the form:
> if first_test_ AND/OR second_test
> Here also, people seems to no try to write complex expression like: foo ||
> bar; echo quux && quuz.
>
> So, porting Busybox 2021 hush can solve bugs we have currently in U-Boot, but
> what if fixing these bugs lead to a board script failing and so a device not
> booting...
> I would like to have the opinion of the community on this question.

My feeling is that we should go with the newer (correct?) behaviour.
Boards not booting can be found with the existing release process.

Also if we keep the old hush around for a while people can still use
it, particularly if it is much smaller.

Regards,
SImon