On Tue, Jul 06, 2021 at 09:44:20AM +0200, Wolfgang Denk wrote:
> Dear Tom,
>
> In message <20210705191058.GB9516@bill-the-cat> you wrote:
> >
> > > > foo=bar set foo bar
> > > > echo $foo echo $foo
> > > >
> > > > if [ 1 -gt 2 ]; then if {1 > 2} {
> > > > echo a echo a
> > > > else } {
> > > > echo b echo b
> > > > fi }
> > > >
> > > > foo() { proc foo {first second} {
> > > > echo $1 $2 echo $first $second
> > > > } }
> > > >
> > > > for file in $(ls *.c); do foreach file [glob *.c] {
> > > > echo $file echo $file
> > > > done }
> > > >
> > > > fact() {
> > > > if [ $1 -eq 0 ]; then
> > > > echo 1
> > > > else
> > > > echo $(($1 * $(fact $(($1 - 1)))))
> > > > fi
> > > > }
> > > >
> > > > proc fact {n} {
> > > > if {$n} {
> > > > expr {$n * [fact [expr
> > > > {$n - 1}]]}
> > > > } {
> > > > return 1
> > > > }
> > > > }
> > > >
> > > > Hopefully this gives you a bit of a feel for the basic differences.
> >
> > Which of these things, from each column, can you do in the context of
> > U-Boot? That's important too.
>
> Well, with a current version of hush we can do:
>
> -> foo=bar
> -> echo $foo
> bar
>
> -> if [ 1 -gt 2 ]; then
> > echo a
> > else
> > echo b
> > fi
> b
>
> -> foo() {
> > echo $1 $2
> > }
> -> foo bar baz
> bar baz
>
> -> for file in $(ls *.c); do
> > echo $file
> > done
> ls: cannot access '*.c': No such file or directory
>
> -> fact() {
> > if [ $1 -eq 0 ]; then
> > echo 1
> > else
> > echo $(($1 * $(fact $(($1 - 1)))))
> > fi
> > }
> -> fact 4
> 24
>
>
> Oh, in the contect of U-Boot? Well, there are of course
> limitations, but not because of the shell, but because of the fact
> that we have no concept of files, for example.
>
> But another command interpreter will not fix this.Yes, clearly the file based examples won't work either way, as-is. I was asking for what things can be done today with the implementations we have now. I'm pretty confident that exactly zero people have written complex U-Boot scripts and then been happy about the experience. > > This is I think the hard question. A draw of the current shell is that > > it it looks and acts like bash/sh/etc, for at least basic operations. > > That's something that's comfortable to a large audience. That has > > disadvantages when people want to start doing something complex. Sean > > has shown that several times and he's not the only one. LIL being > > tcl'ish is not. > > Tcl is a horror of a language for anything that is above trivial > level. TCL has its fans. csh has it's fans. The question isn't what's the best desktop shell or general scripting language, but what's the most useful in our environment an use cases. > Do you really think that replacing standard shell syntax with Tcl is > "something that's comfortable to a large audience"? I seriously > doubt that. I don't know if it's right either. But drawing on my comment just now and above about complex boot scripts, I also don't know if "it's sh but quirky and incomplete, WHY DOESN'T THIS WORK RIGHT" is better than "It's TCL? I don't know that, let me hit stackoverflow and do a little reading" as would be the common experience. Especially if we document up-front what the quirks we have are. > > Something that has "sh" syntax but also clear to the user errors when > > trying to do something not supported would also be interesting to see. > > It seems like a lot of the frustration from users with our shell is that > > it's not clear where the line between "this is an sh-like shell" and > > "no, not like that" is. > > Did you run some tests on the version of hush as comes with recent > busybox releases? Which of our user's requirements does it fail to > meet? It fails to meet the requirement of having been ported to U-Boot. I'd joke that perhaps you can bootefi busybox, but a quick search says that particular trick looks to still just be for python (https://lwn.net/Articles/641244/). -- Tom
signature.asc
Description: PGP signature
