Not aligned columns with ls on xfce4-terminal when su / root

Other talk about Salix
Post Reply
westms
Posts: 298
Joined: 17. Mar 2013, 18:51

Not aligned columns with ls on xfce4-terminal when su / root

Post by westms »

For Salix64 Xfce 14.1:

As normal user on an xfce4-terminal (0.6.2), using e.g. pts/0,
or as normal user or as root user, both on e.g. tty2 (cntl+alt+F2),
an ls command, e.g. in directory /etc, produces a well-ordered output.

But on an xfce4-terminal (not a tty) with

Code: Select all

[etc]$ sudo ls
Passwort:
or

Code: Select all

[etc]$ sudo su
Passwort:
ls
or, first a change to pre-sudo behavior, then

Code: Select all

[etc]$ su
Passwort:
ls
The ls output is messed up. The columns are no longer displayed as aligned columns.

Why?
User avatar
gapan
Salix Wizard
Posts: 6238
Joined: 6. Jun 2009, 17:40

Re: Not aligned columns with ls on xfce4-terminal when su /

Post by gapan »

Have you changed anything with respect to the root user's settings in /root ?
Image
Image
westms
Posts: 298
Joined: 17. Mar 2013, 18:51

Re: Not aligned columns with ls on xfce4-terminal when su /

Post by westms »

gapan wrote:Have you changed anything with respect to the root user's settings in /root ?
I have not touched the home directory of user root itself. But I used "sudo passwd root" to enable the root user. Can not say how it was before.

Code: Select all

root[~]# ls -la
insgesamt 64
drwx------  6 root root 4096 Apr 15 23:24 .
drwxr-xr-x 22 root root 4096 Apr 16 22:03 ..
-rw-r--r--  1 root root  149 Mai 29  2011 .Xresources
-rw-------  1 root root  304 Apr 18 14:08 .bash_history
-rw-r--r--  1 root root   79 Jun 16  2009 .bashrc
drwxr-xr-x  4 root root 4096 Apr 15 23:49 .config
-rw-r--r--  1 root root  671 Sep  3  2009 .elvisrc
drwx------  2 root root 4096 Apr 15 22:27 .gnupg
-rw-r--r--  1 root root  104 Aug 14  2012 .gtkrc-2.0
drwxr-xr-x  2 root root 4096 Apr 15 22:26 .kbd
-rw-r--r--  1 root root 7650 Sep  3  2009 .nanorc
-rw-r--r--  1 root root  163 Mai 30  2009 .screenrc
drwxr-xr-x  3 root root 4096 Apr 15 00:17 .vim
-rw-r--r--  1 root root  621 Sep 28  2011 .vimrc
-rwxr-xr-x  1 root root 2610 Aug 14  2012 .xinitrc
root[~]# 
root[~]# ls -la .vim
insgesamt 12
drwxr-xr-x 3 root root 4096 Apr 15 00:17 .
drwx------ 6 root root 4096 Apr 15 23:24 ..
drwxr-xr-x 2 root root 4096 Apr 15 00:17 colors
root[~]# 
root[~]# ls -la .vim/colors/
insgesamt 12
drwxr-xr-x 2 root root 4096 Apr 15 00:17 .
drwxr-xr-x 3 root root 4096 Apr 15 00:17 ..
-rw-r--r-- 1 root root 1311 Sep  3  2009 xemacs.vim
root[~]# 
I have extended "/ etc/profile", as in all previous versions. The end of shell script is now:

Code: Select all

# For non-root users, add the user specific directory to the search path:
if [ ! "`id -u`" = "0" ]; then
 PATH="$PATH:~/bin"
fi
That is all.

Added:
The problem does not exist on a tty console (cntl+alt+Fx).
TracyTiger
Posts: 27
Joined: 5. Mar 2014, 02:28
Location: California, USA

LS_OPTIONS

Post by TracyTiger »

You may want to go back to basics and check what is actually executing.

which -a ls
alias
whereis ls


For me there is only 1 ls executable on the system the rest are symbolic links. But perhaps another ls file snuck onto your system. :)

There is an alias for ls however which uses the $LS_OPTIONS variable.


env | grep LS_OPTIONS

For me this shows a tab setting of 0 (-T 0). Perhaps it's different for root on your system.

LS_OPTIONS=-F -b -T 0 --color=auto

Remember that the environmental variables can vary greatly depending upon how you run a program as an other user. (e.g. "sudo su" versus "sudo su -")


EDIT: In bash "type ls" will show which ls command will execute, an alias or an executable file. "type -a ls" will show all possibilities. Other operating systems used to give you this information as part of the which command.

I wonder if it's possible for a setting in $LS_COLORS to cause this? This can be tested by clearing $LS_COLORS.
westms
Posts: 298
Joined: 17. Mar 2013, 18:51

Re: LS_OPTIONS

Post by westms »

TracyTiger wrote:You may want to go back to basics...
To be honest, no.
...check what is actually executing.
But for you I make an attempt.
which -a ls
alias
whereis ls


For me there is only 1 ls executable on the system the rest are symbolic links. But perhaps another ls file snuck onto your system. :)
Please note, my computers are not sluts, nor I am slovently, so nothing can creep in. I hope it's not something like Ebola. But I thank you for your worry. For your reassurance:

A normal user on an xfce4-terminal:

Code: Select all

westms[~]$ which ls
/usr/bin/ls
westms[~]$
westms[~]$ whereis ls
ls: /bin/ls /usr/bin/ls /usr/X11R6/bin/ls /usr/bin/X11/ls /usr/X11/bin/ls /usr/man/man1/ls.1.gz /usr/share/man/man1/ls.1.gz /usr/X11/man/man1/ls.1.gz
westms[~]$
westms[~]$ file /bin/ls /usr/bin/ls /usr/X11R6/bin/ls /usr/bin/X11/ls /usr/X11/bin/ls
/bin/ls:           ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped
/usr/bin/ls:       symbolic link to `../../bin/ls'
/usr/X11R6/bin/ls: symbolic link to `../../bin/ls'
/usr/bin/X11/ls:   symbolic link to `../../bin/ls'
/usr/X11/bin/ls:   symbolic link to `../../bin/ls'
westms[~]$
westms[~]$ alias
alias ap='apropos'
alias la='ls -al'
alias ll='ls -l'
alias ls='ls --color=auto'
alias sipa='publicip.rb -i'
westms[~]$
westms[~]$ env | grep LS_OPTIONS
LS_OPTIONS=-F -b -T 0 --color=auto
westms[~]$
User root on an xfce4-terminal:

Code: Select all

westms[~]$ su
Passwort:
root[westms]# cd
root[~]#
root[~]# which ls
/bin/ls
root[~]#
root[~]# whereis ls
ls: /bin/ls /usr/bin/ls /usr/X11R6/bin/ls /usr/bin/X11/ls /usr/X11/bin/ls /usr/man/man1/ls.1.gz /usr/share/man/man1/ls.1.gz /usr/X11/man/man1/ls.1.gz
root[~]#
root[~]# file /bin/ls /usr/bin/ls /usr/X11R6/bin/ls /usr/bin/X11/ls /usr/X11/bin/ls
/bin/ls:           ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped
/usr/bin/ls:       symbolic link to `../../bin/ls'
/usr/X11R6/bin/ls: symbolic link to `../../bin/ls'
/usr/bin/X11/ls:   symbolic link to `../../bin/ls'
/usr/X11/bin/ls:   symbolic link to `../../bin/ls'
root[~]# alias
root[~]#
root[~]# env | grep LS_OPTIONS
root[~]#
A good nose you have. No LS_OPTIONS for user root on an xfce4-terminal. But I did not remove it.

Code: Select all

root[~]# ls
and
root[~]# ls -C
Gives a bad output on an xfce4-terminal.

root[~]# ls --color=auto
Gives a correct output on an xfce4-terminal!

env | grep LS_OPTIONS (on a tty as root gives)
LS_OPTIONS=-F -b -T 0 --color=auto

ls -C on a tty gives a correct output.

ls -C on a tty from within a bash script gives a bad output.

(man ls says "-C list entries by columns")

The collected output on a tty from a bash script, owner root :

Code: Select all

which ls >>/tmp/on_a_tty.txt
/usr/bin/ls

whereis ls >>/tmp/on_a_tty.txt
ls: /bin/ls /usr/bin/ls /usr/X11R6/bin/ls /usr/bin/X11/ls /usr/X11/bin/ls /usr/man/man1/ls.1.gz /usr/share/man/man1/ls.1.gz /usr/X11/man/man1/ls.1.gz

file /bin/ls /usr/bin/ls /usr/X11R6/bin/ls /usr/bin/X11/ls /usr/X11/bin/ls >>/tmp/on_a_tty.txt
/bin/ls:           ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped
/usr/bin/ls:       symbolic link to `../../bin/ls'
/usr/X11R6/bin/ls: symbolic link to `../../bin/ls'
/usr/bin/X11/ls:   symbolic link to `../../bin/ls'
/usr/X11/bin/ls:   symbolic link to `../../bin/ls'

alias >>/tmp/on_a_tty.txt

env | grep LS_OPTIONS >>/tmp/on_a_tty.txt
LS_OPTIONS=-F -b -T 0 --color=auto

ls -C /etc >>/tmp/on_a_tty.txt
ConsoleKit		   group		  polkit-1
DIR_COLORS		   group-		  ppp
HOSTNAME		   gshadow		  printcap
ImageMagick-6		   gshadow-		  profile
UPower			   gtk-2.0		  profile.d
X11			   gtk-3.0		  protocols
a2ps-site.cfg		   hardwareclock	  radiusclient
[rest skiped]
The script itself::

Code: Select all

#/bin/bash
cd /etc >/tmp/on_a_tty.txt
printf "%s\n" 'which ls >>/tmp/on_a_tty.txt' >>/tmp/on_a_tty.txt
which ls >>/tmp/on_a_tty.txt
printf "%s\n" 'whereis ls >>/tmp/on_a_tty.txt' >>/tmp/on_a_tty.txt
whereis ls >>/tmp/on_a_tty.txt
printf "%s\n" 'file /bin/ls /usr/bin/ls /usr/X11R6/bin/ls /usr/bin/X11/ls /usr/X11/bin/ls >>/tmp/on_a_tty.txt' >>/tmp/on_a_tty.txt
file /bin/ls /usr/bin/ls /usr/X11R6/bin/ls /usr/bin/X11/ls /usr/X11/bin/ls >>/tmp/on_a_tty.txt
printf "%s\n" 'alias >>/tmp/on_a_tty.txt' >>/tmp/on_a_tty.txt
alias >>/tmp/on_a_tty.txt
printf "%s\n" 'env | grep LS_OPTIONS >>/tmp/on_a_tty.txt' >>/tmp/on_a_tty.txt
env | grep LS_OPTIONS >>/tmp/on_a_tty.txt
printf "%s\n" 'ls -C /etc >>/tmp/on_a_tty.txt' >>/tmp/on_a_tty.txt
ls -C /etc >>/tmp/on_a_tty.txt
There is an alias for ls however which uses the $LS_OPTIONS variable.


env | grep LS_OPTIONS

For me this shows a tab setting of 0 (-T 0). Perhaps it's different for root on your system.

LS_OPTIONS=-F -b -T 0 --color=auto

Remember that the environmental variables can vary greatly depending upon how you run a program as an other user. (e.g. "sudo su" versus "sudo su -")
Please look in the listings above.
EDIT: In bash "type ls" will show which ls command will execute, an alias or an executable file. "type -a ls" will show all possibilities. Other operating systems used to give you this information as part of the which command.
On an xfce4-terminal:

Code: Select all

root[etc]# type ls
ls is hashed (/bin/ls)
root[etc]# type -a ls
ls ist /bin/ls
ls ist /usr/bin/ls
root[etc]#
On a tty:

Code: Select all

# type ls
ls ist ein Alias von `/bin/ls $LS_OPTIONS'.
#
# type -a ls
ls ist ein Alias von `/bin/ls $LS_OPTIONS'.
ls ist /usr/bin/ls
ls ist /bin/ls
#
# env | grep LS_OPTIONS
LS_OPTIONS=-F -b -T 0 --color=auto
I wonder if it's possible for a setting in $LS_COLORS to cause this? This can be tested by clearing $LS_COLORS.
Correction:
I answerd with a wrong information. Correct is:
$LS_COLORS is always empty on an xfce4-terminal, whether a normal user or user root. $LS_COLORS is always filled with a long text string on a tty, whether a normal user or user root.

The bash login shell on a tty works different than the skipt computing bash on a tty and the bash login shell on a tty works different than the bash login shell on an xfce4-terminal.

Are your configuration files restored from a backup after a fresh installation on a clean disk? Are the configuration files new from the automatic installation and configuration work? Or did you install over an older installation? My configuration files are not from a backup. Its all Salix home made.

Added:
Meanwhile, I have gained the impression that it is related to the tab width. Command ls uses space characters to fill small gaps intervals between columns. It uses tabs and spaces if the free space is larger. Maybe ls uses a different tab width, than the termnals. From where ls gets the tab size to use?
TracyTiger
Posts: 27
Joined: 5. Mar 2014, 02:28
Location: California, USA

Re: LS_OPTIONS

Post by TracyTiger »

My mention of $LS_COLORS causing issues was a long shot in case it was possible to inject cursor positioning escape sequences. It was simple to test by clearing the variable. It's probably impossible for $LS_COLORS to cause your problem. I've never looked into this.
westms wrote: Are your configuration files restored from a backup after a fresh installation on a clean disk? Are the configuration files new from the automatic installation and configuration work? Or did you install over an older installation? My configuration files are not from a backup. Its all Salix home made.
I'm using a fresh default full Salix64 14.1 installation where I installed shotwell, gwenview, and possibly the codecs package. I haven't done any configuration changes. I don't actually use this particular system. It was built just in case a friend running Salix needed support over the telephone. I didn't import any configuration files. I didn't make any configuration changes.
westms wrote: Added:
Meanwhile, I have gained the impression that it is related to the tab width. Command ls uses space characters to fill small gaps intervals between columns. It uses tabs and spaces if the free space is larger. Maybe ls uses a different tab width, than the termnals. From where ls gets the tab size to use?
As I previously wrote, -T sets the tab stops. The man page for ls shows more information.
TracyTiger wrote:There is an alias for ls however which uses the $LS_OPTIONS variable.

env | grep LS_OPTIONS

For me this shows a tab setting of 0 (-T 0). Perhaps it's different for root on your system.

LS_OPTIONS=-F -b -T 0 --color=auto
Try executing this command ...

Code: Select all

(export LS_OPTIONS="-F -b -T 0"; /bin/ls $LS_OPTIONS -C /etc | head)
You should see the columns properly lined up.

Then change the tab setting from zero to a number such as fourteen.

Code: Select all

(export LS_OPTIONS="-F -b -T 14"; /bin/ls $LS_OPTIONS -C /etc | head)
You'll probably see the listing with skewed columns.

To get a better understanding of how the tab setting works you can try different values for the tab setting with different screen widths and different file name sizes.

You can ignore the $LS_OPTIONS and do it more simply with ...

Code: Select all

/bin/ls -T 14 -C /etc | head
You can execute the ls command as you showed previously then examine the resulting output to see how the tab (/t) characters and spaces are used to form the columns. It sounds like you may have already studied this.

Code: Select all

ls -C /etc >> /tmp/ls-output.txt
od -c /tmp/ls-output.txt | head
If your problem is simply the tab settings then a workaround to solve your problem may be to create an alias command, such as lsc that sets the tabs.

Code: Select all

alias lsc="/bin/ls -C -T 0 "
or for all ls uses ...

Code: Select all

alias ls="/bin/ls -T 0 "
Post Reply