[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19218: Inconsistent spacing of output of "ls --full-time [file argum
From: |
Michael Salem |
Subject: |
bug#19218: Inconsistent spacing of output of "ls --full-time [file argument]" |
Date: |
Sat, 29 Nov 2014 14:02:28 +0000 |
Summary: the output format of "ls --full-time" with a file argument
seems to be inconsistent (within the same version of ls) for
different arguments.
I have either a question, or a bug report. on ls. The question: is
the output of
ls --full-time
intended to be consistent within one version of ls?
I was trying to use it to extract file timestamps using "cut", and
was finding that for different file arguments the output was
different, and there was no unique way to extract the timestamp. This
always with the sane version of ls; different versions have
significantly different output spacing, which is just the way it is,
not a problem. If the answer is "the horizontal spacing is not
specified and not consistent", I express criticism, but say no more.
Otherwise, I have found what appears to be a consistent bug in
several versions of ls, both in Linux and three different versioned
Windows ports. In the first cases I tested there was an extra space
character in the output depending upon the file argument. I later
found, but did not investigate further, MAJOR differences in spacing
in output from the Linux 8.21 version (examples below, look for
pam.conf).
The problem manifests in the same way in "ls" in (GNU coreutils) 8.21
in Linux Mint, ls 4.4.231 from the UnxUtils Windows port; ls 5.3.0
from GnuWin32; and ls 4.5.287 for Windows from
https://u-tools.com/msls.asp. It is the no surprise that the
horizontal output spacing of DIFFERENT versions are different from
each other; but within EACH SINGLE version they all omit a space
before the file size for some, but not all, file arguments with the
--full-time option. (I first discovered the variability using "cut"
to process the output, finding that what worked for a full listing
didn't work in some other cases). I also found an example of much
worse variability in 8.21 Gnu. This last variability is so great that
I would say that the output from "ls --full-time" is essentially
randomly, unpredictably spaced, unsuitable for piping. Or have I
misunderstood something?
In all cases I invoked, for files in the working directory,
ls --full-time [file argument without path]
In Windows (with cut.exe in the working directory) I used file
arguments cut.exe, c*.exe *.exe, and no argument (all files). In
Linux I worked in the bin directory, and used file arguments cut, c*,
*, and no argument. With the more restrictive argument all the lines
of output had one less space before the file size. I don't know
exactly what happens; in Windows cut.exe, c*.exe came out one way,
*.exe, and no argument the other. At least in the Windows versions
there were no tab characters, only spaces; this isn't a tab spacing
issue. (I later found much worse in the Linux /etc directory, see
examples.)
Anyway, astonishing as it sounds, there may be a very long-standing
bug in something as basic as ls.
All examples given are generated by "ls --fulltime [argument] >
report" and copied and pasted, not hand-copied; they contained no tab
characters.
SAMPLES OF INCONSISTENT OUTPUT FROM ls --full-time
--------------------------------------------------
(Lines contain no unexpected hard breaks; visibly broken lines are
due to viewer and transmission issues.)
MS Windows
----------
ls 5.3.0
ls --full-time (with no argument; same for ls --full-time *.exe)
...
-rw-rw-rw- 1 Michael 0 0 2014-11-29 12:28:00.000000000 +0000
cccc.txt
-rwxrwxrwx 1 Michael 0 17920 2003-06-20 16:57:42.000000000 +0100
cut.exe
...
ls --full-time cut.exe (same for c*.exe)
-rwxrwxrwx 1 Michael 0 17920 2003-06-20 16:57:42.000000000 +0100
cut.exe
ls 4.4.231 and 4.5.287
ls --full-time (with no argument; same layout for ls --full-time
*.exe)
-rw-rw-rwa 1 Everyone 0 2014-11-29 12:28:00 cccc.txt
-rwxrwxrwa 1 Everyone 17920 2003-06-20 16:57:42 cut.exe
ls --full-time cut.exe (same for c*.exe)
-rwxrwxrwa 1 Everyone 17920 2003-06-20 16:57:42 cut.exe
Linux Mint, ls 8.21
----------
/bin directory
...
-rwxr-xr-x 1 root root 124932 2014-03-24 07:37:58.000000000 +0000 cp
-rwxr-xr-x 1 root root 138900 2013-06-02 13:07:47.000000000 +0100
cpio
...
ls --full-time cp (same layout with c*)
...
-rwxr-xr-x 1 root root 124932 2014-03-24 07:37:58.000000000 +0000 cp
-rwxr-xr-x 1 root root 138900 2013-06-02 13:07:47.000000000 +0100
cpio
...
/etc directory - MASSIVE variability found here. The output contained
no tab characters - this is not an issue of tab expansion
ls --full-time (with no argument)
...
-rw-r--r-- 1 root root 249 2014-07-22 16:34:41.000000000
+0100 os-release
-rw-r--r-- 1 root root 552 2014-01-31 22:19:46.000000000
+0000 pam.conf
...
ls --full-time pam.conf
-rw-r--r-- 1 root root 552 2014-01-31 22:19:46.000000000 +0000
pam.conf
In case the spacing gets messed up by the display software, I append
four lines, repeated from the Linux examples, with spaces globally
replaced by
underlines. i consider that the first two should be identical to each
other, as
should the last two.
-rwxr-xr-x_1_root_root__124932_2014-03-24_07:37:58.000000000_+0000_cp
-rwxr-xr-x_1_root_root_124932_2014-03-24_07:37:58.000000000_+0000_cp
-rw-r--r--__1_root____root______552_2014-01-31_22:19:46.000000000_+000
0_pam.conf
-rw-r--r--_1_root_root_552_2014-01-31_22:19:46.000000000_+0000_pam.con
f
I don't know how communication is handled; this email is sent with a
legitimate email address, hopefully not for publication. I'm not
subscribed to the list, but mail will also reach me for the time
being at the temporary address address@hidden Text is not ideal
and lines break, but I don't know if attaching a file is supported.
Best wishes, Michael Salem
- bug#19218: Inconsistent spacing of output of "ls --full-time [file argument]",
Michael Salem <=