Stupid Unix Trick – Command Mashups
I've been a *nix Administrator in some form or fashion for about 10 years now. I remember back when I was first learning commands and how the OS works and every once in a while I'd come across something stupidly simple yet extremely useful to put in my bag of tricks. Yesterday I was reminded about one of those things and I figured I'd share it here so that you can throw it in your bag of tricks as well if it's not already in there.
To start out, let me illustrate the problem. You are writing a shell script or running a series of commands on the CLI. Let's just say it's something simple like creating a new directory, changing to that directory, and then creating a file. When I first started out, that command would look something like this:
mkdir newdirectory; cd newdirectory; touch newfile
The problem with this is that each command is executed on it's own regardless of whether or not the previous command was successful. So if, for example, my mkdir and cd failed (permissions maybe?), I would be creating that newfile in whatever directory I started out in. At best, I just created a new file in the wrong directory. At worst, if the file which I'm creating was the same name as another file already in the current directory, I just overwrote it. Not good!
The way to fix this is to add a dependency so that each command will not execute without the successful return of the command before that. The way you do this is by putting an "&&" between them instead of the semi-colon. So now the command string above should look like this:
mkdir newdirectory && cd newdirectory && touch newfile
Now you have guaranteed that the new file will not be created with the touch command unless both the mkdir and cd commands before it are successful. Stupid simple, right? Enjoy!
Recent Posts
- Static Application Vulnerability Testing: Binary Scanning vs Source Code Scanning
- Auditors Just Don’t Understand Security
- Looking for DevOps Stuff?
- Our First DevOps Implementation
- dev2ops Interview
- Amazon Web Services – Convert To/From VMs?
- Come to CloudCamp Austin 2!
Recent Comments
- John Sapp on Static Application Vulnerability Testing: Binary Scanning vs Source Code Scanning
- Ernest on Microsoft Azure for Dummies – or for Smarties?
- Josh on Static Application Vulnerability Testing: Binary Scanning vs Source Code Scanning
- Glenn on Microsoft Azure for Dummies – or for Smarties?
- Erik on Microsoft Azure for Dummies – or for Smarties?
- Don Jackson on Auditors Just Don’t Understand Security
- Josh on Auditors Just Don’t Understand Security
- Don Jackson on Auditors Just Don’t Understand Security
- Don Jackson on Auditors Just Don’t Understand Security
- Don Jackson on Auditors Just Don’t Understand Security
devops
- Agile Operations Blog
- Agile Testing
- Agile Web Operations
- dev2ops – Web Ops at Scale
- Kitchen Soap, A WebOps Blog
- The Madstop
- The Open Minded Enterprise
- The Simple Logic
Links
- Amazon Web Services Blog
- Gilligan on Data
- National Instruments Home
- Server Fault
- Steve Souders’ Blog
- Transparent Uptime blog
Security
Tags
Categories
- Advertising (2)
- Application Performance Management (14)
- Automation (4)
- Browsers (4)
- Cloud Computing (9)
- Conferences (60)
- OWASP AppSec DC 2009 (16)
- OWASP AppSec NYC 2008 (18)
- TRISC 2009 (8)
- Velocity 2008 (8)
- Velocity 2009 (8)
- Content Management (2)
- Featured (3)
- Green Computing (1)
- High Availability (1)
- Log Management (2)
- Management (2)
- Monitoring (2)
- Networking (3)
- Firewalls (1)
- Operating Systems (1)
- Operations (9)
- Popular (2)
- SaaS (2)
- Sarcasm (1)
- Search (1)
- Security (50)
- Cloud Computing (4)
- Compliance (1)
- Metrics (2)
- PCI (2)
- Phishing (1)
- Virtualization (3)
- Web Application Security (29)
- Dynamic Analysis (1)
- Static Analysis (1)
- Wireless Networks (2)
- Service-Oriented Architecture (1)
- Software and Tools (10)
- Training (1)
- Uncategorized (1)
- Virtualization (4)
January 30th, 2010 - 15:38
Relying on non-zero-exit is such a great idiom and its consistent use will add up to more reliable and predictable outcomes. It’s especially important when one script relies on calls to another.
Along with the “&&” (and) expression, I also like to use the the “OR” expression to manage error cases. For example this usage:
statement1 || or-statement
This will cause the “or-statement” to run if the “statement1″ command fails (ie, exits non-zero).
One can combine the “OR” and “AND” expressions with code blocks for a short hand if/then/else syntax
statement1 &|| {
else-statement1; else-statement2
}
Here’s a concrete example that checks if an error string is found in a log file
grep ERROR /path/to/log &|| {
echo “error found on `hostname`:/path/log/log|mail -s “error detected”
exit 1
}