qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 1/6] tests/qemu-iotests: Improve the check for GNU sed


From: Thomas Huth
Subject: Re: [PATCH 1/6] tests/qemu-iotests: Improve the check for GNU sed
Date: Fri, 11 Feb 2022 17:48:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

On 11/02/2022 17.14, Eric Blake wrote:
On Tue, Feb 08, 2022 at 03:52:19PM +0100, Thomas Huth wrote:
The current code with $SED has been introduced almost three years
ago already...

   Can’t we just do `alias sed=gsed`?

Maybe ... but let's ask Philippe and Kevin first, who Signed-off
commit bde36af1ab4f476 that introduced the current way with $SED:
What's your opinion about this?

This commit was to have check-block working on the OpenBSD VM image.

Sure. The question was whether using an alias as suggested by Hanna would be
nicer instead of using $SED ?

Scripting with aliases becomes a nightmare to debug, since it is
relatively uncommon.  In particular, in bash, you have to explicitly
opt in to using aliases (contrary to POSIX sh where aliases are
available to scripts at startup).

shopt -s expand_aliases
... as I just learnt the hard way ;-)

Using $SED everywhere may require
more hunting, but it is more obvious when reading a test that "oh
yeah, I might be using extensions that the default 'sed' can't
support" than a script that blindly uses 'sed' and depends on it
aliasing to a more-capable sed at a distance.

The other question is how many GNU sed features are we actually
depending on?  Which tests break if we have BSD sed or busybox sed?
Can we rewrite those sed scripts to avoid GNU extensions?  But
auditing for s/sed/$SED/ seems easier than auditing for which
non-portable sed extensions we depend on.

The most obvious part are the filter functions in common.filter - we're using "-r" here that is not part of the POSIX sed as far as I can see.

Not sure whether anybody really wants to rewrite all sed statements for full portability, but maybe we could also introduce a wrapper for GNU sed like this:

if ! command -v gsed >/dev/null 2>&1; then
    if sed --version | grep -v 'not GNU sed' | grep 'GNUx sed' \
       > /dev/null 2>&1;
    then
        gsed()
        {
            sed $*
        }
    else
        gsed()
        {
            _notrun "GNU sed not available"
        }
    fi
fi

... then we could simply use "gsed" everywhere we depend on the GNU behavior, and the tests don't look as ugly as with the $SED ?

 Thomas




reply via email to

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