Martin F. Krafft: Parsing arguments in a shell script
Since shell is a rather unpredictable programming language, which seems not
to allow manipulation of variables in parent processes, parsing arguments
has always been a bit cumbersome. For instance, check out lines 74 through 123
of /usr/bin/deb-reversion (package devscripts) for the way I used to
do things, which involves a sort of state machine to handle options taking
arguments.
Just last night, I came up with another means, and while it felt like an
incredible hack at the time, I am starting to like it. This method can be
combined with getopt, I just use it to parse guessnet test lines
in /etc/network/interfaces right now:
eval $(while [ -n "$ 1:- " ]; do
case "$1" in
mac) echo MACADDR="'$2'"; shift;;
essid) echo ESSID="'$2'"; shift;;
ie) echo IE="'$2'"; shift;;
*)
echo "$ME: E: invalid argument: $1" >&2
exit 1;;
esac
shift
done exit $?) exit $?
When this is done, any (or none) of the three variables MACADDR,
ESSID, and IE are defined in the shell script's environment. If an
argument is required, I can do checks following the loop, or use getopt
to parse $@ before looping over its components. Of course, the last line
really does make it look like a hack, but it works and it's flexible...
If I now look at /usr/share/guessnet/test/test-wireless, I wonder how
Thomas Hood managed to get things working, specifically because he sets
variables inside a while loop, and then uses them outside of the loop --
exactly the sort of construct that drove me nuts previously. Maybe it has
to do with my religious use of set -u, maybe not. In any case, I am simply
not willing to investigate.
They represent exactly the same thing, yet someone who knows music
needs a split second to decode the below but a few seconds for the above
(if they understand lilypond's syntaxis). In fact, at first I thought
that I had done something wrong in invoking lilypond-book to
produce that snippet, because I had misparsed the code above (which,
incidentally, is one bar of some actual music that I have in my
~/data/audio/lilypond directory)
The plain text interface certainly does have some
advantages, but IMO the downsides by far outweigh the benefits. In
general, lilypond is not well suited as a way to actually write
music, as opposed to simply typesetting already existing music. I did
actually follow a course on harmonics (although I never finished it due
to lack of time); when writing some new piece, I find that it often far
easier to do the actual writing on a piece of paper and then enter that
in lilypond syntaxis, rather than getting distracted over the lilypond
syntaxis while trying to concentrate on what chords I can and/or want to
use. It is unnatural, and would look like a Japanese person being forced
to read and write texts like 'gaka ga e o kaita' which then get
postprocesssed into something like ' ' (look ma,
Unicode!). Or, in other words: why isn't there just an input method to
write music? There are unicode characters for musical notes,
you know...
When comparing lilypond to finale, it is not hard to understand that
entering music in a graphical environment is just so much easier. When I
last used it, Finale had four input methods: one with keyboard and mouse
(use the numeric keys on the keyboard to enter the desired note length
and the mouse to enter the pitch); one with keyboard only (use abcdefg
etc. to choose the pitch, and the same numeric keys to enter the desired
length); one with keyboard and MIDI keyboard (use the numeric keys to
enter a desired note length, and just press a note on the MIDI keyboard
to choose it); and finally, it can also quantisise music as you play it
(which is the fastest, but least accurate, method to enter music).
Lilypond only allows entering music with the keyboard directly, and then
only displays notes after 'compiling' them, so that you cannot see your
mistakes and typos until much later. I'm disregarding midi2ly, which
converts MIDI files to lilypond input files in a reasonably good way;
but Finale has MIDI import functionality as well, I do not consider that
to be an 'Input Method' as such.
After having entered the music, a musician will want to do something
with it. Have the computer play it, for instance, or print it out so
that he or she can rehearse it and eventually play it themselves.
Lilypond will do neither by itself; however, it can produce postscript,
PDF, and DVI files which one can use to print, and/or MIDI files which
one can have the computer play. The printouts are great, as I've said
before; but playing the MIDI files is another matter entirely.
As I've explained earlier, playing MIDI used to be done through
hardware. When I still had a working SB16-compatible card, I could play
MIDI files on my computer perfectly fine by just using the driver for
that sound card. Since I currently depend mostly on ESS1371-compatible
cards, that do not havve any hardware MIDI synthesizer, however, that
doesn't work. So I have to use software sequencing instead. On Windows,
software sequencing is done by the sound card's driver. On Linux, there
is no software sequencing being done by any driver, so it all has to be
done in userland. In theory, that's just fine. Unfortunately, the
implementation sucks.
The only software MIDI synthesizer available on Debian is
