On Apr 15, 2013, at 9:28 AM, Michael Brown <[email protected]> wrote:
> On 15/04/13 08:48, Leo Baltus wrote: >> Just a thought: would it make sense to have some sort of framework that >> allows several fields to be editted just like config and login and have >> config and login use that so that 'edit' could benefit from it too. >> >> I think it would be cool to be able to edit a few variables in one 'edit' >> session so you could visually edit for instance both kernel, initrd, and >> command-line options. > > That's almost exactly why I'm wary of adding this feature: people will expect > that ability. That's a very valid concern, and it only grows more valid if any new features are hidden behind a compile-time flag that defaults to #undef (or however that works :P). > Unfortunately, that wouldn't help in terms of byte count. "config" and > "login" already share the framework for edit boxes, which is abstracted out > into editbox.c; there's no viable way I can see to share more code between > these. > > I'm happy to add an "edit" command which will create a single > horizontally-scrollable edit box, which can be exited only via Enter, Ctrl-C, > or Escape. If this isn't going to be sufficient, then I'd rather not add the > feature at all, and leave "read" as the only way to prompt the user for input. > > Michael That may actually be the best compromise... I'd suggest a switch like "--hidetext" or "--password" in case people want to prompt for sensitive information in a way that the login command doesn't properly facilitate. The ideal thing would be, of course, a custom "config" menu with a user-defined set of variables, but I seem to recall that *that* is specifically not facilitated by the current code structure... Hence this discussion for alternatives, right? If not, I've got some ideas for command syntax that you'd probably like :) Cheers, Andrew _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
