Project

General

Profile

Actions

Bug #12558

closed

Builtin command "printf" of ksh93 does not behave as specified

Added by Hubert Garavel over 1 year ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
cmd - userland programs
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Bite-size
Tags:
Gerrit CR:

Description

After opening a shell "/bin/sh" (i.e., ksh93) and typing the following command

    printf "-e" 

one gets an error message:
   ksh: printf: -e: unknown option
   usage: printf [option] ...

This violates the specifications given on the "printf" manual page in many respects:

  • According to its manual page, the first argument of printf (both /usr/bin/printf and ksh93's
    builtin printf) is always a format string. So, the argument "-e" is a format string ans should
    be displayed as such. Instead, ksh93's builtin printf tries to interpret this format string as
    a command-line option, which is incorrect.
  • Quoting the manual page: "/usr/bin/printf is equivalent to ksh93's printf built-in and print -f,
    which which allows additional options to be specified." So, ksh93's printf should behave
    like /usr/bin/printf, which displays "-e" (without newline) when invoked with argument "-e".

Because the implementation and the manual page differ, one may wonder which one is
incorrect. I think that the implementation is incorrect, because the manual page states
very clearly, at different places and in different ways, what is expected from the implementation.

Note 1: it is likely that, in ksh93 implementation, there is a confusion between "printf" and "print".
The latter accepts options, including an option "-e". It could be that "printf" tries to share
code with "print", including code to parse options, whereas "printf" should not parse any
option since its first argument is directly a format string.

Note 2: This bug also exists in Solaris 11.4, which seems to indicate that it was introduced
during the Sun times.


Related issues

Related to illumos gate - Bug #13661: printf builtin should ignore leading --ClosedAndy Fiddaman

Actions
Actions #1

Updated by Electric Monk 7 months ago

  • Gerrit CR set to 1316
Actions #2

Updated by Andy Fiddaman 7 months ago

  • Category set to cmd - userland programs
  • Status changed from New to In Progress
  • Assignee set to Andy Fiddaman
  • Difficulty changed from Medium to Bite-size
  • Gerrit CR deleted (1316)

This is indeed because of shared code between print and printf.
Although the printf command is correctly declared internally as accepting no arguments apart from the standard ksh builtin --man etc., it goes through the option parser.

To fit with expected behaviour, the man page and the /usr/bin/printf variant, not even those builtins should be recognised.
Option processing should be completely skipped for the printf builtin.

Actions #3

Updated by Andy Fiddaman 7 months ago

  • Gerrit CR set to 1316
Actions #4

Updated by Andy Fiddaman 7 months ago

I've tested the proposed change by running a variety of parameters through both the ksh93 builtin and /usr/bin/printf.
The ksh builtin is no longer treating a leading - as special for printf.

I ran the ksh testsuite builtins.ksh and the results are unchanged from before this change. The only failing test there is around
the %T format, which is down to the fact that a different timezone is printed versus the system date command (and the test compares the two)

af@bloody:~$ printf %T now
Mon Mar  8 14:38:28 GMT 2021
af@bloody:~$ date
Mon Mar  8 14:38:29 UTC 2021
Actions #5

Updated by Jens Elkner 6 months ago

ksh is correct: GMT is a timezone, UTC is a standard.

Actions #6

Updated by Yuri Pankov 6 months ago

Jens Elkner wrote in #note-5:

ksh is correct: GMT is a timezone, UTC is a standard.

It isn't, UTC is valid timezone, at least in our current zoneinfo:

$ ll /usr/share/lib/zoneinfo/UTC
     10364 -rw-r--r--   8 root     bin           56 Mar  5 22:49 /usr/share/lib/zoneinfo/UTC

BTW, the behavior here changed with ksh update, previously it would not print TZ at all:

$ TZ=UTC ksh -c 'printf %T now'
Sat Mar 13 12:19:20  2021

Actions #7

Updated by Andy Fiddaman 6 months ago

The note about the test failure was just for the person who has to approve this change - the test failure is easily explained and can be ignored in the context of this change.

The previous version of ksh was printing the timezone for me:

af@build:.../illumos/usr/src/uts/common/os$ printf %T now
Sat Mar 13 14:04:21 GMT 2021
af@build:.../illumos/usr/src/uts/common/os$ TZ=UTC printf %T now
Sat Mar 13 14:05:49 GMT 2021
af@build:.../illumos/usr/src/uts/common/os$ echo ${KSH_VERSION}
Version JM 93t+ 2010-03-05

Actions #8

Updated by Jens Elkner 6 months ago

And fixing the test is not an option?

Actions #9

Updated by Andy Fiddaman 6 months ago

Jens Elkner wrote in #note-8:

And fixing the test is not an option?

Definitely, but not part of this change.
I have a few tests I want to get fixed but I'm waiting until after #2755 and #13488 and the other ksh fixes I have ready are all done.

Actions #10

Updated by Electric Monk 6 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit f9bbf53b825c087ef99dd9b3e51570ec68a51463

commit  f9bbf53b825c087ef99dd9b3e51570ec68a51463
Author: Andy Fiddaman <omnios@citrus-it.co.uk>
Date:   2021-03-16T15:25:21.000Z

    12558 Builtin command "printf" of ksh93 does not behave as specified
    Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
    Reviewed by: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
    Approved by: Dan McDonald <danmcd@joyent.com>

Actions #11

Updated by Andy Fiddaman 6 months ago

  • Related to Bug #13661: printf builtin should ignore leading -- added
Actions

Also available in: Atom PDF