redboot-cmdline can not cope with slashes in cmdline

[Oliver Grawert]

Binary package hint: redboot-tools

the current redboot-cmdline gets unhappy if slashes show up in the cmdline, input should be parsed through
sed s/\\\//'\\'\\\//g
or different quoting should be applied to the script.

[Dave Martin (dave-martin-arm)]

Note that there is a possible quoting error on line 88 of the original redboot-cmdline script:
        NEWSCRIPT="$(echo "$(${CMD})"|sed s/\"[^]]*\"/\""${CMDLINE}"\"/g)\\"

The sed command executed inside the command substitution is
        sed s/\"[^]]*\"/\""${CMDLINE}"\"/g

I think the [^]]* is unquoted, so glob expansion will be done on the whole word s/...[^]]*.../.../g
You'd have to be really unlucky for that to match some existing file though :P Usually therefore the [^]]* falls through unmodified.

(But then trying to understand non-trivial shell quoting cases always ties my brain in knots...)

[Dave Martin (dave-martin-arm)]

Also, do you mean [^"] instead of [^]] ? This would be my assumption, so that a closed, double-quoted string on a single line is matched and substituted.

[Dave Martin (dave-martin-arm)]

Here's a version of the script I hacked to quote the new command line so that it can be substituted in safely with sed.

I used temp files instead of a shell variable to store the boot commands, since using sed on files "feels" a bit safer, because of what $(...) does to newlines. But after doing it I'm not sure it gains anything much, since $(...) is needed to paste the result into the fconfig command line anyway...

I also tried to make matching of the command line in the boot commands a bit more robust, but that might be overkill.

It's still messy and contains some debug --- let me know if you want me to clean it up; otherwise feel free to pull anything useful from it.

[Dave Martin (dave-martin-arm)]

Oh, here's one other comment I had:

If no string is matched and substituted, really that's an error, but sed does not return any special status to indicate this, and currently redboot-cmdline doesn't detect or report this, though it should just result in the old command line being written back again so although the result won't be what the user expects, the system shouldn't be broken (?) If the string is substituted multiple times, that might be considered an error too. However, I think these things shouldn't occur unless the RedBoot commands were garbage in the first place.

GNU sed can return a programmable status value via the q or Q commands (as in s/this/that/; t1; q1; :1) - this might be useful, but this behaviour is not in POSIX and might not work with busybox sed for example (I've not tried it); so if detecting this case it might be safer to use grep explicitly.

[Tobin Davis (gruemaster)]

Changing importance and removing assignment as this is probably not worth going back to fix. Most systems are moving to u-boot going forward anyways.