DASH Shell discussions
 help / color / mirror / Atom feed
From: Jilles Tjoelker <jilles@stack.nl>
To: Jeroen van Dijke <jeroen@vandijke.net>
Cc: dash@vger.kernel.org
Subject: Re: Bug in man page
Date: Fri, 14 Mar 2014 13:09:19 +0100	[thread overview]
Message-ID: <20140314120919.GA5792@stack.nl> (raw)
In-Reply-To: <B9BC530A-2542-409D-AA48-2B9E3B7906A1@vandijke.net>

On Sun, Mar 09, 2014 at 12:11:43PM +0100, Jeroen van Dijke wrote:
> There seems to be a bug in the dash man page, at least in 0.5.7. It
> reads:

>             Precision:
>                     An optional period, `.', followed by an optional
> digit string giving a precision which specifies the number of digits
> to appear after the decimal point, for e and f formats, or the maximum
> number of *characters* to be printed from a string (b and s formats);
> if the digit string is missing, the precision is treated as zero;

> dash behaves cuts to the number of bytes

> $ length=10; printf "%.${length}s\n" "eeeeeeeeeeeeeeeeeeeeeeeee"
> eeeeeeeeee
> $ length=10; printf "%.${length}s\n" "ëëëëëëëëëëëëëëëëëëëëëëëëë”
> ëëëëë

> The  POSIX specification (2008) says:

> precision Gives the minimum number of digits to appear for the d, o,
> i, u, x, or X conversion specifiers (the field is padded with leading
> zeros), the number of digits to appear after the radix character for
> the e and f conversion specifiers, the maximum number of significant
> digits for the g conversion specifier; or the maximum number of
> *bytes* to be written from a string in the s conversion specifier. The
> precision shall take the form of a ( '.' ) followed by a decimal digit
> string; a null digit string is treated as zero.

> So it seems to me that “characters” should be changed to “bytes”.

Indeed, and the same applies to the field width. This behaviour may not
be the most useful, but it is standard and widely implemented.

Likewise, the sequences \num (in the format string) and \0num (in
arguments for %b) generate bytes, not characters.

On another note, the format string is said to be a "character string";
this may be a C'ism (meaning that it is not a wide character string).

Note that a "byte" in POSIX terminology is a "character" in C standard
terminology. I think the former is less ambiguous in general and should
be the preferred term in man pages where a unit of 8 bits is referred
to. A POSIX "character" may be more than one byte long.

-- 
Jilles Tjoelker

  reply	other threads:[~2014-03-14 12:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-09 11:11 Bug in man page Jeroen van Dijke
2014-03-14 12:09 ` Jilles Tjoelker [this message]
2014-09-26 14:17 ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140314120919.GA5792@stack.nl \
    --to=jilles@stack.nl \
    --cc=dash@vger.kernel.org \
    --cc=jeroen@vandijke.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox