[Top][All Lists]

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

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

From: Kerin Millar
Subject: bug#53801: [PATCH] tests: have printf(1) use octal numbers for POSIX conformance
Date: Mon, 7 Feb 2022 18:21:31 +0000

On Mon, 7 Feb 2022 09:10:12 -0800
"Brian C. Lane" <bcl@redhat.com> 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

reply via email to

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