Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Command line tools for the novice

andymatthews.net

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Command line tools for the novice

#51

Post by AdamGibbins »

johncoltrane wrote: post #47
commadelimited wrote: post #2

I'd love to hear other tools that you guys are using for your daily workflow.

CLI (Mac OS X and Linux): bash, git/tig, svn, cdargs, vifm or ranger (can't decide), vim, grep, man, ssh, a few custom functions and tmux. GUI (Mac OS X): MacVim, ClipMenu, YummyFTP, Quicksilver, iTerm2, SourceTree, FileMerge, Chrome dev tools. GUI (Linux): GVim, Glippy, FileZilla, Synapse, Gnome terminal, SmartGit/SmartSVN, Meld, Chrome dev tools.

Terminator (http://www.tenshu.net/p/terminator.html) is a nice replacement for Gnome Terminal thats very similar to iTerm2.

Re: Command line tools for the novice

#52

Post by jasonlotito »

tocomment wrote: post #33
jasonlotito wrote: post #31

tmux - Without a doubt, the biggest upgrade to my workflow in years. If you aren't using tmux (or at least screen), you are doing yourself a big disservice. Also, I keep seeing iTerm2 get mention. You mentioned split panes and what not, which are not critical when I have that with tmux (as well as the tabs). And while before Lion, Terminal's color support was weak, that's changed. So, I really wonder what the big rea…

What's the benefit from tmux? Why is it better than just using multiple windows?

Because I can shut down my computer, move to another one, and pick up right where I left off. This means even if I leave a process running, it doesn't stop.

tmux is like screen, only it has more features.

Which is really why I asked. What does iTerm2 offer that I can't get from tmux and current terminal? People always refer to iTerms ability to do multiple windows/tabs. For me, this is useless if it's just available client side.

There is an amazing amount of freedom being able to just shut down, move to another computer, and be able to pick up exactly where I left off.

Re: Command line tools for the novice

#53

Post by johncoltrane »

AdamGibbins wrote: post #51
johncoltrane wrote: post #47

Earlier quoted context omitted.

CLI (Mac OS X and Linux): bash, git/tig, svn, cdargs, vifm or ranger (can't decide), vim, grep, man, ssh, a few custom functions and tmux. GUI (Mac OS X): MacVim, ClipMenu, YummyFTP, Quicksilver, iTerm2, SourceTree, FileMerge, Chrome dev tools. GUI (Linux): GVim, Glippy, FileZilla, Synapse, Gnome terminal, SmartGit/SmartSVN, Meld, Chrome dev tools.

Terminator ( http://www.tenshu.net/p/terminator.html ) is a nice replacement for Gnome Terminal thats very similar to iTerm2.

Thanks, I'll take a look.

I don't use any advanced features of iTerm, though, I just use it over Terminal.app because it supports 256 colors. We have not been updated to Lion or Mountain Lion at work so Terminal.app is still limited to 16 colors for me.

Re: Command line tools for the novice

#54

Post by tocomment »

jasonlotito wrote: post #52
tocomment wrote: post #33

Earlier quoted context omitted.

What's the benefit from tmux? Why is it better than just using multiple windows?

Because I can shut down my computer, move to another one, and pick up right where I left off. This means even if I leave a process running, it doesn't stop. tmux is like screen, only it has more features. Which is really why I asked. What does iTerm2 offer that I can't get from tmux and current terminal? People always refer to iTerms ability to do multiple windows/tabs. For me, this is useless if it's just available…

So you have to install tmux on the server?

Re: Command line tools for the novice

#55

Post by pydave »

ralph wrote: post #44
spudlyo wrote: post #39

Earlier quoted context omitted.

GNU grep also supports PCRE. chunky:~$ otool -L /usr/bin/grep | grep pcre; grep --help | grep perl /usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0) -P, --perl-regexp PATTERN is a Perl regular expression Many users choose ack over grep for the same reason they choose htop over top, tmux over screen, zsh over bash, and postgres over mysql -- the perception that one is significantly better t…

I often see ack recommended by word of mouth but unfortunately I feel it's between programmers that don't understand the Unix command-line enough to instruct grep, find, xargs, etc., sufficiently accurately to do what they intend and ack has the allure of doing the right thing, though often slowly, as you say. GNU grep's -I option to ignore binary files for example, or -boa to search binary files. Once the standard c…

How would you exclude the same kinds of files that ack does in grep without typing out the exclude patterns?

As described here ( http://blog.sanctum.geek.nz/default-grep-options/ ), you could use GREP_OPTIONS, but then you run into the problems here ( http://brainstorm.ubuntu.com/idea/24141/ ) -- scripts that use grep without clearing GREP_OPTIONS will fail.

Do you have an alias? Or another script that wraps grep?

Re: Command line tools for the novice

#56

Post by spudlyo »

pydave wrote: post #55
ralph wrote: post #44

Earlier quoted context omitted.

I often see ack recommended by word of mouth but unfortunately I feel it's between programmers that don't understand the Unix command-line enough to instruct grep, find, xargs, etc., sufficiently accurately to do what they intend and ack has the allure of doing the right thing, though often slowly, as you say. GNU grep's -I option to ignore binary files for example, or -boa to search binary files. Once the standard c…

How would you exclude the same kinds of files that ack does in grep without typing out the exclude patterns? As described here ( http://blog.sanctum.geek.nz/default-grep-options/ ), you could use GREP_OPTIONS, but then you run into the problems here ( http://brainstorm.ubuntu.com/idea/24141/ ) -- scripts that use grep without clearing GREP_OPTIONS will fail. Do you have an alias? Or another script that wraps grep?

    find . -type f -name \*.[ch] | grep -v \\.git | xargs grep something
Normally my directories aren't going to have .bzr, .git, .hg, and .svn in the same directory tree, but if they did it wouldn't be that much harder.

    alias nocrap="egrep -v \\.\(git\|bzr\|hg\|svn\)"
    find . -type f -name \*.[ch]| nocrap | xargs grep whatever
This is how I do it because I'm lazy. I suppose I could tell find to exclude directories so it wouldn't have to recurse into them, but the list of directories and files in my source tree is almost always in buffer cache anyway, so I never really worry about it.

Re: Command line tools for the novice

#57

Post by ralph »

spudlyo wrote: post #56
pydave wrote: post #55

Earlier quoted context omitted.

How would you exclude the same kinds of files that ack does in grep without typing out the exclude patterns? As described here ( http://blog.sanctum.geek.nz/default-grep-options/ ), you could use GREP_OPTIONS, but then you run into the problems here ( http://brainstorm.ubuntu.com/idea/24141/ ) -- scripts that use grep without clearing GREP_OPTIONS will fail. Do you have an alias? Or another script that wraps grep?

find . -type f -name \*.[ch] | grep -v \\.git | xargs grep something Normally my directories aren't going to have .bzr, .git, .hg, and .svn in the same directory tree, but if they did it wouldn't be that much harder. alias nocrap="egrep -v \\.\(git\|bzr\|hg\|svn\)" find . -type f -name \*.[ch]| nocrap | xargs grep whatever This is how I do it because I'm lazy. I suppose I could tell find to exclude directories so it…

You might want to consider using single quotes to protect your globs and regexps more rather than backslashes. \✳.[ch] will match the ./✳.c that may have been accidentally created by an earlier error, then find will only look for a file called precisely ✳.c and nothing else. '✳.[ch]' or \✳.\[ch] is what's meant.

(Edited to use ✳ to workaround unescapable mark-up.)

Re: Command line tools for the novice

#58

Post by ralph »

pydave wrote: post #55
ralph wrote: post #44

Earlier quoted context omitted.

I often see ack recommended by word of mouth but unfortunately I feel it's between programmers that don't understand the Unix command-line enough to instruct grep, find, xargs, etc., sufficiently accurately to do what they intend and ack has the allure of doing the right thing, though often slowly, as you say. GNU grep's -I option to ignore binary files for example, or -boa to search binary files. Once the standard c…

How would you exclude the same kinds of files that ack does in grep without typing out the exclude patterns? As described here ( http://blog.sanctum.geek.nz/default-grep-options/ ), you could use GREP_OPTIONS, but then you run into the problems here ( http://brainstorm.ubuntu.com/idea/24141/ ) -- scripts that use grep without clearing GREP_OPTIONS will fail. Do you have an alias? Or another script that wraps grep?

My normal way of running grep is ~/bin/g.

    #! /bin/sh

    exec egrep --color "$@"
(Not a bash, my shell, alias because they're unavailable in many contexts.)

egrep is AKA grep -e. I don't use GREP_OPTIONS because it pollutes those that don't expect it, as you pointed out.

At the top of a particular source tree I may have a ./g that knows more about what's interesting.

    #! /bin/bash

    find \( -name .svn -o -name tags \) -prune -o -type f -exec egrep "$@" {} +
It checks -name before -type because the latter needs a stat(2).

For other things I do ad hoc queries using grep, find, xargs, etc.

Re: Command line tools for the novice

#59

Post by spudlyo »

ralph wrote: post #57
spudlyo wrote: post #56

Earlier quoted context omitted.

find . -type f -name \*.[ch] | grep -v \\.git | xargs grep something Normally my directories aren't going to have .bzr, .git, .hg, and .svn in the same directory tree, but if they did it wouldn't be that much harder. alias nocrap="egrep -v \\.\(git\|bzr\|hg\|svn\)" find . -type f -name \*.[ch]| nocrap | xargs grep whatever This is how I do it because I'm lazy. I suppose I could tell find to exclude directories so it…

You might want to consider using single quotes to protect your globs and regexps more rather than backslashes. \✳.[ch] will match the ./✳.c that may have been accidentally created by an earlier error, then find will only look for a file called precisely ✳.c and nothing else. '✳.[ch]' or \✳.\[ch] is what's meant. (Edited to use ✳ to workaround unescapable mark-up.)

Good point, thanks!
Post reply on HN