bug#19218: Inconsistent spacing of output of "ls --full-time [file argument]"

[Michael Salem]

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