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

[Michael Salem]

Thanks for response to my bug report. I'm not familiar with this 
tracking system, and hope the response is organised right, threading 
appropriately without too much duplication or long-windedness (I 
won;t quote massively in detail). I reported an issue whereby several 
versions of ls all manifested what I describe as inappropriate 
behaviour when used with the --full-time option. This made ls 
inappropriate for my purpose, using cut to extract parts of the line.

I gave specific examples where ls --full-time gave different results 
on the same directory at the same time for different file arguments 
producing the same output line plus others (cp, cp*, c*, no 
argument). BTW, I don't actually have a problem to resolve any more, 
my report was simply for information (I have used stat, and finally 
ended up writing and compiling a simple program).

> Andreas Shcwab kindly suggested that ls is the wrong tool, 
recommending stat. That is absolutely right, and I had later been 
using stat (which happened not to be available to me originally, but 
I learnt about it later) after giving up on ls.

> Paul Eggert says "I don't see a bug in the cases you mention.  
First, 'ls' dynamically adjusts column widths to fit the data, and 
this is considered to be a feature.  Second, different platforms have 
different time stamp resolutions."

This clarifies matters for me, and I now agree insofar as one can't 
expect ls to produce the same output in all circumstances (though 
it's perhaps reasonable to expect it to be consistent ON THE SAME 
PLATFORM and using the same version, just needing small script 
changes if using "cut" to extract subtrings on different platforms).

However, I maintain that the behaviour I described, and repeat below, 
is bad enough to be called a bug. Whether it's considered worth 
correcting is another matter, which I won't push.

ls --full-time on the SAME file on the SAME directory at the SAME 
time (within a couple of minutes) produces differently-formatted 
output depending upon the file argument. The copied and pasted 
example I gave illustarted this.

I gave several examples in my original posting (which can be referred 
to if redundant examples are wanted), but one blatant one is enough, 
with ls 8.21, Linux Mint, /etc directory. In the following I've 
replaced each space by an underline; the output continaed no "real" 
underlines or tab characters. This is a particularly bad example, but 
many others produced output differing by one space between using a 
full filename or no argument. (In /etc try cp, no argumjent, c*.)

ls --full-time (with no argument) produces, amongst other lines:
-rw-r--r--__1_root____root______552_2014-01-31_22:19:46.000000000_+000
0_pam.conf

ls --full-time pam.conf produces:
-rw-r--r--_1_root_root_552_2014-01-31_22:19:46.000000000_+0000_pam.con
f

There is NO WAY that this is anything other than a bug. Maybe not 
worth fixing though?

I repeat, ls --full-time on the SAME file on the SAME directory at 
the SAME time on the SAME platform with the SAME ls version produces 
significantly differently-spaced output formats (the actual non-space 
content is identical, as expected)

Best wishes,
Michael Salem