Bug 695637

Summary: tcsh / coreutils ls time format changed or wrong
Product: [openSUSE] openSUSE 12.1 Reporter: Volker Kuhlmann <bugz57>
Component: BasesystemAssignee: E-mail List <bnc-team-screening>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P4 - Low CC: bugz57, markgray+to-suse, pth
Version: Factory   
Target Milestone: RC 1   
Hardware: Other   
OS: openSUSE 11.4   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Volker Kuhlmann 2011-05-24 10:28:10 UTC 
User-Agent:       Mozilla/5.0 (compatible; Konqueror/4.6; Linux) KHTML/4.6.0 (like Gecko) SUSE

There are some strange things happening with time formats displayed by ls. It seems to be shell dependent too. It's definitely different from oS 11.1.

Old behaviour under oS 11.1 tcsh:

> echo "$LS_OPTIONS" ; echo "$TIME_STYLE" 
-N --color=never -T 0
TIME_STYLE: Undefined variable.
> ls -l file
-rw------- 1 user user 0 2011-05-24 22:03 file
> /bin/ls -l file
-rw------- 1 user user 0 2011-05-24 22:03 file

The default was long-iso, for both built-in and coreutils ls.


oS 11.4 tcsh:

> echo "$LS_OPTIONS" ; echo "$TIME_STYLE" 
-N --color=always -T 0 --time-style=long-iso
TIME_STYLE: Undefined variable.
> ls -l file
-rw------- 1 user user 0 May 24 22:00 file
> /bin/ls -l file 
-rw------- 1 user user 0 May 24 22:00 file

Ok the default changed.
Let's set a new default:

> echo "$LS_OPTIONS" ; echo "$TIME_STYLE"
-N --color=always -T 0 --time-style=long-iso
TIME_STYLE: Undefined variable.
> ls -l file
-rw------- 1 user user 0 May 24 22:00 file
> /bin/ls -l file
-rw------- 1 user user 0 May 24 22:00 file

Oops. The documentation promises --time-style to work.

> ls $LS_OPTIONS -l file 
-rw------- 1 user user 0 2011-05-24 22:00 file
> /bin/ls $LS_OPTIONS -l file
-rw------- 1 user user 0 2011-05-24 22:00 file

Explicitly on the command line it works, but not from LS_OPTIONS. That's a bug.

> echo "$LS_OPTIONS" ; echo "$TIME_STYLE"
-N --color=always -T 0 --time-style=full-iso
long-iso
> ls -l file
-rw------- 1 user user 0 2011-05-24 22:00 file
> /bin/ls -l file
-rw------- 1 user user 0 2011-05-24 22:00 file

So TIME_STYLE takes priority over LS_OPTIONS.
How annoying, but someone may have intended that.
But ls and /bin/ls only consider the time style in TIME_STYLE and ignore the
setting in LS_OPTIONS. That's a bug.

man ls doesn't even mention TIME_STYLE; guess it's incomplete.

info ls is quite clear, and that's how things should be.
That means /bin/ls and tcsh builtin ls are both buggy.

The following is inside bash -l:

> echo "$LS_OPTIONS"; echo "$TIME_STYLE"
-N --color=tty -T 0
long-iso
> ls -l file 
-rw------- 1 user user 0 2011-05-24 22:00 file
> /bin/ls -l file 
-rw------- 1 user user 0 2011-05-24 22:00 file

Ohoh: bash still behaves like it used to.

> echo "$LS_OPTIONS"; echo "$TIME_STYLE"
-N --color=tty -T 0 --time-style=full-iso
long-iso
> ls -l file 
-rw------- 1 user user 0 2011-05-24 22:00:05.000000000 +1200 file
> /bin/ls -l file 
-rw------- 1 user user 0 2011-05-24 22:00 file

bash built-in gives expected output, as does /bin/ls.

> echo "$LS_OPTIONS"; echo "$TIME_STYLE"
-N --color=tty -T 0 --time-style=full-iso

> ls -l file 
-rw------- 1 user user 0 2011-05-24 22:00:05.000000000 +1200 file
> /bin/ls -l file 
-rw------- 1 user user 0 May 24 22:00 file

bash built-in is correct.
/bin/ls is buggy.

--> /bin/ls coreutils changed and is now buggy.

I suspect tcsh doesn't have a built-in for ls and uses /bin/ls instead.

Is this a suse or upstream bug in coreutils?


Reproducible: Always

Steps to Reproduce:
See above



I have some vague memories of having had a similar problem with ls in a suse
release some years ago.
Comment 1 Mark Gray 2011-05-24 11:13:24 UTC 
This effects the gnu-emacs dired display as well, and since I have gotten quite used to the benefits of long-iso over the years I find the change to the absurd posix date display to be most unwelcome.
Comment 3 Philipp Thomas 2011-10-19 15:26:25 UTC 
The reason is that the coreutils don't know LS_OPTIONS. This is set by /etc/profile.d/ls.{bash|tcsh} and then used in the aliases for ls. So to have changes to LS_OPTIONS be applied you need to either login anew or source one of those files.

For the next version of openSUSE it might be a good idea to define the alias as

alias='ls $LS_OPTIONS'

then changes to LS_OPTIONS would immediately be effective. What do you think?
Comment 4 Volker Kuhlmann 2011-10-20 10:19:47 UTC 
Thanks Philip. If that's the reason dunno how I missed that. Sure nothing has changed in the coreutils package between May and now, other than the default format for ls? I ended up setting TIME_STYLE instead.

Your suggestion is good, there is not much point in having LS_OPTIONS if it isn't evaluated once the shell has started up. I use something like this

alias d  'ls -lF $LS_OPTIONS \!*'

With bash I found that aliases are not really useful, but functions do the same thing well:

d() { ls -lF $LS_OPTIONS "$@"; }

I would not alias ls itself, but do this with the dir, ll, l etc. that's always been in the shell rc files.
Comment 5 Philipp Thomas 2011-10-21 11:13:34 UTC 
That's what ls.bash has now:

    case "$is" in
        bash) alias ls='ls $LS_OPTIONS'      ;;
        zsh)  alias ls='\ls $=LS_OPTIONS'    ;;
        *)    alias ls='/bin/ls $LS_OPTIONS' ;;
    esac
    alias dir='ls -l'
    alias ll='ls -l' 
    alias la='ls -la'
    alias l='ls -alF'
    alias ls-l='ls -l'


I'll turn those into functions. ANd as this is something for 12.1 I'm moving the bug there.
Comment 6 Philipp Thomas 2011-10-21 11:43:52 UTC 
OK, the alias for ls can't be changed to a shell function as you'll then get recursion. I have changed the others so.

BTW, as you see, the alias for ls is ls='ls $LS_OPTIONS', so LS_OPTIONS are evaluated every time you call ls or one of its other aliases.