[RFC PATCH 03/28] cli: lil: Replace strclone with strdup

[Wolfgang Denk]

Dear Sean,

In message <5a967151-94f0-6037-2d02-0114c43b846c at gmail.com> you wrote:
>
> AIUI hush has diverged significantly from what U-Boot has. This would
> not be an "update" moreso than a complete port in the style of the
> current series.

Agreed.  However, as you write this it sounds like a big problem
only.  I disagree here - it is also a chance to do a few things
different than with the original port.

Please keep in mind when this original port of the hush shell was
done:  it was a time when many systems came with a total of 4 MB
flash memory, and not only U-Boot, but also the Linux kernel and a
ram-disk image or such had to fit into that.  At that time 40 or 60 kB
code size for just a fancy shell was immense!

Under such restrictions (and the need to complete the task with a
given budget) many things were just commented out which from today's
point of view would be nice to have.


This is not a problem of the code complexity or resources, but only
of different requirements and different resources.


> I don't think sh-style shells are a good match for U-Boot's execution
> environment in the first place. The fundamental idea of an sh-style
> shell is that the output of one command can be redirected to the input
> (or arguments) of another command. This cannot be done (or rather would
> be difficult to do) in U-Boot for a few reasons

There is an old saying:

	The loser says: "It might be possible, but it is too difficult."
	The winner says: "It might be difficult, but it is possible."

Apparently you take another position here than me.

First, I disagree that pipes are the "fundamental idea" of a shell.
It is a fundamental idea of the UNIX operating systems, indeed.

But please keep in mind that we are here in a boot loader, not in a
full-blown OS context.

> * U-Boot does not support multithreading. Existing shells tend to depend
>    strongly on this feature of the enviromnent. Many of the changes to
>    U-Boot's hush are solely to deal with the lack of this feature.

I disagree to both parts of your statement.

Multithreading (or rather, a concept of separate processes which can
eventually even run in parallel) is very nice to have, but it is not
mandatory in most cases.  Command pipes can almost always be
strictly sequentialized and thus run in a single-task environment,
too.  I'm not sure, but I think I even remember pipes in the "shell"
of the CPM "OS" on Z80 processors a number of decades ago...

And the fact that our current version of hush did not attempt to
keep these features was much more driven by strict memory footprint
limitations that anything else.  I claim it would have been
possible, and still is.

You also don't mention (and I guess you oversee) another critical
fact: so far, U-Boot has no concept of files.  The classic design
principle "everything is a file" is missing even more than the
concept of processes.

> * Existing commands do not read from stdin, nor do they print useful
>    information to stdout. Command output is designed for human
>    consumption and is substantially more verbose than typical unix
>    commands.

This is a statement which is correct, but it does not contain any
pro or con for the discussion here.

And if we had the features, it would be easy to fix.

> * Tools such as grep, cut, tr, sed, sort, uniq, etc. which are extremely
>    useful when working with streams are not present in U-Boot.

You are talking about OS environments here.  But we are a boot
loader.

Also, this argument is not fair, as the suggested LIL does not
provide grep, sed, awk, sort, uniq etc. functionality either, or
does it?

> And of course, this feature is currently not present in U-Boot. To get

Correct, and for very good reasons.

> which will set my_uuid to the uuid of the selected partition. My issue
> with this is threefold: every command must add new syntax to do this,
> that syntax is inconsistent, and it prevents easy composition. Consider
> a script which wants to iterate over partitions. Instead of doing
>
> 	for p in $(part list mmc 0); do
> 		# ...
> 	done
>
> it must instead do
>
> 	part list mmc 0 partitions
> 	for p in $partitions; do
> 		# ...
> 	done
>
> which unnecessarily adds an extra step. This overhead accumulates with
> each command which adds something like this.

Apparently you fail to understand that this "extra step" is primarily
due to the fact that we are single tasking. Even if we has command
substitution (like we could have with hush) the execution sequence
would be serialized in exactly the same way under the hood - it's
just not as directly visible.

> Both of these workarounds are natural consequences of using a sh-tyle
> shell in an environment it is not suited for. If we are going to go to

No, they are not.  They are much more the consequence of no strict
design guidelines for commands, so everybody implements what fits his
purposes best.  A cleaner approach does not require any of the
additional features you've asked for - it would be possible as is.

> the effort of porting a new language (which must be done no matter if
> we use Hush or some other language), we should pick one which has better
> support for single-threaded programming.

In which way do you think "a new language" needs to be ported when
switching from an old to a new version of hush?  It would be still a
(mostly) POSIX compatible shell, with some restrictions.


I can fully understand that you defend your proposal, but let's be
fair and stick with the facts.  Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To get something done, a committee should consist  of  no  more  than
three men, two of them absent.