[U-Boot] Normal command line behavior?
I notice that when I hit return at a U-Boot > prompt, it executes the last command again. CONFIG_SYS_HUSH_PARSER is defined, from U-Boot 2009.08-rc1-00030-g56bdfa9-dirty.
It this is expected, it seems like a *really* bad idea. It's cost me having to reload 6M images at 115200 twice now.
--jc
J.C. Wren wrote:
I notice that when I hit return at a U-Boot > prompt, it executes the last command again. CONFIG_SYS_HUSH_PARSER is defined, from U-Boot 2009.08-rc1-00030-g56bdfa9-dirty.
It this is expected, it seems like a *really* bad idea. It's cost me having to reload 6M images at 115200 twice now.
--jc
Hi JC,
It is a configuration/design decision: see include/command.h line 46ff, struct cmd_tbl_s, field "repeatable". This is configured via the U_BOOT_CMD macro.
Sometimes it is nice (e.g. sequencing through memory dumps), sometimes it bites (you found one of those!). IMHO, it is enabled in places where it would be better to rely on command line recall rather than the repeat function.
I think the repeat functionality predated the command line recall functionality, so it use to be more desirable to repeat the command because there wasn't an alternative way to repeat the command.
Best regards, gvb
Dear Jerry Van Baren,
In message 4A773C1C.7080109@ge.com you wrote:
It is a configuration/design decision: see include/command.h line 46ff, struct cmd_tbl_s, field "repeatable". This is configured via the U_BOOT_CMD macro.
Sometimes it is nice (e.g. sequencing through memory dumps), sometimes it bites (you found one of those!). IMHO, it is enabled in places where it would be better to rely on command line recall rather than the repeat function.
The general rule is that any command that is non-destructive is repeatable, i. e. a "tftp" will be repeated, while an "erase" will not.
Indeed, today command line history makes it partially dispensable, but often at the cost of more typing (think about using the "md" command).
I think the repeat functionality predated the command line recall functionality, so it use to be more desirable to repeat the command because there wasn't an alternative way to repeat the command.
Correct, this, and because that was exactly what I wanted when I implemented it :-)
Best regards,
Wolfgang Denk
All fair points.
It appears that the 'nand' commands don't use the new parser structure. The 'nand' and 'nboot' commands use the U_BOOT_CMD macro, and have repeatable defined as 1. The 'nand' command is doing it's own sub-command parsing (via strcnmp()'s), and as a result, all 'nand' commands are repeatable. That probably isn't a good idea, and I would request the the 'nand' command itself be made non-repeatable.
--jc
On Mon, Aug 3, 2009 at 5:58 PM, Wolfgang Denk wd@denx.de wrote:
Dear Jerry Van Baren,
In message 4A773C1C.7080109@ge.com you wrote:
It is a configuration/design decision: see include/command.h line 46ff, struct cmd_tbl_s, field "repeatable". This is configured via the U_BOOT_CMD macro.
<
http://git.denx.de/?p=u-boot.git;a=blob;f=include/command.h;h=55caa6eaf888cd...
Sometimes it is nice (e.g. sequencing through memory dumps), sometimes it bites (you found one of those!). IMHO, it is enabled in places where it would be better to rely on command line recall rather than the repeat function.
The general rule is that any command that is non-destructive is repeatable, i. e. a "tftp" will be repeated, while an "erase" will not.
Indeed, today command line history makes it partially dispensable, but often at the cost of more typing (think about using the "md" command).
I think the repeat functionality predated the command line recall functionality, so it use to be more desirable to repeat the command because there wasn't an alternative way to repeat the command.
Correct, this, and because that was exactly what I wanted when I implemented it :-)
Best regards,
Wolfgang Denk
-- 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@denx.de The software required `Windows 95 or better', so I installed Linux.
On Tue, Aug 04, 2009 at 12:07:17PM -0400, J.C. Wren wrote:
All fair points.
It appears that the 'nand' commands don't use the new parser structure.
Do you mean U_BOOT_CMD_MKENT, find_cmd_tbl, etc?
The 'nand' and 'nboot' commands use the U_BOOT_CMD macro, and have repeatable defined as 1. The 'nand' command is doing it's own sub-command parsing (via strcnmp()'s), and as a result, all 'nand' commands are repeatable. That probably isn't a good idea, and I would request the the 'nand' command itself be made non-repeatable.
The one nand command that probably should be repeatable is "nand dump", with auto-increment similar to "md".
-Scott
On Tue, Aug 4, 2009 at 3:48 PM, Scott Wood scottwood@freescale.com wrote:
On Tue, Aug 04, 2009 at 12:07:17PM -0400, J.C. Wren wrote:
All fair points.
It appears that the 'nand' commands don't use the new parser structure.
Do you mean U_BOOT_CMD_MKENT, find_cmd_tbl, etc?
Not sure about that part. I just went back and looked at cmd_i2c.c, cmd_yaffs2.c and a few others and I see they all do sub-command processing with strncmp(), too. I had looked at one other file prior to my post, and thought I understood sub-commands were plugged-in with macros. My mistake.
I forgot to mention that all the yaffs commands are top level. If I were me, I'd like to see the yaffs command broken down into a sub-menu. That's just a minor nit, as having them all in the top level makes the help a little more unwieldy. And they'd be used infrequently enough that having them under a 'y' sub-menu wouldn't make them much more difficult to use.
The 'nand' and 'nboot' commands use the U_BOOT_CMD macro, and have repeatable defined as 1. The 'nand' command is doing it's own sub-command parsing (via strcnmp()'s), and as a result, all 'nand' commands are repeatable. That probably isn't a good idea, and I would request the the 'nand' command itself be made non-repeatable.
The one nand command that probably should be repeatable is "nand dump", with auto-increment similar to "md".
Makes sense.
-Scott
Dear "J.C. Wren",
In message 17434f2e0908041305i629aef0dmbf23e620a61fe505@mail.gmail.com you wrote:
Not sure about that part. I just went back and looked at cmd_i2c.c, cmd_yaffs2.c and a few others and I see they all do sub-command processing with strncmp(), too. I had looked at one other file prior to my post, and
Yes, that's the old, deprecated way of doing this. Today we know better.
I forgot to mention that all the yaffs commands are top level. If I were me, I'd like to see the yaffs command broken down into a sub-menu. That's
Please feel free to submit a patch.
Best regards,
Wolfgang Denk
participants (5)
-
J.C. Wren -
Jerry Van Baren -
Mike Frysinger -
Scott Wood -
Wolfgang Denk