Opened 10 years ago

Closed 9 years ago

#13444 closed defect (fixed)

In Leopard man page for 'port' is missing or not accessable

Reported by: dergaspode@… Owned by: jmpp@…
Priority: Normal Milestone: MacPorts 1.7.1
Component: base Version: 1.6.0
Keywords: man Cc: jokkel@…, ryandesign (Ryan Schmidt)
Port:

Description

I did a clean install of Leopard, the migrated my Users. Just to be sure I deleted MacPorts as documented in the FAQ. I then did a new MacPorts install using the downloadable .dmg.

Everything worked fine, the installation and then downloading packages like teTex.

But the man page for port cannot be displayed. Error message


Cannot open the message catalog "man" for locale "de_DE.UTF-8" (NLSPATH="<none>")

No manual entry for port


I receive the same error message with every other man page that is not available so the strange error message is propably because of Leopard having problems with other languages then English. But still there should be a man page for port.

Displaying other man pages that are available works.

I have an Intel Mac and I am now on 10.5.1. My login shell is tcsh. Other people veryfied that they have the same problem.

Change History (16)

comment:1 Changed 10 years ago by jmpp@…

  • Component changed from ports to base
  • Milestone set to MacPorts base bugs

comment:2 Changed 10 years ago by jberry@…

  • Owner changed from macports-dev@… to jmpp@…
  • Version changed from 1.5.2 to 1.6.0

This bug is due to the fact that in Leopard, MANPATH is now set explicitly by default (read path_helper(8)). In such a case, the extremely useful mapping of PATH to MANPATH (as had been done in prior versions of Mac OS X) is not performed, which means that the man pages at /opt/local/share/man are not found automatically.

This problem has already been fixed in trunk. I'm not sure if the changes have yet been migrated to the 1.6 branch.

Trunk installs two files, /etc/paths.d/macports and /etc/manpaths.d/macports, which contain lists of paths that should be incorporated into the PATH and MANPATH environment variables.

As a workaround, install these files yourself, or set your MANPATH variable to include /opt/local/share/man.

Assigning this bug to jmpp to ensure he migrates the fixes to 1.6 branch.

comment:3 Changed 10 years ago by jmpp@…

The work on /etc/paths.d and /etc/manpaths.d has already been merged into the 1.6 branch, but other than that I'm not too sure a missing MANPATH variable or mapping to PATH variable or whatever route Leopard uses to find man pages (standard, please emerge!) is what's troubling the original poster. It seems to me like his man command is having problems with shell locales, from the error he reported:

Cannot open the message catalog "man" for locale "de_DE.UTF-8" (NLSPATH="<none>")

To the original poster, what *LANG* env variable do you have set? Or is it LC_ALL? Does the problem go away if you unset either of those or if you set them to english (en_US.UTF-8)?

-jmpp

comment:4 Changed 10 years ago by eingaspode@…

OK, here the extra info.

setenv says

LANG=de_DE.UTF-8

After

setenv LANG en_US.UTF-8

I no longer receive the error message about my locale settings. This propably is another bug I already filed at Apples Bugreporter.

But of course the man page still is not found. I now receive the message


No manual entry for port


Is there a roadmap when 1.6.0 will be released?

Thanks for taking a look at my bug report.

comment:5 Changed 10 years ago by raimue (Rainer Müller)

Since the guide covers now that MANPATH has to be set, I think this should be closed.

comment:6 Changed 9 years ago by jokkel@…

After just installing, I had the same problem. Although .profile contained the following lines:

# MacPorts Installer addition on 2008-06-22_at_14:34:42: adding an appropriate MANPATH variable for use wi$
export MANPATH=/opt/local/share/man:$MANPATH
# Finished adapting your MANPATH environment variable for use with MacPorts.

The manpath hadn't changed as env showed. And so there was no man page available for port and installed ports. But the changes to path worked.

jokkel@myMac:~/$ env
MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11/man
(…)
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/opt/local/bin

Adding the following line to .bash_profile finally did the job.

export MANPATH=${MANPATH}:/opt/local/man

It works now. I'm not sure what went wrong. But this should be fixed, as it is really a basic flaw on non english systems.

comment:7 follow-up: Changed 9 years ago by ryandesign (Ryan Schmidt)

  • Cc jokkel@… ryandesign@… added

@jokkel: it sounds like you're saying that you have a .profile and a .bash_profile, and setting MANPATH in .profile had no effect, while setting MANPATH in .bash_profile worked. And that's exactly right. .bash_profile takes precedence over .profile. MacPorts only attempts to modify .profile, not .bash_profile.

comment:8 in reply to: ↑ 7 Changed 9 years ago by jokkel@…

Replying to ryandesign@macports.org:

@jokkel: it sounds like you're saying that you have a .profile and a .bash_profile, and setting MANPATH in .profile had no effect, while setting MANPATH in .bash_profile worked. And that's exactly right. .bash_profile takes precedence over .profile. MacPorts only attempts to modify .profile, not .bash_profile.

comment:9 Changed 9 years ago by jokkel@…

.bash_profile takes precedence over .profile. MacPorts only attempts to modify .profile, not .bash_profile.

Well, I didn't know that. Could the installer not check for .bash_profile and write to it too, if it's found? I know lots of people using .bash_profile to get color coding for folders, files, links. Or at least this should be mentioned in the docs somewhere.

comment:10 follow-up: Changed 9 years ago by blb@…

It definitely should be smart about it; the patch isn't too complicated.

comment:11 in reply to: ↑ 10 ; follow-up: Changed 9 years ago by ryandesign (Ryan Schmidt)

Replying to blb@macports.org:

It definitely should be smart about it; the patch isn't too complicated.

Sure. We should probably also do the same for the various configuration files the tcsh shell could use instead of assuming .tcshrc

comment:12 in reply to: ↑ 11 ; follow-up: Changed 9 years ago by blb@…

Replying to ryandesign@macports.org:

Sure. We should probably also do the same for the various configuration files the tcsh shell could use instead of assuming .tcshrc

Looking at the man page, seems like just ~/.tcshrc or ~/.cshrc would be the two to check for?

comment:13 in reply to: ↑ 12 Changed 9 years ago by ryandesign (Ryan Schmidt)

Replying to blb@macports.org:

Looking at the man page, seems like just ~/.tcshrc or ~/.cshrc would be the two to check for?

Those are the ones I know about. But then I didn't know about .bash_login for bash.

comment:14 Changed 9 years ago by blb@…

  • Milestone changed from MacPorts base bugs to MacPorts 1.8.0

comment:15 follow-up: Changed 9 years ago by jmroot (Joshua Root)

Fixed along with #17588?

comment:16 in reply to: ↑ 15 Changed 9 years ago by blb@…

  • Milestone changed from MacPorts 1.8.0 to MacPorts 1.7.1
  • Resolution set to fixed
  • Status changed from new to closed

Replying to jmr@…:

Fixed along with #17588?

Looks that way.

Note: See TracTickets for help on using tickets.