Re: Strange 'ls' listing
- From: Sam Sharpe <lists.redhat@xxxxxxxxxxxxx>
- Date: Wed, 7 Apr 2010 22:14:14 +0100
On 7 April 2010 21:55, Kwan Lowe <kwan@xxxxxxxxxxxxxxxxx> wrote:
On Wed, Apr 7, 2010 at 4:43 PM, Michael Cronenworth <mike@xxxxxxxxxx> wrote:
I believe you can generate your own formatted output to workaround it.
Sure, not intuitive, but possible. You can alias "ll" to your custom
:) Might do that...
I was interested because of the OP about the new behaviour breaking
some scripts. In one company I'd worked I had some complaints about
some perl scripts that had failed to work after an OpenSSH update.
"Eh?" I thought... Turns out that their script was counting characters
in the ls output and grabbing the file size. Something changed in the
output at one point (I think it was a change from a 5 char username to
a 6 char username (like admin to webadm) and a bunch of scripts broke.
Yeah, I know...
FWIW, I'm not convinced that this behaviour breaks or should break
anything. The reason I say that is because in the position where there
can now be a ".", I have for many years seen occurrences of "+" - and
I've never heard of that being a problem before (and I used to use
WinSCP at the time).
From "info coreutils 'ls invocation'":
Following the file mode bits is a single character that specifies
whether an alternate access method such as an access control list
applies to the file. When the character following the file mode
bits is a space, there is no alternate access method. When it is
a printing character, then there is such a method.
GNU `ls' uses a `.' character to indicate a file with an SELinux
security context, but no other alternate access method.
A file with any other combination of alternate access methods is
marked with a `+' character.
users mailing list
To unsubscribe or change subscription options:
- Prev by Date: RE: Strange 'ls' listing
- Next by Date: Re: FPL steps down: what's the real story?
- Previous by thread: Re: Strange 'ls' listing
- Next by thread: Re: Strange 'ls' listing