On Apr 14, 2011 5:28 PM, "Thomas Bächler" <thomas@archlinux.org> wrote:
Am 14.04.2011 23:09, schrieb Dave Reisner:
I tested it better than 0.6.10 and it seems okay. Can someone please proof-read this and tell me if it is good?
Sandbox testing says this doesn't work. I feed in a file containing:
root=/dev/sda video="din:10 foo bar baz" quiet ro
and after parsing, i echo "root=$root" and "video=$video". i get...
video="din:10 foo bar baz root=/dev/sda
Oh yeah, I forgot one line, fixed it (I'll send a v2 in a second).
I posted what I thought was a valid solution on FS#23467 from stack overflow that seems to be a lot more sane and _much_ more maintainable. For those who weren't following the report, I suggested that we use the same fallback as /etc/fstab, which says to encode spaces with octal sequences. These can then be decoded using printf's %b flag. It requires only a simple change to the current parse_cmdline function.
I really don't understand what you mean (or how it would help). What you mentioned doesn't solve the initial problem of finding out which spaces separate arguments and which spaces are inside quoted strings.
It absolutely does because it eliminates spaces within variables, e.g. video=foo\040bar root=… The whole point is that quotes aren't used. fstab sets precedent here so its not some wild and whacky new thing being introduced.
I also never got a response as to where you're seeing pollution from using export over eval.
'export' exports variables to the environment and they are passed on when forking. These variables are for internal purposes in mkinitcpio and don't belong into other applications. As a simple example, I had 'udevd_running=1' set in my environment during initscripts, which certainly shouldn't be there. (This wasn't on the command line, but in another place in mkinitcpio where things where exported when they shouldn't be).
The right way would be something like bash's 'declare', but ash doesn't have that.
Right. I understand what export does. It also wouldn't be hard to cleanse the environment since we know exactly what we're parsing. Having those cars during sysinit? Not the worst thing in the world. Exported to a user's shell? That's a real issue.
Sorry, but eval sucks hard and I've put a lot of effort into _removing_ it from wherever I can in Arch code. It's _rarely_ used properly.
If you check carefully, I use eval right here. There is nothing in the eval'ed strings that should cause trouble.
We'll have to agree to disagree here. The problem is that you can't know what eval is executing in this case because its unbounded and unchecked input. d