31–40 of 59 posts
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 reason for using iTerm2 is over Terminal?
Grey text on grey background: http://contrastrebellion.com/
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...
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.
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…
..plus Ack is 4 or 5 times faster than grep.
Ack is implemented in Perl, which has a full featured regex engine, but is not generally known for being super fast. It's going up against GNU grep, which is a highly tuned regex engine, which is very fast. The ack guys make the argument that ack is faster because it doesn't search stuff you, the developer, don't care about, which in my estimation is horseshit. Try it yourself, I threw a regex at my email spool from the 90s which is about 128M. I made sure it was in disk cache first and then did:
chunky:~$ time egrep -c -i '(d|m|j)ingle' RMAIL
23
real 0m3.129s
user 0m3.075s
sys 0m0.051s
chunky:~$ time ack -c -i '(d|m|j)ingle' RMAIL
RMAIL:23
real 0m26.208s
user 0m26.060s
sys 0m0.121s> 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."
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 named * .
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…
I knew before I even clicked on this article, that something inside was going to cause me nerd rage; it's almost always the case when I read these Baby's first UNIX type articles. I thought this one might be different when I saw Andy's formidable neck beard, and for the most part it was decent but then I saw it. ..plus Ack is 4 or 5 times faster than grep. Ack is implemented in Perl, which has a full featured regex e…
A lot of people do want/need PCRE, which ack relieves the pain point for.
Earlier quoted context omitted.
I switched cold turkey from bash to zsh a few months ago, and going back to bash on servers hasn't been a problem. In my experience, if you've used bash for a long time you don't forget it. Minor tip - you can use the same .aliases file for both shells, I just source it in .bashrc and .zshrc on my dev machine. So if I ever need to switch to bash for some reason, my most used aliases are still available. If you switch…
I'm actually not very taken with oh-my-zsh. It seems to add a layer of complexity while not really adding anything you couldn't just paste into your .zshrc. If it eliminated tinkering overhead that would be one thing, but in my experience it just gave me a new layer of software that needed tinkering.
I knew before I even clicked on this article, that something inside was going to cause me nerd rage; it's almost always the case when I read these Baby's first UNIX type articles. I thought this one might be different when I saw Andy's formidable neck beard, and for the most part it was decent but then I saw it. ..plus Ack is 4 or 5 times faster than grep. Ack is implemented in Perl, which has a full featured regex e…
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.
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
Earlier quoted context omitted.
I've been on zsh for ages, and the thing that always kills me dead when stuck in bash is the terrible default command line editor. Whereas in zsh, if I go back to edit a multi-line loop or something, it preserves the white-space, bash by default presents the commands as a semicolon delimited list on one line. That's ass. Is there a handy bash shortcut to mimic zsh's behavior here?
How I wish there was a better language for interacting with Unix command line utilities than the godawful POSIXy shells.