[Libguestfs] [libnbd PATCH 03/20] nbdsh: Check for python-exec2c installations

[Martin Kletzander]

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 at 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 at 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20210608/b2709e10/attachment.sig>