bug#53801: [PATCH] tests: have printf(1) use octal numbers for POSIX conformance

On Mon, 7 Feb 2022 09:10:12 -0800
"Brian C. Lane" <[email protected]> wrote:

> On Mon, Feb 07, 2022 at 08:52:33AM -0800, Brian C. Lane wrote:
> > On Sat, Feb 05, 2022 at 10:44:29AM +0000, Kerin Millar wrote:
> > > Hello,
> > > 
> > > The attached patch rectifies some test failures that were reported at https://bugs.gentoo.org/774363. Whether it be a builtin of sh(1) or not, POSIX does not require for the printf utility to support hexadecimal notation.
> > > 
> > > -- 
> > > Kerin Millar
> > 
> > Thanks for the patch. I'll have to ponder this for a bit. So the issue
> > is showing up in Gentoo because it uses dash, right? The issue I have
> > with the change is that it then obscures what's being written. Everyone
> > knows what 0x55aa is :) I'd prefer a solution that continues to use hex
> > so that future users don't have to figure out what's going on.
> 
> Actually, on Fedora at least, printf comes from coreutils so the shell
> shouldn't matter at all. The tests are single quoted to prevent shell
> expansion, so maybe dash is using a builtin printf that's different?

$ bash -c 'type printf'
printf is a shell builtin

Yes, it's also a builtin in dash (it is rare these days for printf to ever be invoked in its capacity as a binary). As explained by my prior message, no implementation of the POSIX shell and utilities (XCU) is under any obligation to support GNU-specific features. Therein lies the rub. Octal sequences are guaranteed to work. The problem is a great many Linux developers only ever test things in bash, even where their shebangs purport to target sh.

-- 
Kerin Millar