I'm reminded of this very amusing C++ compilation speedup trick: cat * > everything.cpp - http://stackoverflow.com/a/318495/3229684 http://stackoverflow.com/a/3

I'm reminded of this very amusing C++ compilation speedup trick: cat * > everything.cpp - http://stackoverflow.com/a/318495/3229684 http://stackoverflow.com/a/318495/3229684 --- Also, I tend to do all my work using a realtime-feedback model like this. I discovered inotifywait a few years ago, and consider it to be the coolest thing I've discovered. Using a loop like: while true; do clear; ./program; inotifywait -qq -e delete_self program; done I run my program, then sit waiting until I re-save it, at which point I run it again. This approach is very flexible; the example above works for shell scripts, or I can do "gcc -o file file.c && ./file", or I can do "node file.js", or whatever. Switching the sequence around I can have inotifywait pause before the first execution too, but I prefer the method above. I occasionally substitute "clear" for "tput reset" so I can wipe my scrollback and shift+pgup stops at the top of the current execution. There are some caveats though. The biggest is that this approach doesn't work too well for things that need to be killed to be restarted, like socket servers; that's fixable but nontrivial and likely project-specific too. The second problem are the race conditions that will likely arise between your editor's slow file-save process and inotify's fast response time, producing irritating "File is in use" errors 50% of the time (since inotifywait exited, bash looped, and ./program is trying to be read by your compiler or interpreter while still locked by your editor). The DELETE_SELF inotify event is specific to the Geany text editor; when Geany saves a file it does quite a few operations, and DELETE_SELF is amongst the last (but inotify doesn't see any of the following events since DELETE_SELF marks that the file - that inotify was watching - got deleted; this is thankfully coincidental with Geany being done with the file). You'll need to do something like "inotifywait -m program" and watch what events occur; inotifywait exits on the first event received; hopefully there's a lone unique event at the end of the sequence. Worst-case scenario you might have to add in "sleep 0.05"; I have not tested the success of prefixing the compilation step with something like "while [ ! -r program ]; do true; done".