Welcome to Terminal Tips, a series where we’ll be sharing some shortcuts and tricks we’ve picked up along the way as we use the command line. Today’s post covers a command that is more frequently associated with a text editor than the command line: “Find and Replace”.  If you need to do a find and replace on a file, especially a large file, it becomes cumbersome to do so in a text editor. Github’s new editor, Atom, won’t let you open files larger than 2MB as of the time of this post.

So let’s say you have a CSV file with a couple hundred thousand rows and you want to change any occurrences of the string ‘old’ to the string ‘new’. You could do this using a word processor or an editor, but it would likely crash before you even got the file open, or it would take forever to actually perform the find and replace. What you need is something that gets the job done without all the overhead of an editor. This is where sed comes in.  A quick look at the manual for sed tells us:

The sed utility reads the specified files, or the standard input if no files are specified, modifying the input as specified by a list of commands.

(If you want to read more, open up the Terminal and run the command ‘man sed’ without the quotes)

So now that we know what we’re working with, let’s start to construct our command.

From the man page, the -i flag edits files in place, allowing you to specify a backup. If you’re not concerned about running out of disk space this isn’t absolutely necessary, so we’ll just leave that blank for now.  Our command now looks like:

sed -i ''

Now we actually have to specify the text we want to find and replace. If we want to replace the word old with the word new, we need to construct a suitable expression to tell sed what it is looking for:


From the manual, the -e flag will “Append the editing commands specified by the command argument to the list of commands.” Sounds perfect.  Our command now looks like this:

sed -i '' -e 's/old/new/g'

Now all we have to is specify the path to the file you want to run the command on.  If we had a CSV file called list.csv in our current directory, we could just append that to the command. Now we have:

sed -i '' -e 's/old/new/g' list.csv

When we run this command and go look in the file, we can see that all instances of ‘old’ have been replaced with ‘new’ and you’ve learned a new shell command!



Extra Credit

What if you wanted to find and replace a URL? You can’t use a slash as the seperator character, because there will most likely be slashes in your URL. sed uses whatever follows the ‘s’ in the regular expression as the seperator. So, for example, we could use a comma as a seperator.

sed -i '' -e 's,http://www.oldurl.com,http://www.newurl.com,g'

We can really use any symbols we want.

sed -i '' -e 's#http://www.oldurl.com#http://www.newurl.com#g'


Keep an eye on the blog in the coming weeks for more Terminal Tricks!


It’s a dreary Thursday afternoon, so naturally, music is necessary. Ever the aesthete, Doejo creative director, Garrett Galayda, was kind enough to show me this customizable Soundcloud player, courtesy of ToneDen. A departure from the standard waveform, this plugin makes me want to just stare at my music. Check it out.

Matt Lissner

This is the sixth article in our “The 12 Dos and Don’ts of becoming a Web Developer” series.

“Fine,” you tell me.  “I won’t get caught in tutorial paralysis.  So what do I need to do?”

Set up a Github account and push some code, young padawan.  It’s that simple.

It doesn’t matter what you’re working on; create a repository for it, commit it, and push it to Github.  It doesn’t matter if it’s good or not; you can always go back and improve it later, or leave it as-is and push something better to a new repository next time. Once you figure it out, it will take you an extra 30 seconds every hour or so to do this, but the benefits are pretty great:

1) Remember when I said you need a solid grasp of Git?  Here’s your chance to practice.  Initializing a repository, adding your changes, committing them with a descriptive message, and pushing them to a remote repository (such as Github) should all be second nature to you.  That way, when you start working on a team and need to handle more advanced concepts like branching / merging  / rebasing, soft and hard resets, cherry-picking, etc., you won’t feel totally overwhelmed — or, worse, break something and have to spend an hour figuring out how to undo it.

You’ll be able to turn a moment like this:


Into a moment like this:


2) Employers love to see that you’ve been active on Github.  From my experiences with hiring and conversations with other developers, I’d say that having an active Github profile will not only move you to the top of the pile but probably put you in the top 10-20% of applicants.  It shows that you not only know what the hell you’re doing but also gives us a window into how you solve problems.  Github alone may not get you a job, but if you have an active profile, it’ll definitely get you some interviews.  That’s where you get to kick ass, take names (literally.  Get business cards.  You’ll never know when you’ll need them), and show what an awesome member of the team you’ll be.


3) You never know when you’re going to need old code.  Perhaps you’re trying to remember how you made a full-size background image resize properly on a website you built six months ago, but you can’t recall exactly how you pulled it off and you need to do it again for a new site you’re working on.  You can either a) spend an hour or two Googling how to do it and trying to re-implement it or b) take a peek at your Github profile, grab the code, and adjust it for the new project.  Having tried-and-true code snippets at hand will save you a lot of time.


One final protip before you go: commit early, commit often, and leave yourself descriptive messages about what you actually did (no “updated css and lots of other changes” crap).  When you break something (and you will) and need to revert to an earlier commit, you’ll be glad you did this.  What I like to do is, before I sit down and write a single line of code, think of my commit message in terms of my tasks ahead of time; if my commit message involves the word “and” too many times (“updated styling of h1 on front page AND repositioned contact box AND performed data-sanitization on contact box”), I know I need to be vigilant about breaking it up into multiple commits.  You’ll make your life a lot easier, trust me.

Most of the resources I linked in my earlier post cover Git in some shape or form, but here are a few additional (free) resources to check out:




One more thing before I sign-off (I’ve said it before, but it bears repeating): invest the time to learn Git in the command line.  There are programs out there (such as Sourcetree) that will handle a lot of the heavy lifting for you, but they also make it much, much easier to screw things up (as one unfortunate developer in my acquaintance learned recently, when he accidentally deleted most of his hard drive.)  The command line is a powerful tool, and even though it’s super intimidating at first, it won’t take you long to become familiar with it — as long as you take the time to learn it.

Articles in this series:

Samantha Geitz

It is with great gusto that Doejo gets to share with you the launch of our latest creation, a new and improved consequenceofsound.net.  We have been privileged to work with the fledgling online music publication for over 4 years and this new UX project has been in the works for over a year now.

For the uninitiated, Consequence of Sound is probably the best rock n roll website on the net—IMHO, better than RollingStone, cooler than Pitchfork.  CoS overflows with great content, news and opinion but spares you the snark, attitude and arrogance of their elder rivals.  Boasting millions of visitors each month, this project was deployed on WordPress.com VIP.

Consequence of Sound is now mobile responsive and will look just as great on your iPhone or Android phone as it does on the web,” CoS creator Alex Young wrote in a column announcing the re-launch. “The homepage is easier to navigate, our content is better presented, and Festival Outlook has been completely revamped.”

We’re still working with CoS to roll-out new features in the coming weeks, including the ability to personalize the homepage.  “In other words, if you no longer want to see stories about Kanye West, you no longer have to see stories about Kanye West.”

But go ahead and check it out for yourself.  This is one of Doejo’s biggest and stunning projects to date.  We’re proud of our team and the work put forth, and psyched to have gotten the chance to make waves with such a groovy music site.  Rock N Roll Never Dies.


This is the fifth article in our “The 12 Dos and Don’ts of becoming a Web Developer” series.

So you’ve checked out a few of the resources on my list.  Great!  You’re well on your way to becoming dangerous as a web developer.  However, there is one thing that you are undoubtedly going to want to do, and I’m here to tell you not to do it.

Don’t get caught in tutorial paralysis.  Seriously.  Don’t do it.

What is tutorial paralysis, you ask?  When you’re first learning, tutorials are safe.  You have a friendly instructor telling you what to type in your text editor or command line, making sure you don’t have to think too hard.  You can finish a tutorial series in a few hours or a few days, and you’ll feel really proud of yourself for sitting through it, for learning.  You feel like you’re really getting a handle on this web development thing.  At that point, the friendly instructor will usually tell you what course you should take next.  So you complete the next one, and you learn something a bit more advanced, and on and on until someday you actually have to build something.

That is generally the point where you realize that, despite the 50-100 hours of tutorial videos you’ve watched, you have no idea — none at all — how to actually build something on your own.  Cue the eternal despair of the dark night of your soul.


You can talk the talk, but at some point, you need to walk the walk.  The very, very best way to learn how to do something is to build something on your own, even something that you’re super ashamed of (but you won’t be. You’ll be proud of your creation, even if six months later you’ll go back and feel horrified by it.)  Tutorials are great to teach you the basics, but they will never, ever challenge you the way hacking together something on your own will.  If you’re not ready to bash your head against the monitor at least half a dozen times when you’re working on something while you’re learning to code, you’re not challenging yourself enough.  Don’t worry; for all the frustration, and the blood and sweat and tears, the feeling you get when something you’ve been fighting with for hours or days actually works is like a drug.  But, you know, in a good way:




Remember that feeling.  You’ll need it during the next dark night of the soul.

Check back next week, and I’ll give you some advice on what to do with all the awesome code you’re writing.

Articles in this series:

Samantha Geitz