I've checked out some typical open source project which is using auto-tools. I want to hack a bit on this package, but I would also like to change something in the man-page of the package.
The man-page source is found project-name/doc/project-name.1. I just made a small change, and now I want to preview that change, without having to actually do a make install of the project. How do I do that?
I tried stuff like:
man -M . 1 project-name
But it does not work, neither does the various variations I have tried. This sounds like a simple problem, but I can't seem to find anything by googling on the problem, so I'm hoping someone here can help me out. Thanks.
man -l /path/to/manfile.1
On my system, the output from this command is different from nroff -man file.1 | less. Paragraphs wrap at the edge of the terminal, for instance, rather than at 78 characters.
nroff -man /path/to/manfile.1 | less
Related
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 am trying to do a directory-wide search for specific strings in JSON files. The only problem is that these JSON files are only one line, so when I cat all of them, all strings occur a magical "1" time...since there's only one line even when I string them all together.
An easy solution, which I see a lot (here and here), is grep -o. Only problem is it doesn't come standard on my Gitbash. I solved my immediate problem by just installing the latest Cygwin. However, I'm wondering if there was an easier/more granular solution. Is it possible to do the equivalent of "apt-get install" or similar on Gitbash? Or can someone explain to me a quick-and-dirty way to extract and install the tar file in Gitbash?
The other approach is to:
use a cmd session (using the git-cmd.bat which packaged with Git for Windows)
use the grep included Gnu for Windows, which supports the -o option (and actually allow you to use most of the other Unix commands that your script might be currently using)
How do I get a GUI-based merge tool to work with command line SVN in linux? I understand that there are many options like meld, svn Diff, etc. out there. All of them require a helper script to allow svn to invoke the external program during conflict resolution. I followed the instructions given here and the nice svn manual with meld.
But in all cases, when I get to the merge conflict and type 'l' to invoke the external tool, I get an error: The external merge tool exited with exit code 255
I'm fairly certain I'm missing some key thing here. ITs too much of a coincidence for so many different solutions to fail. Would appreciate any solution or pointers to the problem.
Thanks!
Also make sure that the path in your config is absolute. It should be the same path you see when you run a pwd command from that directory. No aliases or relative paths. So if your username is foo you would replace this line:
Add this below it:
merge-tool-cmd = ~/bin/svn-merge-meld
With
Add this below it:
merge-tool-cmd = /Users/foo/bin/svn-merge-meld
You may not have the correct permissions on the wrapper script. Try something like this:
sudo chmod +x /usr/local/bin/mergewrap.py
I've found several wrapper scripts for vimdiff or meld which seem to pass the wrong number of arguments. Unless I've misunderstood the rather terse documentation about the commandline parameters, they only take 2 or 3 filenames. This may also cause the script to fail with an error.
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