On 12/26/2016 07:24 PM, Andrei Borzenkov wrote: > 26.12.2016 21:12, Jakub Jermář пишет: >>>> I am observing a strange behavior when passing boot arguments with a >>>> backslash to the kernel (the multiboot cmd_line via the multiboot >>>> command in grub.cfg). I would like to pass foo\bar to the kernel, but to >>>> no avail. I tried: >>>> >>> >>> Which kernel? What do you load? >> >> The kernel is a modified version of HelenOS, but IMHO this issue is >> kernel agnostic. > > Not really. It depends on target program being loaded which is why I > asked what you use.
Ok, I submitted my grub.cfg and stated that HelenOS is multiboot-compliant, gets loaded by the multiboot command. We boot from an ISO image, which was created like this: "The binary files of GRUB boot loader in this directory have been created by compiling GRUB for the 'i386-pc' target and then using the grub-mkrescue script to create the El Torito boot image." Is there anything else I should include in order to answer your question? >> The cmd_line is already wrong when picked up from the >> multiboot info and printed out (so there is no processing on it from the >> HelenOS side). > > Sure, but /if/ your kernel interpreted `\' as quoting character, the > result would be correct. But instead of the plain actual data there would be escaped data, which is a hassle. And also a possible workaround. >> I think I understand why it is eating the single backslash (expected >> behavior), > > You have two levels here. First level is grub command line processing. > It is loosely compatible with (Bourne) shell so yes, backslash is > treated as escape character. You can still pass backslash using usual > shell quoting, e.g. foo\\bar or 'foo\bar'. Second level is > grub_create_loader_cmdline() function. This one escapes `\' with second > `\'. So in the above case this function receives `foo\bar' as adds > second `\'. This explains a lot, but does not make much sense for my usecase. Thank you, Jakub _______________________________________________ Bug-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-grub
