Regarding Dave Taylor's “Working with Command Arguments” in the February 2016 issue: it's a worthy article but let's expand on it a bit. Long arguments like --help certainly deserve a mention.
But my main gripe with using getopt in bash is the lack of a wrapper function. Python, C, C++, Ruby, etc., all have wrappers that simplify using getopt enormously.
I help maintain hundreds of scripts at work (and home!), and I find the biggest source of errors are those that creep in during maintenance.
The problem is that there are multiple places that need to be kept in sync—the call to getopt itself, the case statement where the options are processed and the help output that documents it all.
So—time for shameless self publicity—I wrote a wrapper for bash that fixes this shortcoming. It's at bhepple.com/doku/doku.php?id=argp.sh.
To use it, you put all the information about the various options in a simple variable (or here-document) and run a bit of mumbo-jumbo to process the arguments. For that low, low price, you get the options parsed, a call made to getopt and variables set for you as well as a help screen—all automatically from the single source. Here's an example:
ARGS="
##############################################################
#OPTIONS:
#name=default sname arg type range description
##############################################################
CD='' c '' b '' foobar
SLOT='' s 'n' s '' option that takes a value
TOKEN='' t 'number' s '' option that takes a value
LONG='' '' 'long' s '' a long option without a
short one
SILENT='' '' '' b ''
##############################################################
"
exec 4>&1
eval $(echo "$ARGS" | argp.sh "$@" 3>&1 1>&4 || echo exit $? )
exec 4>&-
That last bit looks scary, but it does the job—if the user invoked the script with -s 5, the bash variable SLOT has that value, etc., etc.
Hope it helps—it certainly has made my life much easier.
—
Bob Hepple
This is with reference to Dave Taylor's article in the December 2015 issue about
dealing with CSV files. Yes, for people skilled with the power of the shell,
doing
taxes and such accounting things with scripting is very easy and full of
enjoyment. I do not know who invented the comma as a delimiter or the format
called “csv”. Instead, that person should have used tab as a
delimiter, and the format
should have been called “tsv”! I use tab as a delimiter (when exporting
from spreadsheets using OpenOffice) and face no problems whatsoever.
Besides ease of processing, the file becomes so much more readable with
the suitable tab-stop setting.
—
Mayuresh
Dave Taylor replies: Mayuresh, I love your suggestion, and you're right, the use of any punctuation symbol that can occur within the data fields themselves is really pretty stupid as a format. When I convert delimiters back and forth, I use sequences like ^^ that are incredibly unlikely to show up in any prose or data set.
More bizarre—CSV is a standards-body-approved format: www.digitalpreservation.gov/formats/fdd/fdd000323.shtml.
My only comment: tabs can make things more readable, but if you've wrestled with data where the fields vary from less than to greater than a tab's width (typically eight characters), you know how annoying that can be to align perfectly.
Thanks for writing in!
The “Command-Line Tutorial” in the February 2016 issue was a fun article by Sol Lederman. It got me playing around with the commands, and I started manually checking with cal and cksum for unique leap years. When I found the eighth unique one, I started to worry if the world was ending.
After digging around a bit, I discovered that my mis-matched pair was 2016 and 2044. For some reason, in Debian Jessie (32 and 64)—okay in Fedora 23—the year 2016 is generated in a strange fashion.
The numerical dates are displayed with digits separated by one or more spaces (0x20) as appropriate, except for the prior and current date when the cal is generated; in this case the 2nd, 3rd last night, and the 3rd, 4th this morning.
The date of generation and prior day's date are separated by “space”, “underbar”, “backspace” (0x20 0x5f 0x08) sequences instead of just “space”. Now the cksum and wc -c just went out the window and don't match anything, even though the appearance of the two calendars is identical except for the year.
So I would surmise this applies to any Debian derivatives and only for the
current year, and possibly for only single-digit dates. I'll have to wait to see
what happens on a two-digit date! Perhaps it's a remnant of syntax to highlight the
current date.
—
Wally Olson
Sol Lederman replies:
I'm glad you had fun with the calendar puzzle. Thanks for pointing out that different flavors of Linux render calendars differently. I ran into differences as well, and pointed it out in the article, hoping to give readers a heads up in case they got unexpected results. Perhaps other readers will find even more differences. And, maybe the lesson here is that a command as simple as cal has different output on different systems. Hopefully, others who run into different flavors of cal will be inspired to dig in and figure out what's wrong as you did. Happy computing!
I believe it's newsworthy that Google is effectively blocking the inclusion of an already-ready patch to include APNG support in Chromium/Blink.
This reaction is so blatantly against the community and so clearly in protection of Google's own WebP that nobody uses that I can't help but clench my fists.
I would very much appreciate if you could spread the news to your readers and colleagues so that the Internet may finally be free of the legacy of GIF.
Here's the thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KcMjmFOgG2w.
—
OlegM
Regarding Shawn Powers' “The Powers That Be” in the February
2016 issue: I really liked the article; it reminded me of a similar problem we had a
few years ago. All of a sudden, every evening at 10pm our power would drop
for a moment, and every computer in the house would drop—no explanation. We
got the power company out, and they found nothing wrong with the line (but
they were testing only during the day). Anyhow, three visits later, I mentioned
the major hospital three blocks away, and I noticed that there was power-line
work happening on the main road. (We lived on a back street three streets from
the main road.) It turns out that while the power company had been doing power
work on the main line, they switched the power for the hospital's
incinerators to the sub-lines on the back streets and had forgotten to
switch them back. The problem was that the hospital incinerators were
auto-set to start every night at 10, and this was putting too much drain on
the line and causing minor drop outs. The moral: it pays to look around.
—
Trevor Furnell
Shawn Powers replies: I can only imagine your irritation! Great job figuring out what was causing the problem. Finding a resolution like that is almost worth the frustration it caused in the first place. Almost.
I had power problems like Shawn's in my house for some time. Although the house was new in 2013, the power drop from the utility pole into my electric meter was very old, as the previous house was demolished to build a new one. I plugged an analog AC voltmeter in to an outlet and watched the voltage fluctuate from 90 volts to 120 volts. My lights would flicker also. After many months of this, I called the electric company. They checked the connection at the utility pole end of my drop and found a badly corroded splice. The lineman cut off the corroded ends and made a new connection at the pole, and my problems disappeared. This might be the cause of your problem. The fluctuations were worse on windy days since the drop wires were swaying in the wind making the fluctuations even more apparent.
I hope this helps.
—
Eric
Shawn Powers replies: Thanks for the suggestion! During the next year, our city is moving overhead lines to under ground. Hopefully during that process, the new lines will make for more stable electricity. Of course, now it's a moot point for me, but still, stability is nice!