I'm running OSX Mavericks and have installed Macports. I installed gcc via Macports which is working fine. However when I type man gcc I only get:
No manual entry for gcc
I was told I need to add the following to my .bash_profile
export MANPATH=/opt/local/share/man:$MANPATH
which I have done with no effect. Does Macports actually install the corresponding man pages? The man page for the 'port' command works fine as well as other preinstalled tools like clang.
Any help? Cheers.
What the man command looking for is the file 'gcc.1.gz' instead.
You may simply create the symbolic link under the folder /opt/local/share/man/man1
sudo ln -s g++-mp-4.8.1.gz gcc.1.gz
I also did the same for g++.1.gz and c++.1.gz.
I've been having the same problem.
I'm not sure how macports sets the manpath or how to correctly change it in os x for that matter.
But if you do man --path you can see what the path is set to. On mine I see /opt/local/share/man is first.
If I then look for a gcc man page with find it shows me that there is in fact a man page in there
$ find /opt/local/share/man -name "*gcc*"
/opt/local/share/man/man1/gcc-mp-4.8.1.gz
So then I tried man gcc-mp-4.8.1 but that also didn't work.
In the end, it works if you just put the full path when calling man.
This works:
man /opt/local/share/man/man1/g++-mp-4.8.1.gz
Kind of crappy to have to put in the whole path but at least you can see it if you need to.
Putting export MANPATH=/opt/local/share/man:$MANPATH in your .bash_profile is correct, but it will only take effect on new terminals.
Related
I tried following the docs exactly:
git clone git://github.com/bbatsov/prelude.git C:\emacs24.5\prelude
ln -s C:\emacs24.5\prelude C:\Users\blokeley\AppData\Roaming\.emacs.d
cd C:\Users\blokeley\AppData\Roaming\.emacs.d
Then I tried copying C:\Users\blokeley\AppData\Roaming\.emacs.d\prelude\sample\prelude-modules.el to various places:
C:\Users\blokeley\AppData\Roaming\.emacs.d\prelude-modules.el
C:\Users\blokeley\AppData\Roaming\.emacs.d\prelude\prelude-modules.el
C:\Users\blokeley\AppData\Roaming\.emacs.d\prelude\installation\prelude-modules.el
C:\emacs24.5\prelude\prelude-modules.el
When I start emacs, it starts as though prelude was not there: I don't seem to get any indication that prelude has loaded correctly at all.
For example, M-x prelude- returns no matches. I uncommented the (require 'prelude-helm) but M-x helm- returns no matches.
How do I get prelude working?
Just guessing, but if your windows version of emacs does not understand "symbolic links" (those that you create with the ln command) then it wont find your init.el file. Instead of
ln -s C:\emacs24.5\prelude C:\Users\blokeley\AppData\Roaming\.emacs.d
try to copy "C:\emacs24.5\prelude" to "C:\Users\blokeley\AppData\Roaming".
Note that on my machine, the directory ~ expands to C:\Users\blokeley\AppData\Roaming
I strongly recommend that Windows users set the HOME environment variable to something like C:\Users\YOURNAME
I managed to install prelude by:
git clone git://github.com/bbatsov/prelude.git C:\emacs24.5\prelude
ln -s C:\emacs24.5\prelude C:\Users\blokeley\AppData\Roaming
mv C:\Users\blokeley\AppData\Roaming\prelude C:\Users\blokeley\AppData\Roaming\.emacs.d
Then started emacs, which failed due to no GnuTLS being installed, so I found this issue and followed this help page which fixed it. Basically, I installed GnuTLS from http://sourceforge.net/projects/ezwinports/files/ into my emacs/bin directory and all seems to be working.
I then tried to add my old .emacs file to C:\Users\blokeley\AppData\Roaming. However, this broke prelude completely, so I found that I should simply add my customisations to
C:\Users\blokeley\AppData\Roaming\.emacs.d\personal\custom.el
I also wanted find and grep to work properly. Emacs needs the posix versions of these commands rather than the Windows versions. Luckily, I had GitHub Desktop already installed, which has them, so I added the following to my PATH environment variable before system32:
C:\Users\blokeley\AppData\Local\GitHub\PortableGit_c7e0cbde92ba565cb218a521411d0e854079a28c\usr\bin
The long code after PortableGit will be different in your case.
Happy days.
I am trying to install a man page for a bash script on Mac OS X 10.9.5. The procedure that I tried to follow is summarised here: man page tutorial. I also summarise the steps that I tried below:
cp custom_command.1 /usr/local/man/man1/custom_command.1
gzip /usr/local/man/man1/custom_command.1
When trying man custom_command I receive the output No manual entry for custom_command. I also tried other installation methods mentioned in man page tutorial.
It is interesting to note that the steps above worked for the emacs console, i.e. I do get the correct manual when I type man custom_command. However, the command is not recognised by the autocomplete and I receive the following warning before I am able to read the manual: WARNING: terminal is not fully functional.
Any advice on how to resolve the issues above (i.e. both with the system terminal and the emacs console) would be appreciated.
Remark 1
For a reference, the man script that I am trying to install was taken from the tutorial and is restated below for a reference:
.\" Manpage for nuseradd.
.\" Contact vivek#nixcraft.net.in to correct errors or typos.
.TH man 8 "06 May 2010" "1.0" "nuseradd man page"
.SH NAME
nuseradd \- create a new LDAP user
.SH SYNOPSIS
nuseradd [USERNAME]
.SH DESCRIPTION
nuseradd is high level shell program for adding users to LDAP server. On Debian, administrators should usually use nuseradd.debian(8) instead.
.SH OPTIONS
The nuseradd does not take any options. However, you can supply username.
.SH SEE ALSO
useradd(8), passwd(5), nuseradd.debian(8)
.SH BUGS
No known bugs.
.SH AUTHOR
Vivek Gite (vivek#nixcraft.net.in)
First of all you may want to check if the man page your are trying to install is properly formatted and can be opened by man command. To do this pass the path to the man file to man command. It must contain a slash in order to be recognized as a path, for example:
man /usr/local/man/man1/custom_command.1
Then you should make sure the path you are installing your man page to is on the search list of man command. In order to find the man page its path must be either:
specified with -M option to the man command
set in the environmental variable MANPATH
listed in its config file (/private/etc/man.conf on OS X) under MANPATH statement or under MANPATH_MAP statement (which applies only to locations in your PATH environmental variable)
located in the location relative to where binary is installed, i.e.: if binary is installed in path/bin the man page is searched for in path/man, path/cat and path/bin/man, path/bin/cat
listed in files added in /private/etc/manpaths.d/ directory
The name of the man page file must be same as command name with optional section number. It may be gzipped.
To see where man will search for your custom_command man page run
man -d custom_command
OS X user command man pages are typically created in:
/usr/local/share/man/man1
If you prefer to create man pages in a different directory edit:
/private/etc/man.conf
Then add the new path to MANPATH_MAP, for example:
MANPATH_MAP /usr/local/bin /usr/local/man
To have man search a non-default path with a default fallback (/usr/local/share/man):
MANPATH /usr/local/man
MANPATH /usr/local/share/man
MANPATH_MAP /usr/local/bin /usr/local/share/man
Manual pages in MacOS X
The man command in MacOS X uses a sophisticated method of finding manual page files, based on the invocation options and environment variables, the /private/etc/man.conf configuration file, and some built in conventions and heuristics.
In MacOS X you have a command:
/usr/bin/manpath
That lists all your current locations for searching for man pages.
It can be invoked by just typing
manpath
in a Terminal.
It does not however add this to your $MANPATH shell variable.
But you'll still have access to the manpages with the man command.
What get's included in manpath is defined in
/private/etc/man.conf
It's not advised to export an environment variable called MANPATH without adding the output of:
`manpath`
to the list.
So if you want to export $MANPATH to your shell environment, do it like:
export MANPATH="`manpath`:/path/to/man/pages/to/include"
That way you'll get a complete list of manpages defined by the OS and any paths you add yourself.
For more info, open up a terminal and check:
man manpath
and the man.conf file with:
more /private/etc/man.conf
Usually a better option for including man pages in peculiar places, is to create a symlink to the directory containing the man pages in /usr/local/share/man which is indexed by the "man ecosystem" by default.
I had installed packages via brew, but the man command was drawing a blank because I had installed brew to a different directory.
To get round this, still linking the packages (which linked content up a few directories), I could then add to MANPATH in my .bash_profile, like so...
MANPATH="/Users/me/Developer/share/man:$MANPATH"
While existing answers do provide some hints/options which can help solve the OP's problem, they do not actually answer the question in title.
Indeed, in order for the man program to open the man page, it should know where to look for it. This is an obvious statement, but it doesn't help much. The question is whether you should use some "standard" location (and if so, what are those "standard" lookup paths, and where are they defined), or should you place the man page along with your program, and somehow point the man program to your custom location?
The OP seems to have tried placing the man page to what he thought was a "standard" location (/usr/local/man), but the man was unaware of it.
It should have worked if, instead of /usr/local/man/man1/custom_command.1, a /usr/local/share/man/man1/custom_command.1 was used. How could you know this? The answer is in the /etc/man.conf:
#
# Every automatically generated MANPATH includes these fields
#
MANPATH /usr/share/man
MANPATH /usr/local/share/man
MANPATH /usr/X11/man
MANPATH /Library/Apple/usr/share/man
/etc/man.conf is used to configure the default manpath (the provided example is from the default man.conf in macOS Big Sur). That being said, I don't think relying on man.conf default configuration and simply copying the man page for your custom program/script to one of these directories is the right thing to do.
The reason is that the default manpath is configured according to the man.conf only if the $MANPATH environment variable is not set or is empty. If the $MANPATH environment variable is set/not empty, the paths in the /etc/man.conf are not used to look up the man pages.
By default, $MANPATH is not set. But if your program/script + man page will be distributed to other users, you can't be sure whether or not it's set there.
So, what would be a reliable solution? In my opinion, shipping the man pages along with the script, and using the path_helper (man path_helper for more info) to point man to the custom manpath is the best way to go for third-party programs.
From the program/script author the only thing that's needed is to place the file, containing the path to the program man pages, into the /etc/manpaths.d directory. path_helper should do the rest.
It seems that path_helper was designed specifically for such use case, and it's being used by third-party programs (I learned about it after installing Wireshark and while trying to make its man pages discoverable), but there is one caveat:
path_helper will not make the man aware about your custom manpath, if the $MANPATH environment variable was not previously set (and as we know, it's not set by default). From path_helper man page:
(The MANPATH environment variable will not be modified unless it is already set in the environment.)
And this is the reason why you would actually want to set the $MANPATH, to allow the path_helper to augment it with custom manpaths afterwards.
In my case I added export MANPATH (just to set it, without any value) to /etc/zshenv (I am using macOS Big Sur, zsh is the default shell), and path_helper successfully added all the custom manpaths from /etc/manpaths.d files.
Besides all the entries pointed out in baf's answer, there's also /etc/manpaths, which is quite convenient to use for including man pages installed via Homebrew.
For example, below is the content of my /etc/manpaths:
/usr/local/opt/coreutils/libexec/gnuman
/usr/local/opt/findutils/libexec/gnuman
/usr/local/opt/gawk/libexec/gnuman
/usr/local/opt/gnu-sed/share/man
/usr/local/opt/readline/share/man
/usr/local/share/man
/usr/share/man
Meanwhile make sure in /etc/profile, MANPATH is defined before path_helper is loaded:
export MANPATH= # hack: path_helper doesn't setup MANPATH without this
eval `/usr/libexec/path_helper -s`
BTW, in macOS, the default pager is /usr/bin/less is a bit old, and doesn't even support \b for word boundary in regex, so you might want to setup MANPAGER in ~/.bashrc (or somewhere you prefer):
export MANPAGER=/usr/local/bin/less
I recently configured my terminal according to this blog. After followed it step by step, everything is OK but the colour of ls's outputs are grey.
I googled this problem and found this. It says that adding export LSCOLORS=gxfxbEaEBxxEhEhBaDaCaD to the .bash_profile will resolve this problem.
BUT, I use zsh with oh-my-zsh instead of bash. There is no bash_profile at ~. I also tried to add this environments variable to .zshrc, it didn't work unfortunately.
Another way to resolve this problem is to install coreutils packets and use GNU ls instead. However, I reluctantly to install this big packets just for a ls command.
How can I fix this problem.....
I finally surrendered to install GNU-ls instead...
I want to make my bash script deal with long parameters. I found getopt, but it isn't supported in OS X. Can anyone tell me why getopt was implemented by BSD, but not GNU?
I tried building getopt in GNU C lib, but it failed for my poor skills with Linux.
Did anyone do this work?
There is a brew bottle for getopt.
Just run brew install gnu-getopt.
You can either specify the path for it like
/usr/local/Cellar/gnu-getopt/1.1.6/bin/getopt
Or use brew link --force gnu-getopt so it will be linked in /usr/local/bin/
Just be aware that forcing linking might be corrupting your system (as it replaces the system getopt by the gnu one).
See maybe later answer suggesting to define FLAGS_GETOPT_CMD (though few comments state issues with it).
I recommend using Homebrew to install gnu-getopt and then adding $FLAGS_GETOPT_CMD to your ~/.bash_profile file to specify the cmd path for getopt, pointing at the homebrew location, like so:
brew install gnu-getopt
Then follow directions from brew to add to your local path:
sudo echo 'export PATH="/usr/local/opt/gnu-getopt/bin:$PATH"' >> ~/.bash_profile
Then you can add FLAGS_GETOPT_CMD:
sudo echo 'export FLAGS_GETOPT_CMD="$(brew --prefix gnu-getopt)/bin/getopt"' >> ~/.bash_profile
Open a new terminal, or run . ~/.bash_profile in existing terminal to load changes
Run echo $FLAGS_GETOPT_CMD to confirm it was actually set in your console
It's generally a better idea to use getopts instead, and stick with short options. You can see getopts in action in this StackOverflow Q&A. Short options are more standard throughout OSX command line tools, and consistency is a good thing.
Also, getopts is built in to bash, so it's definitely available in OSX, as well as every other platform that can run bash.
Note that there is a getopt is also available in OSX. From Terminal, type man getopt to see its documentation. It doesn't support long options. This is a good reason not to use long options when you're writing tools to run on OSX.
If you want to do this anyway, you can install getopt from macports. Alternately, if you want better portability, you can roll your own long argument handling.
Post some code, and we'll help debug it.
I've done a lot of searching and there seem to be similar issues, but none that have helped me solve this problem. I'm fairly new to Ruby, Rails, and -ix systems so that doesn't help much, either. :(
I was able to get RVM up and running along with the latest versions (1.9.3-p125 of Ruby and 3.2 of Rails). However, when I exit terminal and come back in the system defaults are being used. When I tried to change versions I received a "command not found". I then tried just typing "rvm" and got:
-bash: rvm: command not found
I followed some other tutorial advice and modified my ~/.bashrc file to look like this:
PATH=$PATH:$HOME/.rvm/bin # Add RVM to PATH for scripting
echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"' >> ~/.bashrc
but I'm still getting the exact same "command not found" even after exiting Terminal.
Any thoughts on how to get RVM working properly? Everyone says use it, but it sure isn't simple...
Thanks a lot!
Greg
I followed some other tutorial advice and modified my ~/.bashrc file
Usually I modify .profile file on Mac OS X, and .bashrc on Linux. Try to modify .profile
Please check How to fix Terminal not loading ~/.bashrc on OS X Lion to know why Terminal doesn't load .bashrc file.
If you modify your .bashrc you either need to immediately source it or create a new shell to see the changes take effect.
The standard rvm procedure is to source the rvm script that is created. The installation documentation covers most use cases.
If your rvm command is missing, it's possible that your .bashrc is not working as you expect. Is your PATH being modified as you've requested? If not you might have another issue.