Different: man "stdin: not in compressed format"

[David Torres_4]

Hi,

I've been sporadically getting this message when I do a 'man' on various commands. I've searched the KDB and found the solution for the usual issue, but not mine.

Here's what happens -

man bdf # works fine

man bdf # I get the "stdin: not in compressed format" message.

rm'ing the cat1.Z file fixes it for one iteration.

After beating my head on the keyboard for a few hours, I finally noticed that everytime I run the 'man' command, the title bar on my hpterm was changing to '/usr/share/man'. A little further investigation showed that the compressed bdf man page had hpterm escape sequences imbedded in the very beginning of the file.

I have the 'cd' command aliased to a function that changes my title bar, so that leads me to the conclusion that the 'man' command cd's to /usr/share/man and is using my aliased 'cd'. Obvious right?

Not so obvious is how to get it to stop.

I created a simple 'man' script that unaliases 'cd' and that fixes the "stdin: not in compressed format" error, but man is still changing my title bar to /usr/share/man.

Does anyone have any ideas on how I can fix this? I'm tapped.

Thanks,

Dave

[Sundar_7]

I never happened to deal with this problem.

You can try this

# cp -pr /usr/share/man /tmp/man
# cd /usr/share/man
# rm -rf cat*
# catman &

Wait for catman to complete

now try man

[Sundar_7]

I assume catman did nt help ?

[David Torres_4]

It circumvented the "stdin: not in compressed format" issue which I had already resolved.

But I still have the issue of 'man' using my aliased 'cd' and changing my hpterm window.

In retrospect, maybe I should have titled this thread differently. I went with this one because I seem to have discovered a different angle to a problem that crops up now and again and I thought it would show up in searches better this way.

If anyone knows how to change it , I will gladly do so.

Thanks for your help,

Dave

[Dave Olker]

Hi Dave,

I really don't think the man command changes directories while running, and even if it did it wouldn't use a shell command to do it - it would use chdir(2) or fchdir(2) to do this programmatically.

Just to be sure, I ran tusc against the man command on my system and checked the tusc output. I saw no calls to chdir, getcwd, "cd", or any other call to change the current working directory.

In addition, I too have "cd" aliased to a function that updates my hpterm window with the current working directory and my terminal doesn't change when I use the man command.

The only thing I can surmise is that somehow the "man" command on your system is executing an alias, function, script, or some other program that is causing the "cd" to be entered.

If you type "which man" do you get:

# which man
/usr/bin/man

If you do, check the what(1) string of the /usr/bin/man binary and the cksum value and compare this against another system that doesn't show this problem to ensure that you're using a good copy of the man binary.

Other than that, I'd say check your environment for an alias, function, script, or binary called "man" that causes the "cd" alias to be called.

You might also try logging out and logging in again to see if something is messed up with your specific shell session that could get reset by logging out and logging back in.

I'd also be curious of the same behavior happens when other users on the system, like root, run the man command.

Regards,

Dave

[Kent Ostby]

Dave -- The issue here is that some files in the man directories are NOT compressed and catman is expecting them to be compressed.

Here is a document that deals with the issue. It's for 10.20 and before but the cause of your problems is likely the same.

http://www2.itrc.hp.com/service/cki/search.do?category=c0&mode=id&searchString=W3704717+&searchCrit=allwords&docType=EngineerNotes&search.x=22&search.y=8

Best regards,

Kent M. Ostby

[David Torres_4]

Hi Dave, thanks for the reply.

>which man

/usr/bin/man


>what /usr/bin/man

$Revision: B.11.11_LR
Fri Oct 27 00:58:14 PDT 2000 $


It happenes for regular users and SU accounts alike.

It's definitely something in my personal shell environment because the one root login that didn't show the problem, started right after I sourced my personal .profile.

I think I'll download tusc and see if I an get any answers. Thanks for the tip.

For those following along, there's really 2 issues here.

1. The changing of my hpterm title bar (which is really just an annoyance)

2. The corruption of the compressed man page.

I'll post back when I get some answers.

Thanks again Dave.

Great book BTW. I should have brought my copy over to get it autographed before HP gave me my walking papers. :-)

[Sundar_7]

Instead of "what man", I would use "whence -v".

Even if you have an alias to man, what will only search the PATH and will return you the location.

# whence -v man

It is possible that man itself is aliased to somethign else.

I can confirm man doesnt cd to the directory.

[David Torres_4]

OK, thanks to 'tusc' I have a lot more information -

First off, 'whence -v man' returns /bin/man and /bin is a link to /usr/bin so the executable is the same.

Second, 'man' executes 'chdir' a few times, but that's not where the problem is.

man, either directly or indirectly, exec's several /usr/bin/sh's and actually opens my personal .kshrc file.

In my .kshrc, when I define the new 'cd' function, I actually execute it to reset my window title bar when I first login. Once I commented out that line, both problems went away.

OK, I've got the work around, but I have a problem with 'man' (or an exec'd sh) needing to read my .kshrc. It should be able to get anything it needs from my current ENV settings. Is this a bug in 'man'? Or just my mis-use/understanding of how everything is supposed to work?

Thanks for everyone's help,

Dave

[Ermin Borovac · Accepted solution]

You probably have environment variable ENV set to $HOME/.kshrc. This will cause all subshells to source .kshrc.

The following changes to your environment will make .kshrc be executed only for interactive shells (this will probably make your problem go away).

ENV='${START[ (_$- = 1) + (_ = 0) - (_$- != _${-%%*i*}) ]}'
START=~/.kshrc
export ENV START

[David Torres_4]

Thanks. You are correct, my ENV was set to my .kshrc. That probably explains why I haven't really run into this problem before.
I'm in a new environment now and I probably had my old ENV set properly.

This also gives me a clue to some other unrelated issues I've been having.

But, does anyone else besides me think it's a bad idea for spawned shell processes to automatically source environment files? It would seem to me that anything a shell would need is already in global environment variables.

I guess I find it ironic that CDE hpterm sessions, by default do not source your .profile. The one place where it's a safe assumption that you would want it.

Go figure...

Anyways, thanks everyone,

Dave

[Dave Olker]

Hi Dave,

One other thing to try if you want to change the behavior of the hpterm itself, and possibly those processes that get spawned from that process, is to try experimenting with the "+ls" and "-ls" hpterm options. These control the "loginShell" behavior of hpterm. Perhaps one of these options will also do what you're looking for.

Regards,

Dave