Dear Sean,
In message 5a967151-94f0-6037-2d02-0114c43b846c@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