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

[Wolfgang Denk]

Dear Sean,

In message <4aa7ff19-b774-0d67-b96a-9c0c9290a708 at 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

-- 
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
God made machine language; all the rest is the work of man.