When creating a command line tool, you quickly are faced with the burden of handling command line arguments (parsing options, arguments, flags, etc).
In Python, the optparse module or, its newer version, the argparse module are very nice solutions to build powerful command line interfaces, completely with automatically generated help.
Sometimes however, you just want a quick, simple and small way to get from A to B without a lot of overhead and overkill. Below I'll show you a quick and simple Python trick for command line handling by directly mapping the command line arguments to function arguments.
Gearman (job queue manager) command line tool: routing the workload to the worker process arguments with xargs
Gearman provides a basic command line tool that helps to distribute work from clients to worker processes/machines. By default the worker process can only receive data from its standard input. With the
xargs tool we can circumvent this and route data to the process arguments of the worker process.
Occasionally, I have to convert a PDF file to Postscript (e.g. for subsequent processing with some PostScript utility). In the Linux/command line area, I know two options: pdf2ps and pdftops. I also know that one of the two
sucks has some issues and the other is better. But because their names are so close I can't manage to remember which one to take. This post should put an end to that!
[Spoiler alert and a questionable mnemonic: pdftops is da top.]
I spend a lot of time on the (bash) command line in (Linux and OS x) and it's always good for productivity to have your favorite set of shortcuts, aliases, perferences, predefined (environment) variables and such at your fingertips. You know, all the stuff that lives in
I have access to several systems (at home, at work, remote servers, etc) and from time to time I'm sitting behind a system that doesn't know my preferences yet. I considered using some sort of version control system to "synchronize" these preference files between my setups, but (apart from the practical hurdles) it generally seemed overkill, especially since each setup can have its own peculiarities and customizations.
So, mainly for my own reference, I'm keeping an list of the most important general stuff here. Be welcome to cherry-pick (or suggest additions).
Bash scripts are handy for putting a bunch of longer running jobs in one batch. In some occasions it can be useful to know which command is running at the moment, especially when the commands do not generate output themselves or this output is redirected to files.
Bash has a simple setting to achieve this:
which, according to
help set, enables the following feature:
-x Print commands and their arguments as they are executed.
Disabling it just takes a mere
You can play with it from the bash command line itself, or put it in a bash script of course.
If you're not afraid of a a bit o' Unix/Linux/OSX command line delight, you're probably having
grep hanging on your tool belt.
One option you'll wonder how you could live without is
--color, which enables highlighting of the word or pattern you are grepping for. I find it so useful that I've put the following alias in my
alias grep='grep --color=auto'
Yesterday I had to render a 3d animation for a colleague working on 3D television. He needed a short street-view video with depth map. Because there were some problems with some real world footage he wanted to use, he asked me to create an artificial video in Blender. After I created a simple scene with some models from www.katorlegaz.com, I wanted to render the whole animation overnight on one of the computers in our lab. I had some trouble with getting the command line arguments right and wanted to share this, in case someone else has the same problem.
I first tried
blender -b -a foo.blend
-b is for background mode, so I could log out from the computer after I started the job, the options
-a is for (according to the command line help):render frames from start to end (inclusive), only works when used after -b I thought this was the bare minimum to get the job done. However, nothing happened but this:
Compiled with Python version 2.5. Checking for installed Python... got it! ERROR: No camera Blender quit
Huh, no camera? There was an active camera, the scene rendered just fine from the UI, I checked my file over and over and everything seemed all right.
When you want to extract a bitmap image from a PDF document, it is tempting to do the "print screen" trick. The drawback of this approach is that you'll inevitably lose quality: the image pixels will typically not map to your screen's pixels in a one to one fashion because of the decimation/resampling/scaling (or even rotation) when viewing the PDF document.
There are probably a lot of tools extract the bitmap image correctly out there. I guess this functionality is built in in Adobe Acrobat reader. But if you're in my situation (no desire to use Adobe's bloat) or you just need a small handy command line tool for linux (or other "unixes"): try pdfimages. It's part of the xpdf package, which is probably available for all major linux distributions.
Usage is very straightforward:
pdfimages -j foo.pdf bar
This will extract all images from
foo.pdf and save them in JPEG format (option
The default install of gnuplot in Ubuntu/Debian does offer a crippled form of word completion, when compared to other distribution (Mandrake, Suse). For example, filenames can not be completed with pressing
tab, which can be really annoying if you're used to have this sort of completion. The reason for this is some licensing issue with the readline library. A workaround is to compile Gnuplot with the right tweaks, but this is to much hassle for what it's worth for me.
Another solution, which can also be applied to other applications, is rlwrap. It's just a simple
sudo apt-get install rlwrap away (with uni/multiverse repositories enabled).
Now I have filename completion in gnuplot with:
rlwrap -a -c gnuplot
And if you're not so keen on remembering this, just add the following alias to your
alias gnuplot='rlwrap -a -c gnuplot'