One of my recipes in Yocto need to create a file containing a very specific line, something like:
${libdir}/something
To do this, I have the recipe task:
do_install() {
echo '${libdir}/something' >/path/to/my/file
}
Keeping in mind that I want that string exactly as shown, I can't figure out how to escape it to prevent bitbake
from substituting in its own value of libdir
.
I originally thought the echo
command with single quotes would do the trick (as it does in the bash
shell) but bitbake
must be interpreting the line before passing it to the shell. I've also tried escaping it both with $$
and \$
to no avail.
I can find nothing in the bitbake
doco about preventing variable expansion, just stuff to do with immediate, deferred and Python expansions.
What do I need to do to get that string into the file as is?
-m, --kill-server Terminate any running bitbake server.
Fundamentally, BitBake is a generic task execution engine that allows shell and Python tasks to be run efficiently and in parallel while working within complex inter-task dependency constraints.
PN : Represents the name of the recipe. The name is usually extracted from the recipe file name.
BitBake is a make-like build tool with the special focus of distributions and packages for embedded Linux cross compilation, although it is not limited to that. It is inspired by Portage, which is the package management system used by the Gentoo Linux distribution.
Bitbake seems to have particular issues in preventing expansion from taking place. Regardless of whether you use single or double quotes, it appears that the variables will be expanded before being passed to the shell.
Hence, if you want them to not be expanded, you need to effectively hide them from BitBake, and this can be done with something like:
echo -e '\x24{libdir}/something' >/path/to/my/file
This uses the hexadecimal version of $
so that BitBake does not recognise it as a variable to be expanded.
You do need to ensure you're running the correct echo
command however. Under some distros (like Ubuntu), it might run the sh
-internal echo
which does not recognise the -e
option. In order to get around that, you may have to run the variant of echo
that lives on the file system (and that does recognise that option):
/bin/echo -e '\x24{libdir}/something' >/path/to/my/file
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With