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

Unix tricks

mmb.pcb.ub.es

Post reply on HN
Print view View original

131–140 of 232 posts

Re: Unix tricks

#131

Post by inyourtenement »

kbenson wrote: post #115
inyourtenement wrote: post #97

Earlier quoted context omitted.

rsync is slow if the data is not already on the destination. tar over ssh is fast, and tar over socketpipe is even faster but not encrypted. I'm not aware of any attributes that tar doesn't preserve.

How so? Also, I find that if I'm going to copy the data once, I'm often going to copy it twice, or which to get a more up to date version of it at a later time. Rsync clearly wins in these cases. Finally, from the compress flag on rsync: Note that this option typically achieves better compression ratios than can be achieved by using a compressing remote shell or a compressing transport because it takes advantage of t…

Exactly right. In my use cases, it's best to tar over ssh initially. Then, if I ever want to update the copy, rsync.

Re: Unix tricks

#132

Post by dunk010 »

pavel_lishin wrote: post #26
nathanstitt wrote: post #15

Whut? ctrl-r? How have I missed that? No more 'history|grep foo' for me!

Try this in your .inputrc: # Bind the up arrow to history search, instead of history step "\e[A": history-search-backward "\e[B": history-search-forward No more "^rls" to search for ls in your bash history; just type "ls" and start hitting the up arrow.

This is the best tip ever.

Re: Unix tricks

#133

Post by ninetax »

firebones wrote: post #37

Wanted: a lint for your history that analyzes your commandline usage, suggesting these types of tips based on your historical use. history | commandlint

Where can I find commandlint?

Re: Unix tricks

#134

Post by dunk010 »

Here's a really great presentation I found (probably on HN) some years ago. http://www.ukuug.org/events/linux2003/papers/bash_tips

All extremely useful, my favourite being the .inputrc rebindings of up and down to search history. Takes a little getting used to but is great once you are (good luck to anyone else trying to use your terminal though ;))

Re: Unix tricks

#135

Post by signa11 »

growt wrote: post #54

If I may add a trick: ctrl-z - stops a program bg - sends the stopped program to the background fg - gets the program back to the foreground (interactive mode) very useful in editor sessions or when you want to get rid of the endless download/scp that is blocking your terminal

i normally have this :

fork() { (setsid "$@" &); }

in myzshrc, and then start stuff with :

fork firefox

Re: Unix tricks

#136

Post by nathanstitt »

pavel_lishin wrote: post #26
nathanstitt wrote: post #15

Whut? ctrl-r? How have I missed that? No more 'history|grep foo' for me!

Try this in your .inputrc: # Bind the up arrow to history search, instead of history step "\e[A": history-search-backward "\e[B": history-search-forward No more "^rls" to search for ls in your bash history; just type "ls" and start hitting the up arrow.

Thanks for the suggestion. I used to have a very customized .bashrc with nice little things like that, but have decided to stick with standard stuff for things that work off of muscle memory.

I got tired of sshing into a new box and half the things I'd type wouldn't work properly until I remembered to copy my settings files over, which seemed more trouble than it was worth for a short-lived s3 instance.

That's why I was excited to discover ctrl-r. It's a built-in method of searching history that I can remember and it'll work everywhere.

Re: Unix tricks

#138

Post by LukeShu »

woodchuck64 wrote: post #120

zsh: setopt extendedglob allows you to use numeric ranges on globbing with : mv p1080 .jpg folderx/ to move p1080100.jpg through p1080300.jpg to a new folder. Still not available on bash or more common shells?

Bash:

    mv p1080{100..300}.jpg folderx/

Re: Unix tricks

#139

Post by LukeShu »

jcr wrote: post #81
neoteric wrote: post #76

Earlier quoted context omitted.

This is simply not true: $ mkdir '; echo woops' $ find . -type d -exec echo {} ';' . ./; echo woops As you can see 'woops' is never echoed. EDIT: The reason being the shell is never involved in this process, and the shell is what is responsible for splitting commands on semicolons/newlines.

You are assuming the exact versions of the shell and find programs that you use are the only ones that exist. It may not be a problem on your exact system, but it can be a problem elsewhere.

It's not a problem with GNU or OpenBSD `find`, and I'm pretty sure that's the case for FreeBSD too. What version of find uses system(3) instead of execv(3)?

Re: Unix tricks

#140

Post by stevvooe »

enigmo wrote: post #100
stevvooe wrote: post #72

Earlier quoted context omitted.

Sort will actually externally sort blocks into temp files and merge them. Adjusting this block size can help with thrashing. Awk may still be better for uniquification.

What about 'sort -u' ?

I'm not sure. I haven't closely studied the difference between each algorithm. My guess would be that sort -u would perform better as the data set gets larger with a good block size setting because it does do an external sort. Cardinality would also affect the performance. If the unique set handily fits in memory, an external sort on a large data set wouldn't be very efficient.
Post reply on HN