Regarding Doc Searls' “Heavy Backup Weather” in the October
2012 issue: wait, you use Backblaze? They don't offer Linux support. I'd rather not
see references to services that are not available to me.
—
Josh
Doc Searls replies: You have a good point, and I'm sorry I didn't think about that before I wrote the piece.
We've wanted to put together some kind of backup that would work for both our Linux and Mac boxes, and for all three of our places (two temporary apartments and one house), as well as on the road. I've used Backblaze for my Mac laptop. I'll drop it.
Meanwhile, recommendations for backing up anything from any OS (starting with Linux), anywhere, over the Net, would be welcome.
I just wanted to send complements and thanks for the excellent article “Python Scripts as a Replacement for Bash Utility Scripts” by Richard Delaney in the November 2012 issue. He nailed it: good background, reasoning and explanations, well-chosen examples and clearly written sample code (the latter two often are disappointments in otherwise good articles about coding).
My only complaint is that I did have to print the article to paper to read it, as my old-geek eyes could not make out the sub-7-point light-blue font used in the e-version.
Python is currently one of my two favorite programming languages. The other is Ruby. As I read Delaney's article, it occurred to me that LJ could actually get two-fer-one mileage out of his contribution simply by doing a global search and replace of “Python” with “Ruby”, plus a small number of trivial changes to vocabulary and library references—with, of course, sample code in Ruby rather than Python. Voilà! A whole new, second article! (Might I get co-authorship credit for this edit if/when you publish it?)
My point is that there is practically complete functional equivalence between the two languages (pax, fellow aficionados/purists of either!), especially in this particular domain of Bash-replacement utility scripts. Ruby too has a very large and capable library, both standard and gems, for dealing with exactly the same kinds of problems that Delaney covers so well. For example, Ruby also includes a powerful OptionParser module (“optparse”) for handling command-line switches and arguments easily and generally. I know, I'm developing a large and ever-growing repertory of Ruby utility scripts, many of which are replacements and improvements of older Bash versions—the Ruby versions are much more readable, understandable, maintainable and expandable.
Either is an excellent choice in this domain. Ruby just happens to be my personal favorite, but others may prefer Python. Your mileage may vary, and I'm not trying to start a language flame war here. Interested readers may want to read David Bryant Copeland's excellent book Build Awesome Command-Line Applications in Ruby: Control Your Computer, Simplify Your Life (2012, Pragmatic Bookshelf), which explores this application domain in detail. He also covers and recommends “optparse” (OptionParser) to build truly powerful command-line utility apps.
With both Ruby and Python bulwarking good-old Bash, Long Live the Command
Line! Thanks again.
—
Lorin Ricker
Richard Delaney replies: Thank you very much for your letter. I think you bring up a brilliant point, and having had little real experience with Ruby, I can only take your word for it. Python and Ruby fill a very similar void in what they hope to achieve and make any “flame wars” between the two communities all the more illogical.
As you prefer Ruby, my preference is for Python, but only because I program with Python on a daily basis. The reality is that a number of these beautifully crafted languages, such as Python and Ruby, are almost drop-in replacements for one another. The interpreted, dynamic nature of both these languages along with other advantages, such as an REPL, makes their choice as a Bash replacement all the more enticing.
While selecting your language of choice for such things, it's also important not to ignore some of the more modern compiled languages. Slightly more abstract languages like Haskell provide a very elegant way to write programs, as well as the relative newcomer Go. Aspects like program readability, knowledge of the language and documentation often are more important traits for a programmer than the language itself. Thanks again for your kind words.
I am enjoying reading the November issue and enjoyed the article by Richard Delaney on using Python as a replacement/alternative for writing shell scripts. I wanted to pass on some comments on the same.
The idea resonates with me. Of late, I have resorted to writing Python scripts to perform tasks that usually would be done using shell scripts. My personal reason is that I am not good at Bash scripting and find all the $s and !s to quite cryptic. However, I feel that whereas that may be the main reason for me, it's actually a good thing, because I can implement what I have in mind really quickly, as I know Python well. For example, say I need to search across a huge code base for certain strings, and I want the paths of filenames where the strings occur. I used to try doing it using cat, grep and find, but usually the result turned out to be something I didn't like, or I had to search on the Web for solutions. So, I just wrote a Python script to do the job for me (https://gist.github.com/3759263). I have been using it ever since, and I am quite happy with it. Bash experts may replace my whole program by a single line, but I am not one of them, and I don't always like to search for solutions for which I know the logic, but am constrained by my lack of Bash scripting knowledge to implement the solution.
Thanks for your article. It was a good read. I would like to point
you to docopt (docopt.org), if you haven't heard of
it. It's pretty amazing.
—
Amit
Richard Delaney replies: Thank you very much for your letter. Feedback is always great to hear. I really enjoyed reading your solution to common everyday scripting needs. Often, the easiest way to overcome problems is to write from the ground up in Python what you want. It has the advantage of being very expressive, and you don't need to waste time due to unfamiliarity with certain tools or wrangling with Bash's strange syntax.
However, I really would recommend trying to grapple with some of the real GNU utilities when you get time. Tools like cat, head and tail can be very powerful if you spend any amount of time processing files. They allow you to sample parts of files very easily among a host of other things. Often its easier when you know how to use commands such as these to combine them with a meatier Python script that does the heavy lifting and leaves the simple utilities to the GNU utilities. This has many advantages, such as having decade-tested tools at your disposable, which are the quickest they can be at what they do. The UNIX philosophy of “do one thing well” doesn't translate to every problem, but in this case, I find it is at its most powerful.
PS. Thanks for recommending docopt. I will be looking into it for new projects.
Is it possible to get more in-depth articles in Linux Journal? Everyone that reads this magazine is super smart. I know you don't know what your readers know and what they don't know. So, it makes it hard too go too in-depth into particular articles.
But, from my personal perspective, I see a lot of introduction articles, like intro to Python, or intro to dbus, or intro to setting up your router, or intro to KVM or intro to Git.
Sometimes these intro articles seem similar to those from previous years. Like the Git article—I think there was an article in August 2011 that was similar to an article in 2005.
I would like to see some more in-depth articles. Here are some example topics.
Instead of an intro to KVM, what about some hints and tips for setting up KVM with different network setups (NAS, private network), or setting up removable devices (USB stick) or setting it up with multiple monitors? All these things, for me, seem non-trivial.
Or, what about an entire issue on benchmarking? You could do one article on comparing different distros via benchmarking. You could do another article on comparing virtualization to physical. Or, you could do a project where you show how readers could benchmark their boxes, and readers could send in their results.
Finally, I know you just did an issue on the kernel, but there was no article about where the kernel is going. What about an article on possibilities for kernel development? Are there more and newer additions to the kernel for virtualization? How will the kernel compete with Mountain Lion and Windows 8? What new additions to the kernel will be added for touchscreens?
Overall, I love your magazine. It's great, and I wouldn't be a subscriber
if it wasn't.
However, this is what I feel is missing.
—
Doug
Thank you for your letter. It's only feedback like this that lets us know the thoughts of our readers. We do try to cover both ends of the spectrum, largely due to feedback like yours and feedback quite opposite: “I want to learn more about Linux, but your magazine seems to exclude all but the seasoned veterans.”
We will try to find the proper balance, and if the pendulum has gone the other way a bit, hopefully, it will swing back toward the middle. Seriously though, thank you for the feedback, it's critical!—Ed.
I've read about all the games that are being brought to Linux now that Windows 8 is
out. I guess the developers hate how 8 is locked down.
How about some articles on the games? I love games.
—
Doug
Me too. “Loving” very rarely equates to “is good at”, but I try not to let that stop me. I have been keeping up on the Steam client for Linux, and once that's released, perhaps it will spark a renewed interest in gaming. I freely volunteer my services as resident game-tester!—Ed.
I have been a UNIX user for more than 30 years. I love UNIX because of the philosophy on which UNIX was designed.
I have noticed that in the Linux community, many people try to show they are
knowledgeable by showing they are ignorant in Windows. An example of this is in The
Open-Source Classroom column in the November 2012 issue. The author stated that
“after I learned to press Ctrl-Alt-Del to log in....” One must
have lived on
Mars for decades not to know how to log in to Windows. It is theoretically
possible but practically very unlikely for someone working in the IT field
never to
have logged in to Windows.
—
John Du
My apologies if my sarcasm was taken as a serious point of confusion. I was trying to make a humorous observation that “Ctrl-Alt-Del” historically has been how to reboot a computer, and it's ironically the way to begin computing in modern Windows.
If I'm being completely transparent, however, my new day job does actually mark the first time I've ever had to press Ctrl-Alt-Del to log in. I managed one Windows server in my last sysadmin position, but I used pGina for authentication, so I never had to use the three-finger salute to get a login prompt! (Your observation is correct though, I knew perfectly well how to log in in my new Windows environment.)—Shawn.
Regarding Dave Taylor's column in the November 2012 issue: the following code handles multiple, even overlapping, shell script timeouts reliably. It does not risk killing any unrelated process that just happens to match $myname. It sends SIGTERM, not SIGALRM.
The following shell routines, taken from the script pauljackson.us/watchdog_eg.sh, provide a convenient and robust way for shell script authors to handle multiple, even overlapping, timeouts in shell scripts:
# token = begin_watchdog(secs, func)
#
# Call function 'func' in 'secs' seconds unless
# end_watchdog() called first with 'token'
begin_watchdog()
{
secs=$1
func=$2
dir=$(mktemp -d)
(
trap 'rmdir $dir' 1 2 3 15
sleep $secs
test -d $dir && $func
) 1>/dev/null &
# the returned token is just the temp directory path
echo $dir
}
# end_watchdog(token)
#
# Call off the watchdog - rmdir the token directory
end_watchdog()
{
dir=$1
rmdir $dir
}
woof()
{
echo Woof - Killing process group $$ 1>&2
kill -TERM -$$ 1>&2
}
Dave Taylor replies: That's a cool approach. Thanks for sharing it with the Linux Journal readership!
Thank you all for an excellent November issue. It just sparkled on my tablet, especially all the Python stuff. Richard Delaney's article on how to use Python inside Bash scripts was just what I was looking for. I'd already used Bash inside Python, until discovering I simply was running Bash in Python, so I dropped back to Bash itself. It simply never occurred to me that the other way around was just as valuable.
As for Kyle Rankin's article on the N900 substitute: a very nice try, but personally, I'm still clinging to my N900 until there's a real Linux solution or until I can install a proper native Linux on my transformer—that is, one that doesn't run on VNC.
Keep up the good work. I for one am very pleased with your digital format; it's
getting better and better, and it's a very convenient and cheap solution for us
subscribers abroad.
—
triantares
Thank you for the kind words. I just purchased a 10" tablet computer after turning in my last one when changing jobs. I was surprised how much I missed the tablet computer, largely due to the beautiful magazine rendering. Much like the new digital billboards popping up all along the highways, I find the digital magazine to grab my attention. I often worry the former might cause car accidents, but I'm quite pleased with the latter.
As to Kyle's N900, well, we've been teasing him ever since Maemo was discontinued. He may have given up his N900, but it will take an army to pry the IBM Model M keyboard from his fingers.—Ed.
