Dear Sean,
In message 4aa7ff19-b774-0d67-b96a-9c0c9290a708@gmail.com you wrote:
Without pipes, how do bourne-style shells communicate? Sure you can transfer data into functions using arguments, but what about the other way around? Numeric return values? Global variables? I think these are rather anemic compared to proper return values.
Pipes are basically just a shortcut to avoid buffer space and to make scripting easier and more elegant.
For example:
$ ps aux | grep foo | grep -v grep | awk '{print $2}' | xargs kill
can be written without use of pipes as:
$ ps aux >/tmp/$$.1 ; \ grep foo </tmp/$$.1 >/tmp/$$.2 ; \ grep -v grep </tmp/$$.2 >/tmp/$$.1 ; \ awk '{print $2}' </tmp/$$.1 >/tmp/$$.2 ; \ xargs kill </tmp/$$.2 ; \ rm -f /tmp/$$.1 /tmp/$$.2
[and of course this could be done in many other ways, too, cleaner and more efficient]
The point is: Pipes are just a shortcut. You can do all the same using files - of course with different performance and resource usage.
The point here is that many Hush features were written with fork. For example, to create a new scope (such as for a subshell), Hush just fork()s. When parsing, if it encounters a construct like $(), it fork()s
Yes, of course I am fully aware of this. This is one of the reasons why command substitution was excluded from the inital port of hush to U-Boot - but again: command sustitution is just a shortcut; it is simple enough to write scripts without it, and it is certainly possible to implent this feature in a U-Boot context as well.
The reason it was not done 18 years ago is 1) typical systems at that time did not have the resources (especially not enough ROM for a bigger U-Boot image), and 2) having a shell with basic scripting capabilities was sheer extravagance in a boot loader.
Yes, the situation has changed since then; today a U-Boot image is as big as a v2.2 Linux kernel image was then, and nobody cares.
and then modifies the map variable, (correctly) assuming that the "original" map will remain unmodified. These things are all over and make doing a port difficult; especially when they crop up as unforseen bugs. Though I suppose the real issue here is a lack of virtual memory.
Not really. At the time of the port the concern was about code size (size of the text segment).
IMO "everything is a file" is more of an API thing than a shell thing. E.g. the idea that you can use open/read/write/close to access any resource. But without pipes, I don't think such an abstraction is very useful.
Pipes are just a notation to allow for a convenient use of coroutines, even from a command line interface. They make you think of concurrent processing, but (on single core machines - which was all they had at the time this was invented) it was just an emulation of concurrency on a strictly sequential system.
Nothing really fancy at all, once you have the idea. And nothing that could not be emulated in a U-Boot environment, either.
The question is: how urgently do we need it?
My experience is that if anything is _really_ needed, someone will show up and implement it, probably funded by some customer who needs this feature for some product. I have yet to see any such urgent need for pipes in U-Boot.
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats.
That's the theory, yes. In reality, things are a bit different. Look at the output format of classic Unix commands: ls, ps, df, ...
I don't know about that. I think making U-Boot commands emit output designed for machine consumption would require substantial effort.
Unix commands usually have NOT been designed for "machine consumption", on contrary. Even network protocols, log files atc. were intentionally designed to be humanly readable.
It's the flexibility of the tools which allows for clever usage.
In U-Boot, commands could be cleaned up for better use in pipes - assuming we had those. But there would be no need to do this ina single huge action - it could be done step by step, one command at a time when somebody needs to use it in such a way.
- 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.
These programs are just as much part of the shell as the builtin commands.
Sorry, but they are definitely NOT part of the _shell_.
They are part of the standard Unix toolbox for basic text processing, but for many good reasons each of these is a separate program, and the shell knows nothing of these.
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.
Modern Hush is completely unrecognizable compared to what we have in U-Boot today. Any "updating" effort would be akin to going over the entire upstream codebase and porting it from scratch.
Agreed. But this means porting some code, which still implements the very same language (i. e. "shell"). There would be no new language in this case - just a bigger subset, less restrictions, more options, probably.
Best regards,
Wolfgang Denk