... because they *should* help you automate things, but it never seems to work out that way.
I've been doing data analysis on large batches of data files (100's, not 10's, not 1000's) lately, and while I've written an IDL program to do the fitting, plotting, and output of parameters I need, there remained a few tasks that I couldn't figure out how to automate:
- prepare the batch file (unfortunately, the files are not entirely sequential, so it's not that easy to automate... I could pull some trick with getting a file list and going from there... but...)
- convert all of the .eps files that IDL outputs to .pdf so that I can actually use/view/print them
I decided not to bother about the batch file, it didn't really take that long, and once made I save it and never touch it again. BUT the only way I seemed to be able to convert the eps to pdf was to open all the eps files in Preview (it converts them on opening) and then save each of them. This is fine for a few eps (or ps) files... but when you have a 136 staring you in the face and know there are more to come... and that each one involves pressing command-w, enter, enter, you want to find a way that avoids causing tendonitis. Seriously.
First I turned to Automator (I'm a Mac user... unfortunately my solutions will be less than helpful for Linux users, and nearly useless for Windows users... sorry!). To be fair, I have actually managed to get Automator to do some useful things recently, but usually my encounters with the cute little robot leave me feeling rather let down. A quick perusal turned up what I thought was true anyhow, that Automator has no built in way to convert eps (or ps) to pdf. I also checked the Apple Automator downloads and Automator World to no avail.
So I thought, hey, I've got unix commands up the wazoo on here, there *must* be one that can convert eps to pdf...
excellent. So I pull up the man page, figure out how to use it, test it on a couple of files, and merrily enter:
uuh... geeee... that was fast. A quick "ls" showed me why... it only did the first file. Bugger. A bit of frigging around later, it was determined that pstopdf does not take multiple file arguments.
Ok. That stinks, but maybe now Automator can do something for me using the action "Run Shell Script". Yes, that's it, I'll grab the filenames with a "Find Finder Items" input it to "Run Shell Script" to run the pstopdf command, and voila, there will be 136 pdf's waiting for me. Right? Well not so simple, but yes, eventually. The two main quirks I had to overcome were:
- Apparently at some point the file output and file input of "Find Finder Items" and "Run Shell Script" became mismatched. Oddly this can be solved by inserting a "Label Finder Items" between (you can select none, so it appears to do nothing) which mysteriously does indeed change the file listing in the correct manner.
- When using the "Run Shell Script" action: do not enter anything into the script box until after you selected how you wish to pass the input from the previous action. That little drop down will insert the necessary script fragments you need to work with, but only if the box is empty. Since I tend to dive in, I of course immediately put my command in before selecting this, and got very frustrated very quickly.
- Also, since the pstopdf command only takes one input at a time (and I couldn't get it to work with stdin, though the man page claims it should function) I used the "Pass input: as arguments" option and placed the pstopdf command inside the loop with "$f" as the argument where the input file should go. If you have a command that takes multiple inputs, you *should* be able to use "$@" outside the loop.
Long story short, I'll make available to you, the fruits of my frustration, all for the low, low price of *FREE* (err, uhh, and listening to my rant)... better yet, I'll include my other workflows that I've been using:
- Automator workflow to convert eps (or ps) to pdf (can also be saved as a Finder action)
- Automator workflow to take all pdf files in a folder and merge them into a single pdf
- Automator workflow to take text files, cut out the header and combine them into a single text file (this one will take some tweaking of the inputs the actions have... easy stuff, just change the drop downs and fields you need)
Since some people were having trouble downloading the workflows above, I've put the workflow to convert eps to pdf and to combine pdfs into a zip file for download: PDFworkflows.zip
Is that all? Oh no... no, no, my friends. I started many hours ago, this morning, with IDL opening into an xterm completely UNCONFIGURED for my needs. Let's look at my "needs":
- Something more readable for my not yet caffinated eyes than black on white (I like a nice soothing green on charcoal... reminds me of that old Apple//c we had when I was a kid)
- More pressing: a bigger window (ok, I can drag and resize, but sometimes funky things happen when I do that)
- And pure luxury would be a SCROLLBAR... yes I like to scroll, especially when I'm running batches of 136 files and I'd like to look at some of that output.
Is that too much to ask? I have my X11 configured to open an xterm that is more pleasing on the eyes, but since IDL launches it's own xterm from a mini-app, and I couldn't find where it actually did that anywhere I was stuck with what it gave me. Until today people, until today. All one needs to do is create a default xterm style you are happy with and then any program launching it's own xterm will use this default style. The trick is simple: create a .Xdefaults file in your home directory. The bits of code I used were:
I got most of the commands from here and there is an xterm color table here. Now it looks like this:
Now go make a beautiful, scrollable xterm and make me proud... I have to believe I didn't waste my day in vain.
And convert some eps files to pdf while you're at it. Hell, convert a whole bunch of them and put them together into one gigantic pdf!
Because today, I got my computer to do what I wanted it to do... It just took a really long time.