The following command gives many manuals of Zsh
man zsh<tab>
alt text http://dl.getdropbox.com/u/175564/zsh.png
I would like to browse them fast to search the word compinit.
How can you search the word compinit fast in the manuals in Zsh?
Often for this kind of thing
man -k compinit
works, because authors are sensible enough to put lots of identifiers into the "short description" of the man page.
This doesn't seem to be the case here ... so you're going to have to grep through the source. Which is gzipped ...
zgrep -c compinit /usr/share/man/man1/zsh*
or if you don't have zgrep:
cd tmp
cp /usr/share/man/man1/zsh* .
gunzip zsh*.gz
grep -c compinit zsh*
There are more elegant ways to do this, but that gives you a list of how often compinit appears in each file:
zsh.1:0
zsh4.1:0
zshall.1:0
zshbuiltins.1:0
zshcalsys.1:0
zshcompctl.1:0
zshcompsys.1:29
zshcompwid.1:0
zshcontrib.1:0
zshexpn.1:0
zshmisc.1:0
zshmodules.1:1
zshoptions.1:0
zshparam.1:0
zshroadmap.1:0
zshtcpsys.1:0
zshzftpsys.1:0
zshzle.1:0
Using the internet is probably the best way. The other approach is to use the zshall manpage, which contains all the manpages together. You can then search for compinit in whatever viewer you're using.
EDIT: I just remembered a better way of doing this: Use zsh's run-help function.
$> run-help compinit
This will take you to the manpage that zsh thinks is most appropriate for the topic. It also works for non-zsh related topics like ps, grep, etc, but has been adjusted to work for zsh topics as well.
If for some reason run-help isn't loaded, you can use
$> autoload run-help
to do so.
You could use the internet... all of the man pages are on it... just prefix your searches with
zsh man
(If you know where they are located on the harddrive... you might be able to grep them... I don't know as I have not ever needed to myself)
Related
I see the following question every time I open man pages for git commands:
-> man git-log
Man: find all matching manual pages
* git-log (1)
git-log (1+)
Man: What manual page do you want?
After that I have to wait till the first section is opened automatically or choose it manually.
The question is raised because of two versions of git and its man pages installed on my work host (where I am an ordinary user without administrative privileges):
-> man --where --all git-log
/app/vbuild/SLED11-x86_64/git/2.14.1/man/man1/git-log.1
/usr/share/man/man1/git-log.1.gz
-> echo $MANPATH
/app/vbuild/SLED11-x86_64/git/2.14.1/man:/usr/share/man:/usr/local/man
-> man --version
man 2.5.2
When I remove the first path from MANPATH, the older version of git man pages is opened without any questions. If I remove '/usr/share/man', the newer version is opened automatically but I loose access to pages for other (non-git) commands. Neither of these options is suitable for me.
Can I set preference for one of duplicating sections while keeping others (not duplicating) available as well?
Update:
I have found (thanks to David C. Rankin and a mistake I made through lack of attention) that man's option -c helps to get the desired effect. It is described as follows in the man page for man:
-c, --catman
This option is not for general use and should only be used by the catman program.
So, it is still not clear what the cause of the problem is, why and how the option helps and if it is correct to use it in this way.
I tried to debug man by executing man -d git-log and man -d -c git-log and comparing the output. I see that the differences are mainly about missing debug output of the following kind in the case when I run man -d -c git-log (i.e. in the good case):
update_directory_cache /usr/share/man/cat3curses: miss
can't open directory /usr/share/man/cat3curses: No such file or directory
directory cache update failed
Though, in both cases there are lines as follows:
update_directory_cache /usr/share/man/man3curses: miss
can't open directory /usr/share/man/man3curses: No such file or directory
directory cache update failed
I really like working with grep for it's robust work and customizability.
:vimgrep is too slow for me, grep without --include (or --exclude) too. Also I work with at least 8 file types and --include is a huge helper.
My problem is that:
:grep "ILookForThat" **/*.{c,h}*
Search only one catalog depths, while I need at least four.
:grep -R "ILookForThat" --include=*.{c,h}*
Doesn't work ( the same with "*.{c,h}*" )
What I look for is answer: how to make grep (not vimgrep, ag, or anything else) work, or maybe some answer like: "That definitely should work".
I can add that I use 64 bit Ubuntu 16.04 LTS , removed my aliases for grep.
Of course answers without quicklist are with no acceptance.
After some quick tests I think this should work for you but it's a little verbose:
:grep -r --include="*.c" --include="*.h" "ILookForThat" .
You could consider wrapping this in a custom :command if it's too verbose to be useful.
:grep -r --include=*.{c,h}* ILookForThat .
Everything works as designed, but grep used from within vim has to have a starting point which is stated with a dot character.
I prefer to seach with locate command but I don't know how to perform a partial search with it.
Suppose I want to search file containing the word libevent. How can I do that?
Locate searches for file names. Not file contents.
The ugly way is to use grep It'll start searching from / directory.
grep -irn 'libevent' /
The better way is to narrow down the suspected directories where this files could exists. Suppose those directories' full paths are /path/to/dir1, /path/to/dir2 etc. Then invoke the following command.
for dir in /path/to/dir1 /path/to/dir2
do
grep -irn 'libevent' $dir
done
The locate command is not searching inside the content of files like grep (and other commands) do. It is simply searching inside file paths.
locate work by using a cache index of file paths, and this index is often updated by the updatedb utility.
addenda
A useful way to search some pattern inside (the content of) some files is to use the ability of zsh or some recent versions of bash to expand the ** file pattern, like e.g.
grep foo ~/gee/**/*.[ch]
with zsh this search inside all files named *.c or *.h under $HOME/gee/ containing foo. I find this feature tremendously useful, and justifying alone the adoption of zsh as my interactive shell. With other shells you might type the much longer
find $HOME/gee -name '*.ch' | xargs grep foo
The following command works fine:
$>cscope -b -R
However, the option for inverted index does not work:
$>cscope -b -q -k -R
Input file specified two times.
cscope: cannot create inverted index; ignoring -q option
cscope: removed files ncscope.in.out and ncscope.po.out
I googled this one and found some hits. But could not find any answers or solutions. Any insights are greatly appreciated.
I got it now!!!
As usual, should have read the manual properly :-)
I am using a win32 port of cscope from Google. (hosted at: http://code.google.com/p/cscope-win32/). Here is an excerpt from the 'wiki' tab (http://code.google.com/p/cscope-win32/wiki/UsageNotes?tm=6)
•To use inverted indices (-q option) you need sort utility. I am including one with the cscope archive (here is its source code). The utility can also be found on UnxUtils and http://gnuwin32.sf.net. It should be in your PATH before Windows dir because Windows has its own, incompatible sort utility.
NOTE: I actually needed to put the sort utility even before the c:\windows\system32. (It was not good enough to include it before c:\windows in the PATH).
Having done that, I am happy to say that I was able to create the inverted index.
I'd like to do ls without seeing all the ~ files generated by vim. Is it possible?
This is better solved from within vim, as opposed to bash.
Use
set backupdir=~/.backup,/tmp
to put all your ~ files in the ~/.backup directory. Change that directory to whatever you want. The /tmp means that it will act as a fallback to the ~/.backup directory.
If you don't want backup files to be generated at all, you can use
set nobackup
set nowritebackup
to disable it, but you will of course lose that functionality.
EDIT:
Although the above solution is still the one I recommend because you can do more with it, I just realized that ls has a -B option which will hide files ending with ~. I've aliased it myself, and never noticed. If you really want, you can alias ls -B and go with that.
EDIT v2.0:
As noted by Wesley, some platforms' ls command have different meanings for -B, some may not have it at all. I'm using the GNU ls, and it has had this switch for as long as I can remember.
Many editors use the ~ files to represent backup files. (I use this trick to hide the backup files from gedit.) To disable them from showing, add this command to your bashrc:
alias ls='ls --hide=*~'
Edit: Mac OS X ls does not appear to have this option, so it follows that BSD ls probably doesn't have it either. Ubuntu does have this option, so many Linux distributions probably do; check your manual pages. In addition, Mac ls appears to have a different -B, so consider this when using Sykora's advice.
You'll be sorrrrryyyy if you just hide them from ls. They'll still be there as far as grep and other tools are concerned except that now you can't see them. Moving them to /tmp is a much better way to go.
This problem is ESPECIALLY severe with .svn directories, which have all kinds of useless cr*p that you really don't want to edit. I don't know a solution to that one.
For Mac OS X:
brew install coreutils
echo "alias ls='/usr/local/bin/gls -B'" >> ~/.bashrc