bug-coreutils
[Top][All Lists]
Advanced

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

Re: Inaccurate/incorrect description of the -b option in man ls(1)


From: Jim Meyering
Subject: Re: Inaccurate/incorrect description of the -b option in man ls(1)
Date: Thu, 18 Mar 2010 09:34:47 +0100

address@hidden wrote:
> In the manpage for ls(1), the description of the -b option says,
> "print octal escapes for nongraphic characters"; this description is
> inconsistent with its actual function.  An update to either the
> description or behaviour of the -b option is required.
...
> $ touch $'a\nb'; ls -b $'a\nb'
> a\nb
>
> In accordance with the description of the -b option, the output should
> instead be:
> a\012b
>
> Side Note:
> ----------
> - HP-UX's ls(1) indeed prints octal escapes with -b option specified.
>
> - After checking with the (latest) IEEE 1003.1-2008 standard (POSIX),
> the -b option is not specified for ls(1).

Thank you for the report.
The /bin/ls from Solaris 10 and Irix 6.5 work the same way:

    $ touch $'a\nb'; /bin/ls -b $'a\nb'; rm $'a\nb'
    a\012b

However, the one from MacOS (darwin 9.8.0) agrees with GNU ls:

    $ touch $'a\nb'; /bin/ls -b $'a\nb'; rm $'a\nb'
    a\nb

Note that the authoritative documentation for GNU ls is not the
man page (which is merely the massaged output of ls --help)
but rather the info doc, i.e., what you get when you run
"info coreutils ls".  Its "Formatting the file names" section says this:

    `-b'
    `--escape'
    `--quoting-style=escape'
         Quote nongraphic characters in file names using alphabetic and
         octal backslash sequences like those used in C.

which is consistent with GNU ls's behavior.

Considering the length of time GNU ls has exhibited this
behavior and the size of the install base (compared to those
for Solaris/HP-UX), I'm inclined to leave the behavior as-is,
even though it differs from that of some other systems.

Seeing as how ls --help output is already so long (in spite of
conciseness constraints), I'm not sure this is worth a change there.
However, assuming we stick with the status quo, it does seem worthwhile
to mention this option's portability problem in doc/coreutils.texi.
Would you like to contribute the patch?
If so, here are some instructions:

  http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING




reply via email to

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