[Buildroot] [PATCH] fs/oci: entrypoint and command are space-separated lists

Peter Korsgaard peter at korsgaard.com
Fri May 13 06:06:32 UTC 2022


>>>>> "Arnout" == Arnout Vandecappelle <arnout at mind.be> writes:

Hi,

 >> It indeed makes sense to split the entrypoint on white space, but
 >> for
 >> the args (cmd) it exchanges one set of breakage for another -
 >> E.G. sometimes people want to run sh -c "my shell logic goes here".
 >> I'm not sure what to do about that though. As you are not quoting
 >> the
 >> arguments you cannot even set it to stuff without white space but ith
 >> shell characters, E.G. ENTRYPOINT="sh -c" ARGS="date;date" as the ; gets
 >> enterpreted in the call to sloci-image.

 >  Do you mean

 > BR2_TARGET_ROOTFS_OCI_ENTRYPOINT="sh -c"
 > BR2_TARGET_ROOTFS_OCI_ENTRYPOINT_ARGS="'date; date'"

Yes, exactly.


 > ? Yeah, we'd need a full quoting/splitting parse to support that. In
 > this particular case

 > BR2_TARGET_ROOTFS_OCI_ENTRYPOINT_ARGS="date\;date"

 > would work, but it's kludgy.

 >  I do think it would help to put quotes around the options:

 > OCI_SLOCI_IMAGE_OPTS += $(patsubst %,--cmd '%',$(OCI_ENTRYPOINT_ARGS))

Yes, agreed. That atleast fixes the special shell characters (except for
' itself).


 >  That way, the usual cases (which Yann put in the commit message) are
 >  covered, but weird stuff is still possible as long as you pay
 > attention to spaces.

 >  If you really need spaces, you can still use $(space). So, after
 >  adding single quotes, the following should work:

 > BR2_TARGET_ROOTFS_OCI_ENTRYPOINT_ARGS="date;$(space)date"

Nice and easy for newcomers :P


 >> In general I'm not sure how much value the oci support brings over just
 >> doing:
 >> docker import -c '<Dockerfile command>' output/images/rootfs.tar
 >> <name>:<tag>

 >  That requires a docker daemon installed on the host, while
 >  sloci-image can be run as normal user without any host support
 > required.

s/docker import/podman import/. With that said, wanting to build an OCI
image and not having access docker/podman is quite unlikely I think.

-- 
Bye, Peter Korsgaard



More information about the buildroot mailing list