[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] iotests: Work around failing readlink -f

From: Peter Maydell
Subject: Re: [PATCH v2] iotests: Work around failing readlink -f
Date: Mon, 14 Sep 2020 15:26:56 +0100

On Mon, 14 Sep 2020 at 15:17, Max Reitz <mreitz@redhat.com> wrote:
> On macOS, (out of the box) readlink does not have -f.  If the recent
> "readlink -f" call introduced by b1cbc33a397 fails, just fall back to
> the old behavior (which means you can run the iotests only from the
> build tree, but that worked fine for six years, so it should be fine
> still).
> Suppress all error messages, so in case using $PWD works out, we do not
> cause the user to worry.  If it does not work, we will end up printing
> the following error message anyway:
>   check: failed to source common.env (make sure the qemu-iotests are run
>   from tests/qemu-iotests in the build tree)
> Following that hint (running check from $build_tree/tests/qemu-iotests)
> will make it work, and is probably even easier than obtaining a readlink
> that understands -f.
> Fixes: b1cbc33a3971b6bb005d5ac3569feae35a71de0f
>        ("iotests: Allow running from different directory")
> Reported-by: Claudio Fontana <cfontana@suse.de>
> Reported-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
> v2: Suppress stderr (as requested and suggested by Peter)
> ---
>  tests/qemu-iotests/check | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
> index e14a1f354d..3c9ccc117b 100755
> --- a/tests/qemu-iotests/check
> +++ b/tests/qemu-iotests/check
> @@ -44,7 +44,11 @@ then
>          _init_error "failed to obtain source tree name from check symlink"
>      fi
>      source_iotests=$(cd "$source_iotests"; pwd) || _init_error "failed to 
> enter source tree"
> -    build_iotests=$(readlink -f $(dirname "$0"))
> +    build_iotests=$(readlink -f $(dirname "$0") 2>/dev/null)

Having woken up and actually looked at the context for what
we're doing with readlink here, my usual rune for "give me
the absolute path that this script is in" is

thisdir="$(cd "$(dirname "$0")"; pwd)"

which should be more portable than readlink. It doesn't
give quite the same behaviour if it's run via a path which
is a symlink to a directory, eg if bar/ is a symlink to
foo/ and you run a script as bar/thescript then you'll get
back /path/to/bar/ rather than /path/to/foo/, but do you
really need the path with all the symlinks followed
rather than just some valid absolute path to the build dir?

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]