On Tue, Feb 15, 2022 at 02:28:24PM +0100, Thomas Huth wrote:
On 11/02/2022 17.48, Thomas Huth wrote:
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.
Now that I stepped through the list, the other major part that is failing on
non-GNU seds are the statements that use "\r" or "\n" or "\e" to replace
special characters. That seems to be a non-POSIX extension, too.
But for running with Alpine, there is also the additional problems that the
libc uses slightly different error strings, e.g. "I/O error" instead of
"Input/output error", see e.g.:
https://gitlab.com/thuth/qemu/-/jobs/2094869856
Maybe it could be fixed with some extensions to the filters, but I'm not
sure whether we really want to go down that road...?
AFAIK, errno strings are not standardized by POSIX, so I presume this
problem will apply to running I/O tests on any non-Linux system too.
With this in mind I think we should consider what a portable solution
looks like. We can't simply match the Alpine strings and turn them
into GLibC strings, as that does nothing to help portability on *BSD,
macOS, Windows, etc.