On 07/18/2017 08:25 AM, Geoff Clare wrote: > Eric Blake <ebl...@redhat.com> wrote, on 18 Jul 2017: >> >> On 07/18/2017 04:48 AM, Geoff Clare wrote: >>> >>> On page 2398 line 76737 section 2.14 exec, add to EXAMPLES: >>> >>> Execute the implementation's <i>printf</i> utility, ensuring that any >>> shell built-in version is not executed instead, and using a subshell >>> so that the shell continues afterwards: >>> >>> <tt>(exec printf '%g\n' "$float_value")</tt> >> >> The standard does not require printf %g to work > > That was exactly my reason for choosing that example. The idea is > that if you are going to rely on implementation-defined behaviour, > then always using the external printf utility means you are only > dependent on whether that version of printf supports %g; you don't > care whether or not the various shells that might be used to run > the script also support it in their built-in version.
Fair enough, although the wording could make that obvious, perhaps as: An application that is not concerned with strict conformance can ensure the use of an implementation's extension behavior of %g within the <i>printf</i> utility, by ensuring that any shell built-in version is not executed instead, and using a subshell so that the shell continues afterwards: > > (The alternative of using #! to specify the shell to be used isn't > as reliable because any user can use "xyzsh scriptname" to run the > script using a different shell.) I wonder if it is worth noting that you can also use 'env printf' instead of '(exec printf)' to get the same PATH lookup properties of bypassing a shell builtin. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
