
Alexander Holler holler@ahsoftware.de writes:
Am 03.08.2014 19:51, schrieb Wolfgang Denk:
Dear Alexander,
In message 53DE658F.5010703@ahsoftware.de you wrote:
Just to clarify: I see uEnv.txt (which only was possible through your env import implementation) as a read-only configuration file for u-boot,
This is just one of the many possible usages.
And I don't think all the necessary stuff to save a file in all the possible filesystems should end up in u-boot. Modifying filesystems is dangerous.
Thius has nothing to do with exporting an environment. The export operation and the writing to the file system are two separate steps. If a file system driver contains write support or not depends on the file system code. For the environment it does not matter. If we have write support, we just use it.
So from a u-boot point of view uEnv.txt is a read-only mechanism and I'm happy with it as such.
As mentioned, this is but one usage.
I think that "env import" / "env export" should be kept symmetric.
Using a \r\n instead of \n when -r is used for env export should be something like 4 liner or such.
But it would not be really symmetric. The -r for "env import" makes "env import" eat both formats, which means it can be used almost always, but using -r with "env export" would be a decision which always would be wrong for many people.
Of course, adding the possibility to export the environment in a system-foreign format (Assuming nobody boots windows using u-boot) doesn't really make a harm, it just adds the danger that people will use -r for "env export" because it is used for "env import" too, which most likely would be wrong for most usage scenarios.
Why not just make "env import" treat \r like any other whitespace? It would be a slight change from current behaviour, but the chance that someone actually relies on a trailing \r being part of the value is vanishingly small.