Marin

Also its worth saying that cat < testfile also reads the file but while opening it with bash and piping through cat rather than cat opening directly.

Well a primitive isn't an object, that's when mutability matters. Look up how HashMaps and Lists work, those are the objects that are very concerned with mutating state.

For example if you have a method that takes a primitive:

public void foo(int i)

the primitives will be as you say "mutated". But thats no mutation, it simply means that into the function these variables's values are passed (ie, they are copied). It really doesn't matter because these copies go away the moment the function ends, it isnt something that needs to be garbage collected. In fact a variable like this will most likely end up in the CPU's cache, and not in ram.

It isnt strictly a performance thing, its how the data structure behaves. Mutability is a huge topic when talking about sharing state in a multithreaded application.

Another good way is to write your query as an $elemMatch and then update the matched record. This will become something like contribs.$.fieldtoupdate to point to the matched element. This is useful when dealing with an array of objects where elemMatch needs to match an embedded field.

This is also annoying when using say morphia, that tries very had to not let you do complex queries like this so that it can keep its object model properly. Its possible but you have to use its funky syntax.

It runs mysqlbinlog with 30 minutes ago (that's what the D variable and --start-datetime does). Then it watches mysqlbinlog rerunning every two seconds and tailing the output.

ctrl+w =

my favorite, re-sets all your splits to the same size

To be fair the conflict is trivial to avoid... link to a binary thats named something else.

that link?

Sometimes its nice to do it without the stderr redirection (the 2>&1 part) and still see problems while its running. Even if its forked stderr will show in your shell. Same for cron, you wont loose those messages (will be in log).

Don't get me wrong, I didn't mean to trash your tip. In essence I agree with you. Just there are limits to how much things should be abstracted, part of what makes scripting languages great is that they produce short and simple code to do one thing and one thing only.

But how many shell scripts have truly reusable functionality? I am a firm believer in no abstraction until abstraction is needed. To me nothing should be written as if its a library until the second (even third) time you need to use it, that's how I GSD. For one thing, that gives you two use cases, instead of trying to imagine a second use case.

When I run into situations like this I write the "library" code in something else, something that's more portable and easier to maintain, then call its functionality from the script. Not only is it a faster script (evaluating a shell script isnt exactly fast) but its a good separation of concerns.

There is literally no reason to do this for just about any shell script, especially not the eval bit. Functions are great, and use them, but no reason at all to mix patterns from other languages that have a real purpose for a main() function

# script pattern
foo() {}
bar() {}

# take some input, decide what to do with it
foo

btw this will work on practically any distro and probably BSD, not Ubuntu specific at all

@azulinho you could ssh as root

You can also have vim not save swap altogether:

:set noswapfile

wizard

@jkirchartz most people may already know about play.golang.org but its a good resource. It can also be ran locally using godoc.

awesome

You can also generate different keys for different servers, instead of using id_rsa. In .ssh/config where your host is configured you can add an entry like this:

IdentityFile ~/.ssh/some_other

I find Nick changes annoying too, adding NICK fixes that as well. Great tip!

I agree with oz, also sometimes its a matter of principle/rest of the codebase has function comments. I recommend writing function comments in a way that they are unlikely to change. Commenting on what a function does is great, commenting on "how it does it" leads to the problems you are discussing when the implementation changes.