Sound eXchange, or SoX, the “Swiss Army knife of audio manipulation” has been around for as long as the Linux kernel, and in case you’re not familiar with it, is a command line tool to play, record, edit, generate, and process audio files. [porkostomus] was especially interested about the generating part, and wrote a little shell script that utilizes SoX’s built-in synthesizer to compose 8-bit style music.
The script comes with a simple yet straightforward user interface to record the lead and bass parts into a text file, and play them back later on. Notes from C2 to C5 are currently supported, and are mapped to the keyboard in a two-row piano layout. The output file format itself is just a plain text listing of the played note, wave form, and note length. This lets you easily edit the song or even generate it from an alternative source, for example MIDI. Also note that there are no initial audio files required here, SoX will generate them as needed.
Admittedly, the command line interface may not be the most convenient way to create music, but nevertheless, it is a way — and that is [porkostomus]’s main mission here. Also, SoX is fun — and versatile, you can apply its audio effects even on images, or decode strange signals sent from a helicopter with it.
Truly good ideas tend to apply in all situations. The phrase is “never run with scissors”, not “don’t run with scissors unless you are just going into the next room.” Software development methodology is a good idea and most of us have our choice of tools. But what if you are developing a significant amount of bash or similar script? Should you just wing it because bash isn’t a “real” programming language? [Oscar] says no, and if you are writing more than two or three lines of script, we agree.
We’ve made the argument before (and many of you have disagreed) that bash is a programming language. Maybe not the greatest and certainly not the sexiest, but bash is near ubiquitous on certain kinds of systems and for many tasks is pretty productive. [Oscar] shows how he uses a source code formatter, a linter, and a unit test framework to bring bash scripting in line with modern software development. We are pretty sure he uses source control, too, but that seems so elementary that it doesn’t come up outside of a link to his repository in GitHub.
Continue reading “Software Development in… Bash”
It is easy to dismiss bash — the typical Linux shell program — as just a command prompt that allows scripting. Bash, however, is a full-blown programming language. I wouldn’t presume to tell you that it is as fast as a compiled C program, but that’s not why it exists. While a lot of people use shell scripts as an analog to a batch file in MSDOS, it can do so much more than that. Contrary to what you might think after a casual glance, it is entirely possible to write scripts that are reliable and robust enough to use in many embedded systems on a Raspberry Pi or similar computer.
I say that because sometimes bash gets a bad reputation. For one thing, it emphasizes ease-of-use. So while it has features that can promote making a robust script, you have to know to turn those features on. Another issue is that a lot of the functionality you’ll use in writing a bash script doesn’t come from bash, it comes from Linux commands (or whatever environment you are using; I’m going to assume some Linux distribution). If those programs do bad things, that isn’t a problem specific to bash.
One other limiting issue to bash is that many people (and I’m one of them) tend to write scripts using constructs that are compatible with older shells. Often times bash can do things better or neater, but we still use the older ways. For example:
Continue reading “Linux Fu: Better Bash Scripting”
It used to be one of the joys of writing embedded software was never having to deploy shell scripts. But now with platforms like the Raspberry Pi becoming very common, Linux shell scripts can be a big part of a system–even the whole system, in some cases. How do you know your shell script is error-free before you deploy it? Of course, nothing can catch all errors, but you might try ShellCheck.
When you compile a C program, the compiler usually catches most of your gross errors. The shell, though, doesn’t look at everything until it runs which means you might have an error just waiting for the right path of an if statement or the wrong file name to occur. ShellCheck can help you identify those issues before deployment.
If you don’t like pasting your script into a Web page, you can install the checker locally by visiting GitHub. The readme file there also explains what kind of things the tool can catch. It can even integrate with common editors (as seen in the video below).
Continue reading “Lint for Shell Scripters”