Date: Thu, 8 May 2008 13:41:42 -0400 From: ari edelkind <edelkind-freebsd-hackers@episec.com> To: hackers@freebsd.org Subject: Re: binary file within a shell script Message-ID: <20080508174142.GZ79355@episec.com> In-Reply-To: <3e473cc60805080659h721db611s886b80d213f9a2f3@mail.gmail.com> References: <3e473cc60805080659h721db611s886b80d213f9a2f3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
mathieu.prevot@gmail.com wrote:
> I would like to use one exec file from a shellscript but I would like
> it to be incorporated in the same file, like Nvidia do for its FreeBSD
> drivers. How can I do this in a convenient way ?
I haven't looked at nvidia's driver packaging, but you can embed
binaries into shell scripts using uuencode or base64.
Example:
------------------------
% cat >test.sh
#!/bin/ksh
echo "*** generating ls..."
file=`mktemp /tmp/ls.XXXXXX`
[[ $? -eq 0 ]] || exit 1
uudecode -o $lsfile <<'__EOM__'
^D
% uuencode ls </bin/ls >>test.sh
% cat >>test.sh
__EOM__
chmod +x $lsfile
echo "*** running $lsfile ..."
$lsfile
echo "*** cleaning up"
rm -f $lsfile
^D
------------------------
Note that i used single quotes in the here-document initialization, so
there won't be any shell expansion of the uuencoded data.
A few commonly-installed programs that may suit your needs:
- uuencode / uudecode
- base64
- b64
- openssl base64
If relying on one of the above is infeasible:
You can't portably use inline binary data in a shell script without
preprocessing it (as with one of the above programs), since most shells
can't handle binary zeros; shar(1) fails in this case. You could,
theoretically, write a small, clever wrapper function to account for the
issue. You'd also have to ensure that regexp("^__EOM__$") (in the above
example) doesn't exist within the file contents, and note that
excessively long lines may not be handled efficiently by the shell.
You'll need to account for files that do or don't end in a newline,
possibly by always appending an extra newline, then stripping it upon
extraction. Lastly, you'll need to consider whether you must account
for CR/LF conversion in file transfers or while editing your script.
You probably won't want to deal with all of this, and would be better
off leaving it for out-of-band extraction, such as with dan's gzexe
suggestion. You'll still need to determine whether CR/LF conversion may
be an issue for you.
ari
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080508174142.GZ79355>