On Tue, Jun 08, 2021 at 10:50:35AM +0100, Richard W.M. Jones wrote:
On Tue, Jun 08, 2021 at 09:53:44AM +0200, Martin Kletzander wrote:
> Platforms that utilise python-exec [0] wrapper scripts (mainly Gentoo) utilise
Did you mean "[0]" to reference a URL?
> basenames of python scripts and executables to decide which python
> implementation to use for running that particular command. That
> makes the nbdsh "hack" in sh/nbdsh.in not work, even if 'exec -a'
is
> supported by sh.
It's annoying that we have to work around Gentoo here by adding a
dependency on coreutils. I suppose FreeBSD does have readlink(1).
Yes, coreutils are everywhere and the dependency is even documented in
the libnbd readme, so that should not be an issue. Of course the check
can be done in various ways, even just the mere presence of the wrapper
could be checked with the usual `python-exec2c --version`. Come to
think of it, that might actually be nicer.
But my feeling is that the Gentoo script is broken if it cannot cope
with an unexpected basename.
Well, it's not "broken", but more of a "non-standard". This is
the way
they made it work to have any python package installed with any python
interpreter version. All the binaries and scripts are symlinks to
python-exec2 and that decides whether to run python 3.6 or 3.9 (or
historically 2.7 for example). For rolling distro it is a bit more
complex to manage it. But that is not really the point, sorry.
Anyway, it does almost the same thing as you, except it checks for which
python implementation the package is installed and it does that in
python (with some bells and whistles).
Would a configure-time test be better here? It seems like it would
have less chance of breaking on the end-user machine (I know that on
Gentoo, "end-user" is a distinction without a difference but it would
make nbdsh more robust on non-Gentoo). Also it would mean the package
didn't need to depend on coreutils.
What could actually be the best solution for this if the nbdsh.in is
just changed to:
#!/usr/bin/env @PYTHON@
import nbdsh
nbdsh.shell()
or you can also use runpy:
https://docs.python.org/3/library/runpy.html
We can drop this patch until we figure this out. It is not that
important. But having it behave similarly to above would also remove
the "non-standardiness" of nbdsh.
Rich.
> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
> ---
> sh/nbdsh.in | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/sh/nbdsh.in b/sh/nbdsh.in
> index d10f0c1b6b26..333c2d5f8b96 100644
> --- a/sh/nbdsh.in
> +++ b/sh/nbdsh.in
> @@ -19,7 +19,8 @@
>
> # Test if /bin/sh supports exec -a option (only supported in bash 4.2
> # and above, and not part of POSIX).
> -if /bin/sh -c 'exec -a test true' 2>/dev/null; then
> +if /bin/sh -c 'exec -a test true' 2>/dev/null && \
> + test $(readlink $(which @PYTHON@)) != python-exec2c; then
> exec -a nbdsh @PYTHON@ -mnbd "$@"
> else
> exec @PYTHON@ -mnbd "$@"
> --
> 2.31.1
>
> _______________________________________________
> Libguestfs mailing list
> Libguestfs(a)redhat.com
>
https://listman.redhat.com/mailman/listinfo/libguestfs
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org