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
