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

41–50 of 59 posts

Re: Command line tools for the novice

#41

Post by ralph »

dhimes wrote: post #28
ralph wrote: post #21

> In Grep grep -R 'some term' * , in Ack ack 'some term'. The -R tells grep to search through all directories and subdirectories while the * tells it what types of files. No, that's not how it works with grep. The shell is expanding the glob * to all the things in the current directory that don't start with a dot and that's what grep sees. It then reads each of them in turn or if they're a directory it descends into…

I was under the impression that * expanded to all things not starting with a dot in all directories-- or better: in each directory that -R dictates. I understand that "* tells it what types of files," isn't correct, but I don't understand what you mean by "plays no further part in the descent."

What do you think is doing the expansion of the asterisk? It's the shell, not grep, and is called globbing. http://en.wikipedia.org/wiki/Globbing

The reason there are files that start with a dot is that ls(1) and globs starting with an asterisk ignore them by default. ls needs -a (all) to show them. Some shells, but not bash, provide a globbing syntax for the recursive expansion you think you require here.

But if, as normal, you want to grep recursively down from the current directory then that's what you should specify; just pass grep one path to search, dot, the current directory.

    grep -r foo .
This is very basic knowledge of the Unix command line for a programmer and I highly recommend the classic text _The Unix Programming Environment_ by Kernighan and Pike to learn the philosophy behind Unix. It has nothing on window systems, ssh, etc., nor should it have as that's modern-day noise that hides the essence. It and Kernighan and Ritchie's _The C Programming Language_ were the key books every starting-out Unix programmer read. http://www.amazon.com/exec/obidos/ASIN/013937681X/mqq-20

Re: Command line tools for the novice

#42

Post by johncoltrane »

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?

See tmux's homepage: http://tmux.sourceforge.net/

Tmux is not only a window manager, it allows me to:

* login only once into my VPS and run all kinds of things in parallel

* leave a session at work and come back to it at home

* run processes in the background with textual feedback

Its precursor, screen, works similarily with a little less bells and whistles.

Re: Command line tools for the novice

#43

Post by johncoltrane »

devgutt wrote: post #25
commadelimited wrote: post #4

Earlier quoted context omitted.

That's a good list. I considered including Git but that could be an entire article by itself. I've looked at TMux but I just don't I'd use it.

What's the difference between Tmux and iTerm2?

tmux is a CLI terminal multiplexer. As an interactive CLI program, you need a shell to use it. To run such a shell, you need a terminal emulator. iTerm2 is a Mac OS X only GUI terminal emulator.

You can run tmux in iTerm2.

Re: Command line tools for the novice

#44

Post by ralph »

spudlyo wrote: post #39
shurane wrote: post #37

Earlier quoted context omitted.

Yeah, I don't like it when people spout speed comparisons without backing it up either. A lot of people do want/need PCRE, which ack relieves the pain point for.

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 commands are learnt then by all means use ack if you understand the trade-offs and can fall back to the normal way when on another system or when ack's insufficient.

Re: Command line tools for the novice

#45

Post by ralph »

noselasd wrote: post #35
dhimes wrote: post #28

Earlier quoted context omitted.

I was under the impression that * expanded to all things not starting with a dot in all directories-- or better: in each directory that -R dictates. I understand that "* tells it what types of files," isn't correct, but I don't understand what you mean by "plays no further part in the descent."

just run echo * in your directory. That's the same argument grep will get(instead of the * ) when you pass it * . grep will run through all those files, if any, and recurse through all the directories, if any. grep recursing down a directory will process all the files/subdirs in that directory. (which includes . files). If the shell can't expand the * , grep will receive a literal * and try to open a file/directory n…

Personally, I `shopt -s failglob' in my .bashrc so any glob that fails to expand is treated as an error by the shell and the command never gets started. I then quote all special globbing characters that I intend to pass to the command as it avoids the sometimes hard to spot errors where a glob expanded unintentionally and the command didn't see the wildcards. Relying on non-matching globbing to reach the command will bite one day.

Re: Command line tools for the novice

#46

Post by ralph »

tedunangst wrote: post #27
calpaterson wrote: post #22

Earlier quoted context omitted.

In many (all?) unix shells, globs are expanded by the shell before being passed to the program. 'ls *.jpg' is passed expanded to 'ls 1.jpg 2.jpg 3.jpg' BEFORE ls is run. This choice means that if a program wants to use another style of regular expression (ie: pcre), it must be enclosed in quotes on the shell, ie: "ls | grep -P '.*jpg'"

Minor point: if the glob doesn't match it isn't expanded. Sometimes useful. I rarely escape scp commands for instance.

See `failglob' elsewhere on this page. What you suggest is sometimes useful but also sometimes wrong and hard to spot because the glob might match locally and one not realise.

Re: Command line tools for the novice

#47

Post by johncoltrane »

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.

Re: Command line tools for the novice

#48

Post by ralph »

dredmorbius wrote: post #32
morsch wrote: post #24

Earlier quoted context omitted.

Contrast rebellion refers to W3C's Web Content Accessibility Guidelines , which specify a contrast ratio of at least 4.5. Just for fun, I plugged in the numbers, the site has a contrast ratio of about 4.9. W3C: http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contr...

It's not nearly enough for my liking. I'll take a look when I've got a few more moments to see where various of the W3C's recommendation levels fall on my own assessment of readability. Speaking as a 40-something with decent vision, the site isn't impossible to read, but it's most definitely annoying. For someone with compromised or old eyes, it would be much worse.

I agree, annoying, and I didn't realise many others thought the same. Thanks for the link, I've tried to spread the word. https://plus.google.com/115649437518703495227/posts/iWtSJhR8...

Re: Command line tools for the novice

#49

Post by dkersten »

spudlyo wrote: post #39
shurane wrote: post #37

Earlier quoted context omitted.

Yeah, I don't like it when people spout speed comparisons without backing it up either. A lot of people do want/need PCRE, which ack relieves the pain point for.

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…

htop over top, tmux over screen, zsh over bash, and postgres over mysql

That doesn't seem like a good comparison to me. I use htop over top because it has features that top doesn't have (the funky coloured ASCII graphs). I use tmux over screen because unicode seems to work without any effort on my part. I use bash because I have never looked at zsh in detail and don't care enough. I use postgres because I like its license better than mysql and its not controlled by any one company.

So its not at all about the perception that one is significantly better than the other, at least for me, its about specific features (license is a feature). Or in the case of zsh vs bash, where there are no specific features, I use bash because it seems to be the default on most distros.

Re: Command line tools for the novice

#50

Post by antidoh »

spudlyo wrote: post #39
shurane wrote: post #37

Earlier quoted context omitted.

Yeah, I don't like it when people spout speed comparisons without backing it up either. A lot of people do want/need PCRE, which ack relieves the pain point for.

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 like ack because I like the output format better.
Post reply on HN