Eric Blake wrote: > On 09/08/2010 07:20 AM, Jim Meyering wrote: >> grep portability testing has exposed some unwarranted test failures. >> Using a better SHELL was the quick work-around. >> Fixing init.sh is the real fix: >> >>> From d79a9c27419cc4679620b9283351566ba6085cd2 Mon Sep 17 00:00:00 2001 >> From: Jim Meyering<meyer...@redhat.com> >> Date: Wed, 8 Sep 2010 15:18:46 +0200 >> Subject: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr > > I'm a little worried that this patch might exclude all shells on a > given platform. For example, on IRIX 5.3: > > $ /bin/sh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > P=1 > $ /bin/ksh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > + P=1 > $ bash -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > $ > > If bash is manually installed, then things are okay. But all existing > shells on a bare-bones installation output trace information.
If that happens, the result will be that each init.sh-using test will be skipped. > Maybe a compromise is to test that if there is output, is it at least > proceeded by PS4 (in which case it can be filtered), so as not to > outright rejecting /bin/ksh, but still exclude /bin/sh as > unfilterable? But then each init.sh-using test must be audited to discover if/where this makes a difference, and then we'd have to modify offenders to filter out those bogus lines. All for what? To avoid skipping tests when run an ancient system like Irix 5.x that lacks a usable shell. Polluting our code, even "mere" tests, solely to accommodate an inferior or old system is hard for me to justify. I think it scales better simply to eliminate the offending shells -- then we avoid the constant overhead of auditing for yet another portability nit. Of course, if this turns out to affect too many (and more modern) systems, then I'll be the first to look for a lower-impact solution. Besides, isn't Irix 5.x approaching effective museum-only status?
