Meaning of hash mark in long listing?

[Ralph Grothe]

Hi,

this really is daft.

I get inexplicable hash marks (i.e. '#') in the 3rd field of a long listing.
Having thought this is yet another unknown (to me) feature of ls, I consulted the ls and ll manpages but haven't found a single occurence of the pattern '#', nor any explanation for it.
Is (hopefully not) the filesystem maybe screwed up so that the stat syscalls output an additional field with some memory garbage?
Has anyone a eplanation?

# ll /usr/local
total 6
drwxr-xr-x 2 # bin bin 3072 Jun 18 08:40 bin
drwxr-xr-x 2 # bin bin 96 Jun 18 10:26 etc
drwxr-xr-x 2 # bin bin 96 Jun 6 09:52 games
drwxr-xr-x 2 # bin bin 96 Jun 6 09:52 lib
drwxr-xr-x 2 # bin bin 96 Jun 6 09:33 man

[Michael Tully]

Hi,

Does this appear on any other system?
Do you have any starnge aliases in use?

You not using a different 'ls' command like 'super ls' ?

Michael

[Olav Baadsvik]

Hi,

Check if you have a private ll in your
search-path or an alias with the name
ll

Or you could also try to see if you get
the same output using these commands:

/usr/bin/ll
/usr/bin/ls -l

Regards
olav

[Andreas Voss]

Hi,

i've never seen this before.
Try /sbin/ls -l /usr/local

Regards

[Ralph Grothe]

This is strange, isn't it?

I cannot find any set alii or function definitions, neither for ll nor ls.

The output remains the same even when I invoke the commands using the absolute path (i.e. not evaluating PATH):

# type ll
ll is /usr/bin/ll
# type ls
ls is a tracked alias for /usr/bin/ls
# alias ls
ls: shell alias not found.
# typeset -f ll
# /usr/bin/ll /usr/local
total 6
drwxr-xr-x 2 # bin bin 3072 Jun 18 08:40 bin
drwxr-xr-x 2 # bin bin 96 Jun 18 10:26 etc
drwxr-xr-x 2 # bin bin 96 Jun 6 09:52 games
drwxr-xr-x 2 # bin bin 96 Jun 6 09:52 lib
drwxr-xr-x 2 # bin bin 96 Jun 6 09:33 man
# /usr/bin/ls -l /usr/local
total 6
drwxr-xr-x 2 # bin bin 3072 Jun 18 08:40 bin
drwxr-xr-x 2 # bin bin 96 Jun 18 10:26 etc
drwxr-xr-x 2 # bin bin 96 Jun 6 09:52 games
drwxr-xr-x 2 # bin bin 96 Jun 6 09:52 lib
drwxr-xr-x 2 # bin bin 96 Jun 6 09:33 man
# /sbin/ll /usr/local
sh: /sbin/ll: not found.
# /sbin/ls -l /usr/local
total 6
drwxr-xr-x 2 # bin bin 3072 Jun 18 08:40 bin
drwxr-xr-x 2 # bin bin 96 Jun 18 10:26 etc
drwxr-xr-x 2 # bin bin 96 Jun 6 09:52 games
drwxr-xr-x 2 # bin bin 96 Jun 6 09:52 lib
drwxr-xr-x 2 # bin bin 96 Jun 6 09:33 man

[Ralph Grothe]

The culprit seems to be a user account "# bin" %-{
Dunno, how this could sneak in

# id bin
uid=2(# bin) gid=2(bin)

But can I do a "userdel '# bin'"?

[Ralph Grothe]

Oops, got it
Someone screwed up the /etc/passwd,
see
# grep ^#\ bin /etc/passwd
# bin:*:2:2::/usr/bin:/sbin/sh

but luckily this entry also exists:
# grep ^bin /etc/passwd
bin:*:2:2::/usr/bin:/sbin/sh

So I will vipw, remove "# bin" and chown files belonging to "# bin" to now belong to bin.

Sorry, for confusing you

[Peter Kloetgen]

Hi Ralph,

no, don't delete user bin! But you can change the username with usermod- command to fix your problem.

Allways stay on the bright side of life!

Peter

[Ralph Grothe]

Hi Peter,

I searched the filsystems for files belonging to "# bin".
Argh, my worst fears seem come true.
As it looks almost every file normally belonging to bin has the screwed ownership:

# find / -user '# bin' |tee ~/files_of_#_bin.lst
# wc -l ~/files_of_#_bin.lst
33845 /ROOT/files_of_#_bin.lst

This must have happened when colleagues converted from HP-UX 10.20 to 11.00 while I was on holiday.
Don't know what on earth made them comment lines in /etc/passwd?

Can I reassign ownerships by doing simply this, or would do even more harm?

find / -user '# bin' -exec chown bin {} \;

[Peter Kloetgen · Accepted solution]

Hi Ralph,

i thought this over a little bit, you should use SAM, delete the user "# bin" and use the option "assign data to a new user", and give all data from your corrupt user to correct user bin. This should do it for you.

Your find- command seems also to be ok. If you use it, don't forget to delete the "# bin"- user after it.

Allways stay on the bright side of life!

Peter

[Ralph Grothe]

Sigh,
relieved, the find chown and userdel worked.
now everything looks as usually. :-)

[Olav Baadsvik]

Hi,

Interesting case!!
Even though the problem seems to be solved
I have a comment.

I think it could would be ok just to
delete the line for the # bin user in
/etc/passwd
This because the UID was the same (2)
for both user bin and # bin
What is stored in the file's inode is the
UID not the name # bin or bin.
So when a ll is produced /etc/passwd is
searched for the UID 2 and the username
assosiated with UID 2 is then used in the
output. I would guess that # bin was in front
of bin in /etc/passwd

Regards

[Pete Randall]

Olav has hit it right on the head - all you needed to do was remove the offending entry from /etc/passwd and everything would have been fine.

For What It's Worth,
Pete

[Ralph Grothe]

Olaf, Pete,

you were right both, of course.

This was just my foolish bad intuition to have chmoded through find, which as you stressed, was silly.
Afterwards I also saw that simply the deletion of the commented lines from /etc/passwd would have sufficed since both *bin accounts had the same ID.
Thus the find rather was a waste of energy.
But when the result is right (just like the outcome of the world cup semi-final for Germany, as I heard right now) who cares for style ;-)