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