On Mon, Mar 05, 2018 at 01:43:01PM +0100, [ext] Jan Kiszka wrote: > On 2018-03-05 13:24, Andreas Reichel wrote: > > On Mon, Mar 05, 2018 at 01:01:14PM +0100, Jan Kiszka wrote: > >> Hi Andreas, > >> > >> what is bg_setenv without any parameters supposed to do, and what does > >> it actually - besides printing a suspicious "Environment update was > >> successful."? > >> > > > > Good point, thanks for asking. > > > > If you specify no parameter, the program goes into > > (write_mode), since you call bg_setenv and not bg_printenv. > > > > Output to file is false, since no "-f" given. > > > > auto_update is false, since no "-u" given. > > > > part_specified is false, since no "-p" given. > > > > This means, the program opens the latest environment and then calls > > update_environment(env_new), where env_new is a handle to the latest > > environment. (nothing new created at this point). > > > > update_environment then processes an empty task list which does not > > change the latest environment. It then recalculates the CRC32 again. > > > > The program then stores the unmodified environment together with the > > recalculated CRC32 back into the same place and exits. > > > > Thus, bg_setenv without parameters performs a NOP on the current > > environment data except the CRC and writes the values back again. > > > > Thus, the question here is "what is the default behavior, a program > > should have, if started without any parameter". > > Right, and what is the use case behind it. > > > > > I would say, in case of bg_setenv, the behavior is not offbeat, the > > message is true and if the user has doubts about what to do, he should > > use --help anyway. Per definition, all arguments are optional, therefore > > it would be strange if the help page was printed as if the user missed > > something, since optional arguments are not required per definition. > > Normally, one model such a tool via subcommands: > > tool subcommand [OPTIONS] > > Unless there is a case for the current default behaviour. But it seems > like it is rather a side effect of the normal use cases. >
In the very beginning the idea was to have the 'bg_setenv/printenv' pair modelled like 'fw_setenv/printenv' from U-Boot, where no subcommands are used. If we use sub-commands anyway, it does not make sense to have two different names for the program but rather a bg_envtool or so with bg_envtool set and bg_envtool get which is not as elegant imho and which still makes the arguments what to set optional. I guess the easiest way to cope with that is to just output "Nothing specified, no tasks to do, exiting" if no arguments are passed. Andreas > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux > > -- > You received this message because you are subscribed to the Google Groups > "EFI Boot Guard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/efibootguard-dev/b3006f0a-77a0-e67f-1cd9-f93f34f22721%40siemens.com. > For more options, visit https://groups.google.com/d/optout. -- Andreas Reichel Dipl.-Phys. (Univ.) Software Consultant [email protected], +49-174-3180074 TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082 -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/20180305130837.GA2818%40iiotirae. For more options, visit https://groups.google.com/d/optout.
