[U-Boot-Users] 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,
On Tuesday 12 February 2008, Matthias Fuchs 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.
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@denx.de =====================================================================
In message 200802121549.49402.sr@denx.de 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
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
On Tuesday 12 February 2008 15:49, Stefan Roese wrote:
Hi Matthias,
On Tuesday 12 February 2008, Matthias Fuchs 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.
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,
On Wednesday 13 February 2008, Matthias Fuchs wrote:
what about a 'scrubenv' or 'cleanenv' command that tries to unset all variables leaving readonlys untouched.
Or 'resetenv'?
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. :)
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@denx.de =====================================================================
Hi Stefan,
On Wednesday 13 February 2008 09:56, Stefan Roese wrote:
Hi Matthias,
On Wednesday 13 February 2008, Matthias Fuchs wrote:
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 :-)
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. :)
Do not get into details :-)
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
Matthias Fuchs matthias.fuchs@esd-electronics.com writes:
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@denx.de
On Wednesday 13 February 2008, Markus Klotzbücher wrote:
=> 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.
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@denx.de =====================================================================
Stefan Roese sr@denx.de writes:
On Wednesday 13 February 2008, Markus Klotzbücher wrote:
=> 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.
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@denx.de
Hi,
Stefan Roese sr@denx.de writes:
On Wednesday 13 February 2008, Markus Klotzbücher wrote:
=> 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.
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?
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
Detlev Zundel dzu@denx.de writes:
Stefan Roese sr@denx.de writes:
On Wednesday 13 February 2008, Markus Klotzbücher wrote:
=> 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.
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?
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@denx.de
On Wednesday 13 February 2008, Markus Klotzbücher 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"...
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@denx.de =====================================================================
In message m23arxun23.fsf@ohwell.denx.de 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
Wolfgang Denk wrote:
In message m23arxun23.fsf@ohwell.denx.de 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
In message 47B37416.8090708@freescale.com you wrote:
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
Wolfgang Denk wrote:
In message 47B37416.8090708@freescale.com you wrote:
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
In message 47B37791.3010109@freescale.com you wrote:
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
Hi,
In message 47B37791.3010109@freescale.com you wrote:
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.
* 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
In message 200802131113.08367.sr@denx.de you wrote:
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
So I still would like to see the extra check.
Nope. I will NAK it. Markus is absolutley right.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 200802131113.08367.sr@denx.de you wrote:
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
In message 47B37430.8070008@freescale.com you wrote:
=> 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
On Wednesday 13 February 2008, Scott Wood wrote:
Wolfgang Denk wrote:
In message 200802131113.08367.sr@denx.de you wrote:
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.
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@denx.de =====================================================================
In message 200802140620.15102.sr@denx.de 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
Hi Wolfgang,
In message 200802140620.15102.sr@denx.de 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
In message m27ih6p68o.fsf@ohwell.denx.de 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
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
Wolfgang Denk wd@denx.de writes:
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.
[...]
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@denx.de
On 17:40 Fri 15 Feb , Wolfgang Denk wrote:
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?
Ack-By : Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com
Best Regards, J.
Hi,
yes, I can live with the 'env' command, too. Sound's good to me.
Matthias
On Friday 15 February 2008 21:27:20 Jean-Christophe PLAGNIOL-VILLARD wrote:
On 17:40 Fri 15 Feb , Wolfgang Denk wrote:
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?
Ack-By : Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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.
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
In message 00ca01c8740c$5a7b9fe0$c3031c0a@atmel.com 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.
If "env default" is implemented the same way, then you could get a 100% clean environment by:
env clear ; env default
I see.
What will "env" do without parameters?
As usual: it will print it's "usage" message and return an error code.
Best regards,
Wolfgang Denk
In message 200802202217.58210.matthias.fuchs@esd-electronics.com 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
u-boot-users-bounces@lists.sourceforge.net wrote on :
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
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.
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
In message 20080215164010.2944E24D11@gemini.denx.de 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.
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
In message 200802130921.38894.matthias.fuchs@esd-electronics.com you wrote:
what about a 'scrubenv' or 'cleanenv' command that tries to unset all variables leaving readonlys untouched.
Make this "clearenv", please.
The command could request a confirmation:
No.
=> 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
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 =>
What do you think?
Looks good to me...
Best regards,
Wolfgang Denk
In message 200802120944.42632.matthias.fuchs@esd-electronics.com 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.
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
participants (9)
-
Detlev Zundel -
Jean-Christophe PLAGNIOL-VILLARD -
Markus Klotzbücher -
Martin Krause -
Matthias Fuchs -
Scott Wood -
Stefan Roese -
Ulf Samuelsson -
Wolfgang Denk