Using ll to list files not working correctly

[Chris Fadrowski]

I have a number of 11.23 Itanium servers. ON all but 1 server using ll works correctly. on this particular server, when doing a long listing (ll), i don't get any dates or permissions. I just get file names. Can anyone tell me why this is happening?

i should get

drwxrwxrwx 2 root sys 96 May 12 2005 h16/

but i only get "h16"

[Pete Randall]

Chris,

Run the alias command to see if there are any aliases (aliai?) for ll.


Pete

[Chris Fadrowski]

not entirely sure what you mean, however it did work a few days ago, and no changes have been made to the system.

[HGN]

Hi

You can make sure by doing a ls -l ,the output is same as ll if that works then there might be some issue on the ll file,rename and ftp a similar file from another server and try.

Rgds

HGN

[Pete Randall]

Chris,

Example:

$ alias
autoload=typeset -fu
bdf=/usr/local/bin/bdfmegs
ls=ls -F
ll=ls

If you see "ll" in the output, there is an alias set for it which is preventing it from behaving normally. Use unset to get rid of the alias: "unset ll".


Pete

[Chris Fadrowski]

it shows up as

ll = ll -alf


i did the unset, but it still won't work properly. i may take it from another server.

[Mel Burslan]

what does

whereis ls tell you on a system which is working properly and one which is not ? Also, what are the file sizes and permissions of the first occurance of ls on the whereis output ?

A corruption is possible.

[Chris Fadrowski]

root@host:/>whereis ll
ll: /usr/bin/ll /usr/share/man/man1.Z/ll.1

root@host:/>whereis ls
ls: /sbin/ls /usr/bin/ls /usr/share/man/man1.Z/ls.1


output of ll

root@host:/>ll
.
..
lost+found
etc
stand
tmp
home
opt
usr
var
sbin
dev
net

.spc_disclaimer
.spc_trust_store
.sw
MANPATH
lib
bin
.profile
.ssh
u01
.dt
security_catalog
.dtprofile
.mozilla-license
.ICEauthority
.Xauthority
.mozilla
.TTauthority
depot
cdrom
sh_history
nsr
local100
.spc_trust_store.old

alias output

root@host:/>alias
autoload='typeset -fu'
command='command '
functions='typeset -f'
history='fc -l'
integer='typeset -i'
ll='ll -alf'
local=typeset
nohup='nohup '
r='fc -e -'
stop='kill -STOP'
suspend='kill -STOP $$'
type='whence -v'

[Pete Randall · Accepted solution]

Chris,

That's it exactly. The alias is messing it up. Try resetting the alias with "alias ll=ll".


Pete

[Mel Burslan]

or simply

unalias ll

[Pete Randall]

Sorry to continue in a separate response - I didn't follow my train of thought far enough.

After you re-alias ll, to permanently fix this, we need to find where it is being set so we can remove it. You can try a find command:

find /home /etc/profile -exec grep 'alias ll' {} \;

That should flush out the culprit.


Pete

[Chris Fadrowski]

thanks for all your help.. it turns out some one set .profile to

ll = ll -alf

should have been ll -alF

i found this with your help..

[Pete Randall]

Thanks, Mel - I could not seem to remember the unalias command!


Pete

[Bill Hassell]

Another quick test is to use the actul command rather than the shorthand name:

/usr/bin/ll

This bypasses all aliases since alias does an exact match (ll does not match /usr/bin/ll). Another way to investigate a malfunctioning command is to ask the shell:

type ll

Always use 'type' (which is an alias to whence -v) and forget about which and whereis to track down what the shell will do. type will expand aliases, report on built-ins, etc.

[Sorrel G. Jakins]

..but WHO changed .profile?

You need to restrict root password and use sudo.

Sorrel