What I’ve done in my .bashrc (see my dotfiles) is defined a shell command
r that invokes
rake depending on the arguments given. If your argument to
new, or the one-letter aliases for those, the
r command assumes you meant to invoke
rails, and does so. Otherwise it assumes you meant
r db:migrate == migrating....
r db Welcome to psql 8.3.17, the PostgreSQL interactive terminal.
r s => Booting WEBrick
Short and sweet. No more fat-finger mistakes.
script/rails or bundle exec rails?
You’ll notice that
r also chooses between using
bundle exec rails. In general, I’ve learned to always use bundle exec to ensure correct behavior of executables in a Rails project. But this is actually overkill for the
As it turns out,
bundle exec rails simply invokes
script/rails, which in turn initializes Bundler anyway. So
bundle exec rails therefore runs Bundler’s setup twice, and for no good reason. (Actually, Bundler.setup is invoked three times!)
In fact, in my testing
script/rails is up to 1 second faster than
bundle exec rails. The upshot is that the
r command should prefer to use
script/rails if possible.
script/rake file is not included in standard Rails projects, but you can use the same trick to get a 1-second boost over
bundle exec rake. This may qualify as a hack, so proceed with caution.
And don’t forget:
chmod a+x script/rake
Pretty straightforward, right? I find that this simple
r command is now an indenspensible part of my Rails toolkit. Compared to straight up
rake, it’s fewer keystrokes, fewer mistakes, and a bit faster to boot.
Suggestions? Discuss the Gist on GitHub.comments powered by Disqus