From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] 'filesize' env var - making U-Boot command more scriptable?
Date: Sun, 15 Oct 2017 13:50:40 +0200 [thread overview]
Message-ID: <20171015115040.ECEB41202A0@gemini.denx.de> (raw)
In-Reply-To: <CAJ+vNU1c86fd3yj+qnZE5SnPLmzHaUWF68oT+gwHKYmNag84Hg@mail.gmail.com>
Dear Tim,
In message <CAJ+vNU1c86fd3yj+qnZE5SnPLmzHaUWF68oT+gwHKYmNag84Hg@mail.gmail.com> you wrote:
>
> Various U-Boot commands that deal with files/blobs end up setting the
> 'filesize' env variable to be used for subsequent commands which is
> very handy. I haven't found this documented anywhere but a scan of the
> code looks like this is done by
Documentation is certainly not perfect, but at least filesize gets
mentioned in the U-Boot environment variables section of the manual;
see the very end of [1] (plus a few othe rplaces).
[1] http://www.denx.de/wiki/view/DULG/UBootEnvVariables
> I've seen other commands that allow a usage that will allow specifying
> a var name to put a result in.
>
> I've noticed commands such as 'ubi' and 'nand' would benefit from
> setting filesize when dealing with volume names and partition names.
> I've also noticed how some commands (ie nand) are good about reporting
> sizes in hex but others (ie ubi) report them in decimal only making it
> difficult for someone to even cut-and-paste sizes to following
> commands.
>
> Has there been a desire or proposal to make this more standard or come
> up with something different?
If you really think about it, all of this is just a worarounf for
the lack of command substitution (aka backquotes / backticks) in the
available command interpreters in U-Boot.
The currently most used one is based on an ancient version of hush
from the BusyBox project. It has a large number of severe
restrictions and a fair number of known other issues.
IMO if somebody is willing to spend efforts in this area it would be
best to replace hust by a more recent version of a shell, adding
command substitution.
[If you go a step further you might even think about introducing a
concept of "files" and adding pipes. But then we would be mioving
more and more into the direction of an OS ;-) ]
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
All this doesn't alter anything, you know. The world is still full of
stupid people. They don't use their brains. They don't seem to want
to think straight. - Terry Pratchett, _Soul Music_
prev parent reply other threads:[~2017-10-15 11:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 16:47 [U-Boot] 'filesize' env var - making U-Boot command more scriptable? Tim Harvey
2017-10-15 11:50 ` Wolfgang Denk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171015115040.ECEB41202A0@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox