Maddening: ls -l output messed up

[Andrew Scott_3]

I have an issue on one of my HP-UX machines. when you do an ls -l (ll) on it, in any terminal, the blank space on either side of the group is ENORMOUS, and scales with the terminal width. This is extremely annoying. See attached screenshot.

I've been unable to find a difference between the environment variables and stty settings from the machine that is doing this and any of my other HP-UX machines.

How do I fix this?

[Pete Randall]

What do the executables look like?

$ ls -l /usr/bin/ll
-r-xr-xr-x 7 bin bin 28672 May 5 2003 /usr/bin/ll*
$ ls -l /usr/bin/ls
-r-xr-xr-x 7 bin bin 28672 May 5 2003 /usr/bin/ls*


Pete

[Andrew Scott_3]

In terms of permissions and sizes, exactly the same as my systems that do not exhibit this issue:

$ ls -l ls
-r-xr-xr-x 7 bin bin 77852 Feb 15 2007 ls
$ ls -l ll
-r-xr-xr-x 7 bin bin 77852 Feb 15 2007 ll

[Mel Burslan]

Can you see any difference(s) on the output of 'stty' command between a properly displaying system and this one ?

[Andrew Scott_3]

Zero difference in stty settings at all. I literally ran stty -a on two machine in two terminals with window transparency and laid them on top of each other. They're both exactly the same.

I've also messed with tabs, to no avail. It changes how far the cursor moves when I hit the tab key, but it doesn't affect the whitespace around the group column in ls output.

This is all under HP-UX 11.31, patched up to March '09, and using TERM set to xterm. The behavior exhibits in any terminal as well as the serial console. Root a normal users. I've even gone so far as to copy the /etc/profile from a properly working machine onto this one, with no change in behavior.

[Hein van den Heuvel]

Well,

man ls indicates /usr/share/lib/terminfo/?/* as a dependency.

It may take formatting information from there.
What is TERM set to?
Try setting it to VT100 or HPTERM?

If you use
# ls -l > test.txt
and then
# cat test.txt
does that look alright?

does # od -c on that test.txt show any hard tabs? ( \t = 011 )

Does your terminal emulator have a 'scope' or 'do-not-interpret-controls' mode? Try it!

Try settings tab stops with 'tabs' every 8 columns?

just some things I would try.
fwiw,
Hein

[Andrew Scott_3]

TERM is most often set to xterm, but the behavior exists if I change it to vt100 and hpterm.

piping the output to a text file and catting the text file shows the same massive gaps around the group field. loaded in vi with list set to show hidden characters shows none, the whitespace is literally just a bunch of spaces.

[Andrew Scott_3]

the od -c output looks like this:

*
0250560 7 2 1 2 8 F e b 1 5
0250600 2 0 0 7 u n t i c \n - r -
0250620 x r - x r - x 2 b i n
0250640
*

I really don't know how to read that.

[Andrew Scott_3]

Okay, read the od man page. Similar to setting list in vi.

No hard tabs anywhere in the output. The whitespace is just that, spaces.

[Hein van den Heuvel]

>> does # od -c on that test.txt show any hard tabs? ( \t = 011 )

That was a silly remark for a piped file.
But if you could log a telnet session...

how do other commands which show user/group behave?

For example:
# UNIX95= ps -o group,user,pid
# groups

Hein.

[Andrew Scott_3]

the UNIX95 output is spaced wide, just like ls:

$ UNIX95= ps -o group,user,pid
GROUP USER PID
users ascott 2293
users ascott 29308

The output of the groups command is normal:

$ groups
dba sys users

[Andrew Scott_3]

Didn't come out in the text paste, here's a screenshot.

[Hein van den Heuvel]

The dump looks good, not control characters other than \n for new-line.
Specifically no \t for tabs as yo confirmed with vi.

The forum formatting dropped the spaces, so the character dump output is not too useful, but your description was. It suggests NOT to looks at terminal settings to me.

# od -b
would give us the exact bytes, with the space problem, but your description already convinced me that the spaces are there.

Hein

[Andrew Scott_3]

Yes, od -b pukes out all the 040 codes for spaces.

0272400 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040 067
0272420 066 065 064 070 040 106 145 142 040 061 065 040 040 062 060 060
0272440 067 040 172 143 141 164 012 055 162 055 170 162 055 170 162 055
0272460 170 040 040 040 061 040 142 151 156 040 040 040 040 040 040 040
0272500 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040
*
0272560 040 040 040 040 040 040 040 142 151 156 040 040 040 040 040 040
0272600 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040
*
0272660 040 040 040 040 040 040 040 040 040 040 040 040 067 071 071 040
0272700 106 145 142 040 061 065 040 040 062 060 060 067 040 172 143 155
0272720 160 012 055 162 055 170 162 055 170 162 055 170 040 040 040 061
0272740 040 142 151 156 040 040 040 040 040 040 040 040 040 040 040 040
0272760 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040
*
0273040 040 040 142 151 156 040 040 040 040 040 040 040 040 040 040 040
0273060 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040
*
0273140 040 040 040 040 040 040 040 067 071 060 040 106 145 142 04

[Suraj K Sankari]

Hi,

All users are facing the same ?
If not then logout from the server and login again.

Suraj

[Andrew Scott_3]

Yes, this affects every user on the box, even root.

And yes, the power cord is plugged in. ;-)

[Hein van den Heuvel · Accepted solution]

I think that observing the same effect in ps and ls is critical. It absolves both, and points to the systems.

I suspect that the following paper holds the key (but I have not finished reading it)


http://docs.hp.com/en/5992-4118/longusername_white_paper_updated.pdf

Hein.

[Andrew Scott_3]

ps exhibits similar behavior.

[Andrew Scott_3]

Bingo!

lugadmin -d 8

That fixed it. Apparently whenever I enabled long user/group names, the default display length got set to something absurd. Odd I didn't see this kind of behavior on any other machines, as I've enabled long user/group names on everything I have.

Thanks for the point in the right direction!

[Dennis Handly]

>od -b pukes out all the 040 codes for spaces.

(You might want to use xd(1) and get it in hex. 0x20 for space)