Delete all env vars except read onlys
Hi,
I am wondering if there is a way to delete all environment variables but not the readonly ones. The common way to delete all variables is to make the environment CRC invalid an do a reset. After reset a saveenv saves a default environment.
What I want to do is to delete all variables (preferable from an autoscr script) but not the vendor variables like serial# and eth?addr.
Wildcards in the setenv parameters would solve this issue, but chars like '*' or '?' are valid chars for environment variables.
Any idea?
Matthias
Hi Matthias,
Quoted 5 lines · Matthias Fuchs
I am wondering if there is a way to delete all environment variables but not the readonly ones. The common way to delete all variables is to make the environment CRC invalid an do a reset. After reset a saveenv saves a default environment.
Quoted 7 lines
What I want to do is to delete all variables (preferable from an autoscr script) but not the vendor variables like serial# and eth?addr.
Wildcards in the setenv parameters would solve this issue, but chars like '*' or '?' are valid chars for environment variables.
Any idea?
I don't know of such a solution. But such a "feature" would be handy sometimes. So perhaps this needs to get implemented as a new U-Boot command. But you should be careful. Such a command should require probably a password, to that users don't unintentionally erase their environment.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
Quoted 5 lines · In message <[email protected]> you wrote:
I don't know of such a solution. But such a "feature" would be handy sometimes. So perhaps this needs to get implemented as a new U-Boot command. But you should be careful. Such a command should require probably a password, to that users don't unintentionally erase their environment.
Please don't do passwords in U-Boot (btw - it might be difficult, as the logical way to store these would be in the environment :-)
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 Conscious is when you are aware of something, and conscience is when you wish you weren't.
Hi Stefan,
what about a 'scrubenv' or 'cleanenv' command that tries to unset all variables leaving readonlys untouched.
The command could request a confirmation:
=> scrubenv
Do you really want to do this ('yes' or 'no')? yes Can't overwrite "serial#"
Can't overwrite "ethaddr"
=> saveenv
The above output is faked. So I did not start coding :-)
What do you think?
Matthias
Quoted 23 lines · Stefan Roese
Hi Matthias,
Quoted 5 lines · Matthias Fuchs
I am wondering if there is a way to delete all environment variables but not the readonly ones. The common way to delete all variables is to make the environment CRC invalid an do a reset. After reset a saveenv saves a default environment.
Quoted 7 lines
What I want to do is to delete all variables (preferable from an autoscr script) but not the vendor variables like serial# and eth?addr.
Wildcards in the setenv parameters would solve this issue, but chars like '*' or '?' are valid chars for environment variables.
Any idea?
I don't know of such a solution. But such a "feature" would be handy sometimes. So perhaps this needs to get implemented as a new U-Boot command. But you should be careful. Such a command should require probably a password, to that users don't unintentionally erase their environment.
Best regards,
Stefan
Hi Matthias,
Quoted 2 lines · Matthias Fuchs
what about a 'scrubenv' or 'cleanenv' command that tries to unset all variables leaving readonlys untouched.
Or 'resetenv'?
Quoted 7 lines
The command could request a confirmation:
=> scrubenv
Do you really want to do this ('yes' or 'no')? yes Can't overwrite "serial#"
Can't overwrite "ethaddr"
=> saveenv
Yes, I was just thinking (while showering, no joke) about this and had the same idea with an 'yes' check. :)
Quoted 3 lines
The above output is faked. So I did not start coding :-)
What do you think?
Looks good to me.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
Hi Stefan,
Quoted 7 lines · Stefan Roese
Hi Matthias,
Quoted 2 lines · Matthias Fuchs
what about a 'scrubenv' or 'cleanenv' command that tries to unset all variables leaving readonlys untouched.
Or 'resetenv'?
All the same to me with the name. As always it will be the most complicated part. I have to remember the 'ethrotate' variable :-)
Quoted 11 lines
Quoted 8 lines
The command could request a confirmation:
=> scrubenv
Do you really want to do this ('yes' or 'no')? yes Can't overwrite "serial#"
Can't overwrite "ethaddr"
=> saveenvYes, I was just thinking (while showering, no joke) about this and had the same idea with an 'yes' check. :)
Do not get into details :-)
Quoted 6 lines
Quoted 4 lines
The above output is faked. So I did not start coding :-)
What do you think?
Looks good to me.
I put it on my list.
Matthias
Quoted 7 lines · Matthias Fuchs
what about a 'scrubenv' or 'cleanenv' command that tries to unset all variables leaving readonlys untouched.
The command could request a confirmation:
=> scrubenv
Do you really want to do this ('yes' or 'no')? yes
Such a confirmation is not very Unix-like and will prevent this command to be used in scripts. I like the idea of a scrubenv/resetenv command but vote for leaving out the confirmation.
U-Boot provides many, much more serious ways to blow you foot off which don't ask such questions.
Best regards
Markus Klotzbuecher
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
Quoted 9 lines · Markus Klotzb?cher
Quoted 2 lines
=> scrubenv
Do you really want to do this ('yes' or 'no')? yesSuch a confirmation is not very Unix-like and will prevent this command to be used in scripts. I like the idea of a scrubenv/resetenv command but vote for leaving out the confirmation.
U-Boot provides many, much more serious ways to blow you foot off which don't ask such questions.
Sure. But not by "just" typing one command. Or at least I don't know those kind of destructive commands.
So I still would like to see the extra check.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
Quoted 8 lines · Stefan Roese
Quoted 7 lines · Markus Klotzb?cher
Quoted 2 lines
=> scrubenv
Do you really want to do this ('yes' or 'no')? yesSuch a confirmation is not very Unix-like and will prevent this command to be used in scripts. I like the idea of a scrubenv/resetenv command but vote for leaving out the confirmation.
Quoted 5 lines
Quoted 2 lines
U-Boot provides many, much more serious ways to blow you foot off which don't ask such questions.
Sure. But not by "just" typing one command. Or at least I don't know those kind of destructive commands.
It need not be a single one, it could be a script. For instance, I once ran an "update" script without checking that _my_ version of U-Boot would be used. It used some ancient version which turned the board (temporarily) into a doorstop.
Stupid? Yes! But would such checks (e.g. to "mw") have avoided the problem? I doubt it. Probably I'd just have typed "yes" without checking.
BTW, after accidentally erasing the environment variables U-Boot will (likely) still start up, so it's really not that critical, is it?
Just my 2c.
Best regards
Markus
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
Hi,
Quoted 21 lines
Quoted 8 lines · Stefan Roese
Quoted 7 lines · Markus Klotzb?cher
Quoted 2 lines
=> scrubenv
Do you really want to do this ('yes' or 'no')? yesSuch a confirmation is not very Unix-like and will prevent this command to be used in scripts. I like the idea of a scrubenv/resetenv command but vote for leaving out the confirmation.
Quoted 5 lines
Quoted 2 lines
U-Boot provides many, much more serious ways to blow you foot off which don't ask such questions.
Sure. But not by "just" typing one command. Or at least I don't know those kind of destructive commands.
It need not be a single one, it could be a script. For instance, I once ran an "update" script without checking that _my_ version of U-Boot would be used. It used some ancient version which turned the board (temporarily) into a doorstop.
Quoted 6 lines
Stupid? Yes! But would such checks (e.g. to "mw") have avoided the problem? I doubt it. Probably I'd just have typed "yes" without checking.
BTW, after accidentally erasing the environment variables U-Boot will (likely) still start up, so it's really not that critical, is it?
Why not do both? Unix untilities do it sometimes this way: Use an interactive check for "scrubenv" but allow "scrubenv -force" not to ask. As many of the U-Boot users know Unix, this would follow from the "principle of least surprise"...
Cheers
Detlev
Signature · 8 lines
Progress in mathematics comes from repeated acts of generalization.
If mathematics is anything, it is the art of chosing the most elegant
generalization for some abstract pattern. Thus esthetics is central.
-- Douglas Hofstadter
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.deQuoted 25 lines · Detlev Zundel
Quoted 25 lines
Quoted 8 lines · Stefan Roese
Quoted 7 lines · Markus Klotzb?cher
Quoted 2 lines
=> scrubenv
Do you really want to do this ('yes' or 'no')? yesSuch a confirmation is not very Unix-like and will prevent this command to be used in scripts. I like the idea of a scrubenv/resetenv command but vote for leaving out the confirmation.
Quoted 5 lines
Quoted 2 lines
U-Boot provides many, much more serious ways to blow you foot off which don't ask such questions.
Sure. But not by "just" typing one command. Or at least I don't know those kind of destructive commands.
It need not be a single one, it could be a script. For instance, I once ran an "update" script without checking that _my_ version of U-Boot would be used. It used some ancient version which turned the board (temporarily) into a doorstop.
Stupid? Yes! But would such checks (e.g. to "mw") have avoided the problem? I doubt it. Probably I'd just have typed "yes" without checking.
Quoted 7 lines
Quoted 2 lines
BTW, after accidentally erasing the environment variables U-Boot will (likely) still start up, so it's really not that critical, is it?
Why not do both? Unix untilities do it sometimes this way: Use an interactive check for "scrubenv" but allow "scrubenv -force" not to ask. As many of the U-Boot users know Unix, this would follow from the "principle of least surprise"...
Yeah, why not both. That's fine with me!
Best regards
Markus Klotzb?cher
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
Quoted 6 lines · Markus Klotzb?cher
Quoted 4 lines
Why not do both? Unix untilities do it sometimes this way: Use an interactive check for "scrubenv" but allow "scrubenv -force" not to ask. As many of the U-Boot users know Unix, this would follow from the "principle of least surprise"...
Yeah, why not both. That's fine with me!
Yes, I like it too.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
Quoted 5 lines · In message <[email protected]> you wrote:
Why not do both? Unix untilities do it sometimes this way: Use an interactive check for "scrubenv" but allow "scrubenv -force" not to ask. As many of the U-Boot users know Unix, this would follow from the "principle of least surprise"...
That would be exactly the other way round, i. e. provide an optional "-i" argument like "rm *" is doing in Unix.
The default shall be not to ask any questions.
Best regards,
Wolfgang Denk
Signature · 8 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
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
They say, well, meybe it _is_ smelly, maybe it _is_ overcrowded, may-
be it _is_ a bit like Hell would be if they shut the fires off and
stabled a herd of incontinent cows there for a year, but you must
admit that it is full of sheer, vibrant, dynamic _life_.
- Terry Pratchett, _Moving Pictures_Quoted 10 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> you wrote:
Why not do both? Unix untilities do it sometimes this way: Use an interactive check for "scrubenv" but allow "scrubenv -force" not to ask. As many of the U-Boot users know Unix, this would follow from the "principle of least surprise"...
That would be exactly the other way round, i. e. provide an optional "-i" argument like "rm *" is doing in Unix.
The default shall be not to ask any questions.
rm defaults to not asking questions in *some* cases, but to asking in others. Hence the -f flag to rm.
-Scott
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 5 lines
That would be exactly the other way round, i. e. provide an optional "-i" argument like "rm *" is doing in Unix.
The default shall be not to ask any questions.
rm defaults to not asking questions in *some* cases, but to asking in others. Hence the -f flag to rm.
Oops??? "rm" never asks unless you ask it to ask.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
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
Q: How do you play religious roulette?
A: You stand around in a circle and blaspheme and see who gets
struck by lightning first.Quoted 9 lines · Wolfgang Denk
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 4 lines
That would be exactly the other way round, i. e. provide an optional "-i" argument like "rm *" is doing in Unix.
The default shall be not to ask any questions.
rm defaults to not asking questions in *some* cases, but to asking in others. Hence the -f flag to rm.
Oops??? "rm" never asks unless you ask it to ask.
Not true. It will ask if you don't have write permission to the file, even if you are able to delete because you have write permission to the directory.
The -f flag wouldn't be there if it were a no-op...
-Scott
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 2 lines
Oops??? "rm" never asks unless you ask it to ask.
Not true. It will ask if you don't have write permission to the file, even if you are able to delete because you have write permission to the directory.
Does it? Indeed. Must be a GNUism. I bet this was't there in Unix v6 when I learned it ;-)
You are right, but this is still a special case where another, explicit protection is being overwritten.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 You got to learn three things. What's real, what's not real, and what's the difference." - Terry Pratchett, _Witches Abroad_
Hi,
Quoted 8 lines
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 2 lines
Oops??? "rm" never asks unless you ask it to ask.
Not true. It will ask if you don't have write permission to the file, even if you are able to delete because you have write permission to the directory.
Quoted 6 lines
Does it? Indeed. Must be a GNUism. I bet this was't there in Unix v6 when I learned it ;-)
You are right, but this is still a special case where another, explicit protection is being overwritten.
* mkfs.ext2 on a file, needs -F package managers with unfulfilled
* dependencies always ask and need a "--force-xxx" to go ahead whatsoever.
* bzip2, bunzip2, bzcat, gzip, gzcat, gunzip -f to overwrite files
* git-checkout-index needs -f to overwrite files
* git-push needs -f to push non-linear head
* git-fetch needs -f in same situtation
* rsync -force to force deletion of dirs even if not empty
....
I'll stop here. It seems the unix commandline tilted to a behaviour where interactive commands tend to ask in dangerous situations but scripts can explicitely override it - which is definitely what I prefer.
Cheers
Detlev
Signature · 6 lines
Woman who seek to be equal with men lack ambition
-- Timothy Leary
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.deQuoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
U-Boot provides many, much more serious ways to blow you foot off which don't ask such questions.
Sure. But not by "just" typing one command. Or at least I don't know those kind of destructive commands.
=> prot off all; era all
Quoted 1 line
So I still would like to see the extra check.
Nope. I will NAK it. Markus is absolutley right.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 Let the programmers be many and the managers few -- then all will be productive. -- Geoffrey James, "The Tao of Programming"
Quoted 7 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> you wrote:
Quoted 2 lines
U-Boot provides many, much more serious ways to blow you foot off which don't ask such questions.
Sure. But not by "just" typing one command. Or at least I don't know those kind of destructive commands.
=> prot off all; era all
There's a slight difference between two commands with arguments versus one command with none.
-Scott
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 2 lines
=> prot off all; era all
There's a slight difference between two commands with arguments versus one command with none.
Well, as Markus already wote, there are so many ways to kill yourself. If you don't accept the line above, just try "run update" without loading a (valid) image first.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 One essential to success is that you desire be an all-obsessing one, your thoughts and aims be co-ordinated, and your energy be concentra- ted and applied without letup.
Quoted 5 lines · Scott Wood
Quoted 4 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:
Quoted 2 lines
U-Boot provides many, much more serious ways to blow you foot off which don't ask such questions.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Sure. But not by "just" typing one command. Or at least I don't know those kind of destructive commands.
=> prot off all; era all
There's a slight difference between two commands with arguments versus one command with none.
Yes, there is a big difference for my taste.
I would still prefer the version with the '--force' parameter. Just my 2 cents.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
Quoted 3 lines · In message <[email protected]> you wrote:
I would still prefer the version with the '--force' parameter. Just my 2 cents.
I really don't want to have this, for two reasons: 1) U-Boot doesn't do "Do you really want to" confirmations, because these don't fit into the Unix design philisophy; 2) U-Boot doesn't do GNU style long command line switches (for several reasons, memory footprint being one of them).
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 Quantum Mechanics is God's version of "Trust me."
Hi Wolfgang,
Quoted 10 lines
Quoted 3 lines · In message <[email protected]> you wrote:
I would still prefer the version with the '--force' parameter. Just my 2 cents.
I really don't want to have this, for two reasons: 1) U-Boot doesn't do "Do you really want to" confirmations, because these don't fit into the Unix design philisophy; 2) U-Boot doesn't do GNU style long command line switches (for several reasons, memory footprint being one of them).
As I hinted at in my other mail, git is my prime example of living up to the spirit of unix - and still many commands there, e.g. git-push need a '-f' to prevent clobbering costly changes inadvertently.
In my opinion your argument 1) is not true as it stands. Unix wants its users to be as productive as possible and typing two extra characters when ommitting them can cause hours of work is definitely in this spirit.
Exaggerating your argument I would ask why you do not work only as root on your machine. In U-Boot we do not have this "user" level of protection so IMHO it makes sense to have at least a bit of it.
It is true however that we don't have any kind of option processing, so probably '-force' wasn't a good choice to begin with. What about only using "all" as a "conformative" option?
Cheers
Detlev
Signature · 7 lines
Perfection (in design) is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
-- Antoine de Saint-Exupery
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.deQuoted 4 lines · In message <[email protected]> you wrote:
As I hinted at in my other mail, git is my prime example of living up to the spirit of unix - and still many commands there, e.g. git-push need a '-f' to prevent clobbering costly changes inadvertently.
The important point is the "inadvertently". It is OK if you need an overwrite flag for commands that in the normal course of action are non-destructive, but in special situations are.
However, commands which are designed to cause "destructive" actions don't ask:
* rm does not ask by default. Not even for "rm -r *"
* mkfs does not ask normally - it will happily kill the whole partition's content
* cp or mv will happily overwrite target files (assuming sufficient permissions)
etc.
The "clearenv" command has a well-defined purpose: clear the
environment. Similar like "erase" will clear the flash. Or "cp" or "mw" will overwrite even vital parts of the RAM. No questions being asked.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 Bus error -- please leave by the rear door.
Uff....
After a longish discussion with Detlev we came up with a new proposal, which hopefully is acceptable to all. We agreed that a command name like "clearenv" or "scrubenv" or similar (which doesn't require any arguments) might be too dangerous for the unexperienced user why randomly types commands "just to see what happens". For example, even if you type "erase" it will not do any damage because arguments are missing - but "erase all" will blow away most of your flash content without asking.
So the idea is to call the new command "environment" (or short "env"); usage would be then:
=> env clear
to clear the envrionment (except read-only variables); thsi also allows for pretty useful additional functionality like this:
=> env default
to reset the environment to the (compiled in) default settings.
One might even consider something like
=> env clear all
to blow away the whole env, including the read-only variables.
Would that be acceptable to everybody?
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 "There is such a fine line between genius and stupidity." - David St. Hubbins, "Spinal Tap"
Quoted 8 lines · Wolfgang Denk
After a longish discussion with Detlev we came up with a new proposal, which hopefully is acceptable to all. We agreed that a command name like "clearenv" or "scrubenv" or similar (which doesn't require any arguments) might be too dangerous for the unexperienced user why randomly types commands "just to see what happens". For example, even if you type "erase" it will not do any damage because arguments are missing - but "erase all" will blow away most of your flash content without asking.
[...]
Quoted 1 line
Would that be acceptable to everybody?
Sounds good!
Best regards
Markus Klotzb?cher
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
Quoted 23 lines · Wolfgang Denk
Uff....
After a longish discussion with Detlev we came up with a new proposal, which hopefully is acceptable to all. We agreed that a command name like "clearenv" or "scrubenv" or similar (which doesn't require any arguments) might be too dangerous for the unexperienced user why randomly types commands "just to see what happens". For example, even if you type "erase" it will not do any damage because arguments are missing - but "erase all" will blow away most of your flash content without asking.
So the idea is to call the new command "environment" (or short "env"); usage would be then:
=> env clear
to clear the envrionment (except read-only variables); thsi also allows for pretty useful additional functionality like this:
=> env default
to reset the environment to the (compiled in) default settings.
Quoted 10 lines
One might even consider something like
=> env clear all
to blow away the whole env, including the read-only variables.
Would that be acceptable to everybody?
Best Regards,
J.
Hi,
yes, I can live with the 'env' command, too. Sound's good to me.
Matthias
Quoted 46 lines · On Friday 15 February 2008 21:27:20 Jean-Christophe PLAGNIOL-VILLARD wrote:
Quoted 23 lines · Wolfgang Denk
Uff....
After a longish discussion with Detlev we came up with a new proposal, which hopefully is acceptable to all. We agreed that a command name like "clearenv" or "scrubenv" or similar (which doesn't require any arguments) might be too dangerous for the unexperienced user why randomly types commands "just to see what happens". For example, even if you type "erase" it will not do any damage because arguments are missing - but "erase all" will blow away most of your flash content without asking.
So the idea is to call the new command "environment" (or short "env"); usage would be then:
=> env clear
to clear the envrionment (except read-only variables); thsi also allows for pretty useful additional functionality like this:
=> env default
to reset the environment to the (compiled in) default settings.
Quoted 8 lines
One might even consider something like
=> env clear all
to blow away the whole env, including the read-only variables.
Would that be acceptable to everybody?
Best Regards,
J.-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
After a longish discussion with Detlev we came up with a new proposal, which hopefully is acceptable to all. We agreed that a command name like "clearenv" or "scrubenv" or similar (which doesn't require any arguments) might be too dangerous for the unexperienced user why randomly types commands "just to see what happens". For example, even if you type "erase" it will not do any damage because arguments are missing - but "erase all" will blow away most of your flash content without asking.
So the idea is to call the new command "environment" (or short "env"); usage would be then:
=> env clear
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
to clear the envrionment (except read-only variables); thsi also allows for pretty useful additional functionality like this:
=> env default
to reset the environment to the (compiled in) default settings.
I see this as essential and have implemented this in my own u-boot. I call it "defenv".
It is a little different though, It will reinitialize the predefined environment variables to default settings but will not touch the other.
If "env default" is implemented the same way, then you could get a 100% clean environment by:
env clear ; env default
What will "env" do without parameters?
Best Regards
Ulf Samuelsson
Quoted 4 lines · In message <[email protected]> you wrote:
It is a little different though, It will reinitialize the predefined environment
variables to default settings but will not touch the other.
Makes sense.
Quoted 4 lines
If "env default" is implemented the same way, then you could get a 100% clean environment by:
env clear ; env default
I see.
Quoted 1 line
What will "env" do without parameters?
As usual: it will print it's "usage" message and return an error code.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 "If you are afraid of loneliness, don't marry." - Chekhov
Quoted 2 lines · In message <[email protected]> you wrote:
yes, I can live with the 'env' command, too. Sound's good to me.
Hm... and who will submit the patch?
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 A bore is someone who persists in holding his own views after we have enlightened him with ours.
u-boot-users-bounces at lists.sourceforge.net wrote on :
Quoted 14 lines
Uff....
After a longish discussion with Detlev we came up with a new proposal, which hopefully is acceptable to all. We agreed that a command name like "clearenv" or "scrubenv" or similar (which doesn't require any arguments) might be too dangerous for the unexperienced user why randomly types commands "just to see what happens". For example, even if you type "erase" it will not do any damage because arguments are missing - but "erase all" will blow away most of your flash content without asking.
So the idea is to call the new command "environment" (or short "env"); usage would be then:
Quoted 6 lines
=> env clear
to clear the envrionment (except read-only variables); thsi also allows for pretty useful additional functionality like this:
=> env default
This would be a very nice feature. With this command no knowledge is needed in which sector(s) the environment is stored. This would be very convenient in our production or service department, because all our different boards could be reseted to a known state with the same command.
Quoted 11 lines
to reset the environment to the (compiled in) default settings.
One might even consider something like
=> env clear all
to blow away the whole env, including the read-only variables.
Would that be acceptable to everybody?
No objections!
Best Regards,
Martin Krause
--
TQ-Systems GmbH
Muehlstrasse 2, Gut Delling, D-82229 Seefeld
Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl
http://www.tq-group.com
Quoted 22 lines · In message <[email protected]> I wrote:
After a longish discussion with Detlev we came up with a new proposal, which hopefully is acceptable to all. We agreed that a command name like "clearenv" or "scrubenv" or similar (which doesn't require any arguments) might be too dangerous for the unexperienced user why randomly types commands "just to see what happens". For example, even if you type "erase" it will not do any damage because arguments are missing - but "erase all" will blow away most of your flash content without asking.
So the idea is to call the new command "environment" (or short "env"); usage would be then:
=> env clear
to clear the envrionment (except read-only variables); thsi also allows for pretty useful additional functionality like this:
=> env default
to reset the environment to the (compiled in) default settings.
Quoted 8 lines
One might even consider something like
=> env clear all
to blow away the whole env, including the read-only variables.
Would that be acceptable to everybody?
There was general agreement that this was a good thing, but I haven't seen any actual code yet.
I anybody working on this?
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 Q: Do you know what the death rate around here is? A: One per person.
Quoted 3 lines · In message <[email protected]> you wrote:
what about a 'scrubenv' or 'cleanenv' command that tries to unset all variables leaving readonlys untouched.
Make this "clearenv", please.
Quoted 1 line
The command could request a confirmation:
No.
Quoted 2 lines
=> scrubenv
Do you really want to do this ('yes' or 'no')? yes
No. Such code will not go into U-Boot.
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." - Doug Gwyn
Quoted 2 lines
Can't overwrite "serial#"
Can't overwrite "ethaddr"
I would not print such messages, especially since you aren't overwriting these. If you want, print a similar warning as used by the "erase" command for protected flash sectors, i. e. something like:
=> cleanenv Warning: 5 protected variables will not be cleared =>
Quoted 1 line
What do you think?
Looks good to me...
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer
Quoted 6 lines · In message <[email protected]> you wrote:
I am wondering if there is a way to delete all environment variables but not the readonly ones. The common way to delete all variables is to make the environment CRC invalid an do a reset. After reset a saveenv saves a default environment.
Quoted 7 lines
What I want to do is to delete all variables (preferable from an autoscr script) but not the vendor variables like serial# and eth?addr.
Wildcards in the setenv parameters would solve this issue, but chars like '*' or '?' are valid chars for environment variables.
Any idea?
There is no direct way; you may write a small standalone application...
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel 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 Extended Epstein-Heisenberg Principle: In an R & D orbit, only 2 of the existing 3 parameters can be defined simultaneously. The parame- ters are: task, time and resources ($).