Alternatives Don’t Need To Be Bashed

November 26, 2024 by Bryan Cockfield 20 Comments

By default, bash is the most popular command language simply because it’s included in most *nix operating systems. Additionally, people don’t tend to spend a lot of time thinking about whatever their computer uses for scripting as they might for other pieces of software like a word processor or browser. If you are so inclined to take a closer look at this tool that’s often taken for granted, there are a number of alternatives to bash and [monzool] wanted to investigate them closely.

Unlike other similar documentation that [monzool] has come across where the writers didn’t actually use the scripting languages being investigated, [monzool] is planning to use each of these and accomplish specific objectives. This will allow them to get a feel for the languages and whether or not they are acceptable alternatives for bash. Moving through directories, passing commands back and forth, manipulating strings, searching for files, and manipulating the terminal display settings are all included in this task list. A few languages are tossed out before initial testing even begins for not meeting certain specific requirements. One example is not being particularly useful in [monzool]’s preferred embedded environments, but even so there are enough bash alternatives to test out ten separate languages.

Unfortunately, at the end of the day none of the ten selected would make a true replacement for bash, at least for [monzool]’s use case, but there were a few standouts nonetheless. Nutshell was interesting for being a more modern, advanced system and [monzool] found Janet to be a fun and interesting project but had limitations with cross-compiling. All in all though this seemed to be an enjoyable experience that we’d recommend if you actually want to get into the weeds on what scripting languages are actually capable of. Another interesting one we featured a while back attempts to perform as a shell and a programming language simultaneously.

Get Your Lisp On With The Dune Shell

September 20, 2024 by Dave Rowntree 10 Comments

Lisp is one of those programming languages that seems to keep taunting us for not learning it properly. It is still used for teaching functional languages today. [Adam McDaniel] has an obvious fondness for this fifty-year-old language and has used it in several projects, including their own shell, Dune.

Dune is a shell designed for powerful scripting. Think of it as an unholy combination of bash and Lisp.

Dune is designed to be highly customisable, allowing you to create a super-optimised workstation for your admin and programming tasks. [Adam] describes the front end for Dune as having turned up the cosiness dial to eleven, and we can see that. A cosy home is personalised, and Dune lets you customise everything.

Dune is a useable functional programming environment with a reasonably complete standard library to back it up, which should simplify some of the more complicated sysadmin tasks. [Adam] says the language also supports a few metaprogramming concepts, such as a quote operator, operator overloading, and macro programming. It’s difficult to describe much more about what you can do with Dune, as it’s a general-purpose programming language wrapped in a shell. The possibilities are endless, and [Adam] is looking forward to seeing what you lot out there do with his project!

The shell can be personalised by editing the prelude file, which allows you to overload functions for the prompt text, the incomplete prompt text (so you can implement intelligent completion options), and a function that deals with the formatting of the command response text. [Adam] gives us his personal prelude file, which defines many helper functions displaying useful things such as the current weather, a calendar, and an ASCII art cat. You never know when that might come in handy. This file is written in Lisp, so we reckon that’s where many people will start as they come up the Lisp (re)learning curve before embarking on more involved automation. Dune was written in Rust, so you need that infrastructure to install it with Cargo.

As we said earlier, Lisp is not a new language. We found a hack for porting a Lisp interpreter to any old language and also running Lisp bare metal on a Lisp machine. Finally, [Al] takes a look at some alternative shells.

Blowing Up Shell Scripts

September 18, 2024 by Bryan Cockfield 24 Comments

One of the most universal experiences of any Linux or Unix user is working through a guide or handbook and coming across an almost unbelievably complex line of code meant to be executed with a shell. At the time of encountering a snippet like this it’s difficult to imagine any human ever having written it in the first place, but with some dedication it is possible to tease out what these small bits of code do when they’re typed into the terminal and run (unless it’s something like :(){ :|:& };: but that’s another story entirely). [noperator] recently built a tool which helps users in this predicament understand these shell scripts by expanding them into a more human-intelligible form.

The tool is named sol and does much more than expanding shell one-liners into a readable format. It also provides an interactive shell environment where the user can explore the exploded code in detail, modify it in any way they see fit, and collapse it back down to a single line so it can easily be sent to other users. It can be used with most of the major text editors as well as piped directly to standard input, and has a number of other options as well such as custom configurations and the ability to see non-standard bits of code that might not be compatible from one shell environment to another, as well as helping to translate those bits of code.

[noperator] has made the code available in the linked GitHub page for anyone curious about its use, and has a to-do list for future versions of the tool as well including adding support beyond bash. We’d definitely recommend a tool like this especially if you’re still relatively new to bash scripting (or shell scripting in general) and, as always, we’d just to remind everyone not to blindly copy and paste commands into their terminal windows. If you’re the type of person to go out on a limb and run crazy commands to see what they actually do, though, make sure you’re at least logged into the right computer first.

Obsolete E-Reader Gets New Life

November 13, 2023 by Bryan Cockfield 6 Comments

For those who read often, e-readers are a great niche device that can help prevent eye fatigue with their e-ink displays especially when compared to a backlit display like a tablet or smartphone, all while taking up minimal space unlike a stack of real books. But for all their perks, there are still plenty of reasons to maintain a library of bound paper volumes. For those who have turned back to books or whose e-readers aren’t getting the attention they once did, there are plenty of things to do with them like this e-book picture frame.

The device started life as a PocketBook Basic Touch, or PocketBook 624, a fairly basic e-reader from 2014, but at its core is a decent ARM chip that can do many more things than display text. It also shipped running a version of Linux, which made it fairly easy to get a shell and start probing around. Unlike modern smart phones this e-reader seems to be fairly open and able to run some custom software, and as a result there are already some C++ programs available for these devices. Armed with some example programs, [Peter] was able to write a piece of custom software that displays images from an on-board directory and mounted the new picture display using an old book.

There were a number of options for this specific device that [Peter] explored that didn’t pan out well, like downloading images from the internet to display instead of images on the device, but in the end he went with a simpler setup to avoid feature creep and get his project up and running for “#inktober”, a fediverse-oriented drawing challenge that happened last month. While not strictly in line with a daily piece of hand-drawn artwork, the project still follows the spirit of the event. And, for those with more locked-down e-readers there’s some hope of unlocking the full functionality of older models with this FOSS operating system.

Linux Fu: The Shell Forth Programmers Will Love

February 8, 2023 by Al Williams 28 Comments

One of the most powerful features of Unix and Linux is that using traditional command line tools, everything is a stream of bytes. Granted, modern software has blurred this a bit, but at the command line, everything is text with certain loose conventions about what separates fields and records. This lets you do things like take a directory listing, sort it, remove the duplicates, and compare it to another directory listing. But what if the shell understood more data types other than streams? You might argue it would make some things better and some things worse, but you don’t have to guess, you can install cosh, a shell that provides tools to produce and work with structured data types.

The system is written with Rust, so you will need Rust setup to compile it. For most distributions, that’s just a package install (rust-all in Ubuntu-like distros, for example). Once you have it running, you’ll have a few new things to learn compared to other shells you’ve used. Continue reading “Linux Fu: The Shell Forth Programmers Will Love” →

AI Makes Linux Do What You Mean, Not What You Say

April 20, 2021 by Al Williams 30 Comments

We are always envious of the Star Trek Enterprise computers. You can just sort of ask them a hazy question and they will — usually — figure out what you want. Even the automatic doors seemed to know the difference between someone walking into a turbolift versus someone being thrown into the door during a fight. [River] decided to try his new API keys for the private beta of an AI service to generate Linux commands based on a description. How does it work? Watch the video below and find out.

Some examples work fairly well. In response to “email the Rickroll video to Jeff Bezos,” the system produced a curl command and an e-mail to what we assume is the right place. “Find all files in the current directory bigger than 1 GB” works, too.

Continue reading “AI Makes Linux Do What You Mean, Not What You Say” →

The Shell And The Microcontroller

January 9, 2021 by Elliot Williams 104 Comments

One of the nicest amenities of interpreted programming languages is that you can test out the code that you’re developing in a shell, one line at a time, and see the results instantly. No matter how quickly your write-compile-flash cycle has gotten on the microcontroller of your choice, it’s still less fun than writing blink_led() and having it do so right then and there. Why don’t we have that experience yet?

If you’ve used any modern scripting language on your big computer, it comes with a shell, a read-eval-print loop (REPL) in which you can interactively try out your code just about as fast as you can type it. It’s great for interactive or exploratory programming, and it’s great for newbies who can test and learn things step by step. A good REPL lets you test out your ideas line by line, essentially running a little test of your code every time you hit enter.

The obvious tradeoff for ease of development is speed. Compiled languages are almost always faster, and this is especially relevant in the constrained world of microcontrollers. Or maybe it used to be. I learned to program in an interpreted language — BASIC — on computers that were not much more powerful than a $5 microcontroller these days, and there’s a BASIC for most every micro out there. I write in Forth, which is faster and less resource intensive than BASIC, and has a very comprehensive REPL, but is admittedly an acquired taste. MicroPython has been ported over to a number of micros, and is probably a lot more familiar.

But still, developing MicroPython for your microcontroller isn’t developing on your microcontroller, and if you follow any of the guides out there, you’ll end up editing a file on your computer, uploading it to the microcontroller, and running it from within the REPL. This creates a flow that’s just about as awkward as the write-compile-flash cycle of C.

What’s missing? A good editor (or IDE?) running on the microcontroller that would let you do both your exploratory coding and record its history into a more permanent form. Imagine, for instance, a web-based MicroPython IDE served off of an ESP32, which provided both a shell for experiments and a way to copy the line you just typed into the shell into the file you’re working on. We’re very close to this being a viable idea, and it would reduce the introductory hurdles for newbies to almost nothing, while letting experienced programmers play.

Or has someone done this already? Why isn’t an interpreted introduction to microcontrollers the standard?