On 09/06/2012 11:12 AM, Tom Rini wrote:
On Wed, Sep 05, 2012 at 08:38:26PM -0600, Stephen Warren wrote:
On 09/05/2012 05:51 PM, Rob Herring wrote:
On 09/05/2012 05:03 PM, Stephen Warren wrote:
From: Stephen Warren swarren@nvidia.com
This implements the following:
part uuid mmc 0:1 -> print partition UUID part uuid mmc 0:1 uuid -> set environment variable to partition UUID
What's the reason to not always both print out and set the uuid env var?
Perhaps the env name should be partuuid or part_uuid as you could have uuid's for other purposes?
The idea is that if you're running the command interactively, you won't pass a variable name on the command-line, so the command will print out the UUID for you to read. In this case, it's pointless to set any environment variable.
However, if you're writing a script, you want to capture the UUID into an environment variable, and it's quite unlikely you want to litter stdout with that content too. Hence, either-or, not both.
Do other commands have a "I'm being scripted, probably, don't stdout" and "I'm being interactive, use stdout" distinction like this? IMHO, always printing out makes sense so you can "see" that your script is working as you expect.
In general, as a script writer, yes you do have the ability to choose. Typically, I'd write:
part uuid ....
vs.
var=`part uuid ....`
in order to control this. However, U-Boot's shell doesn't support backticks. As a script writer, I certainly desire the ability to control what commands spam to the console, and really don't think it's useful to print the UUID from a script (does the user really care, and any script developer can just echo it for debugging if they need it).
I'm not aware of other U-Boot commands whose purpose it is to set environment variables, so can't really compare.
Still, if you're insistent on this point, I can change the code to always print, and optionally write an environment variable.