Tag: Bash

Posted on

A Pair of Programming Projects

Good Morning from my Robotics Lab! This is Shadow_8472 and today I am covering my programming work this past month. Let’s get started!

I am finding that even on the monthly cycle, I don’t always finish the projects I intend to. This month, I was intending to work on my phone, but that project hit some tough truth and the story isn’t ready yet.

HyperTrace

I might as well introduce my newest long-term project, HyperTrace. It started out in October as a spectator camera for a larger Redot community project. I studied up on using quaternions to rotate a camera node to avoid gimble lock, but just as I was starting to get it under control after I was bored stiff of them, I realized I could just attach a camera to a physics object.

But once I had a camera with 6 degrees of freedom (three positional and three rotational), I started thinking about how I could make a game out of it. I figured a space piloting game was in order. I got into studying up on using Perlin noise and similar methods of making structured noise to generate a shifting cave structure to represent a hyperspace mesh for the player to navigate – preferably at high speed.

The idea is that an unnamed pilot is tracing out a route through a shifting hyperspace (preferably at high speed), and if he collides with a wall, he is thrown out of hyperspace, where it isn’t safe to re-enter, so he must return to port under conventional physics. If he succeeds, his fleet can instantly jump across his route. This FTL system sets the stage for a future where humanity has colonized the solar system, but is hesitant to venture out to other stars. Think Star Wars meets Space Engineers meets Monkey Ball.

So far, my best tech demo is a blue fog you can navigate at slow, careful speeds. It takes an unacceptably long

Shell Scripting

My services were called upon for a “computer project.” My mother had some PDF files of recipes to separate. Over the course of an afternoon, I wrote a BASH script to separate out each page in each PDF. At its heart was the program qpdf. Along the way, I tried to keep good practices like leaving comments and having checks to prevent accidental overwriting.

Now, I only know a modest bit of BASH (popular Linux command line interface aimed at users), but I know enough about basic programming it was just a matter of syntax for me. But I figured I could do one better in around the same amount of time. I saved a copy of the script and its output, and I set about naming files after their contents, identifying+recombining second pages, and sorting out charts, and numbering repeats (some duplicate recipes had changes).

But for every hour I spent working out a feature, I figured I spent another debugging edge cases. Several recipes had BASH control characters in their titles like *, &, and /. I preferred to use special handling of strings, but in the end I sanitized / as ÷ and * was removed entirely. This additional work extended the project to a total of three days.

Closing thoughts

My goal with Hypertrace is to publish it to Itch.io or similar platform on a donation basis. And before I get past more than a couple tech demos, I’m going to want a version control server in my homelab just in case something happens to my laptop. While I really want to think ahead in terms of security, I know I don’t know enough to make an informed decision about the utility I need now.

Final Question

What Git setup do you recommend for a homelab?

Posted on

How I would Relearn Linux #5: Basic Scripting

Good Morning from my Robotics Lab! This is Shadow_8472 with another tip for how I would relearn Linux. Let’s get started.

Scripts

No serious system administrator has time to memorize long chains of commands taking minutes to type and might need fixing after the first try. When faced with a periodic task involving a long, involved [set of] command[s], it’s preferable to write them in a script to be run sequentially from file. While I did get by for a few years by using Bash’s (terminal shell, see section on shells) history functionality, a script is a much more sustainable way to “remember” commands.

To write a script, put your command[s] into a text document – one per line. The pound sign # at the start of a line turns it into a comment to clue future you or others into your thought process. Using a backslash \ character and additional whitespace for alignment, lines may be broken up at any point to increase readability. This becomes especially useful when dealing with half a dozen flags.

#this line is a comment
podman run \
    --name testpilot \
    --network podman \
    --ip 10.88.2.88 \
    -v ~/sandbox/testVolume:/root/vol1 \
    --rm \
    busybox:latest
#No interrupting commands – even with commented flags.
#    -v ~/sandbox/wrongTestVolume:/root/vol2 \

A script will then need permission to execute.

chmod +x <filename>

Lacking a proper explanation of the Linux permissions system, just know this is a fast way to ensure YOU have permission to EXECUTE your script.

Even understanding up to this point unlocks a powerhouse of possibility. These tools –sequential commands, comments, line breaks, and white space– are all I need to make scripts to stitch together more complicated programs I work with to build my home server. Most importantly: scripting commands allows me to clearly visualize the command I’m working on.

Shells

One slightly mind bending concept is the shell. In simplified terms, a computer shell is an operating environment. Open a terminal on a Linux workstation, and you probably have a Bash shell. Some part of desktop environment you opened that shell from is a graphical shell. From Bash, you can open another instance of Bash inside the last one like a Russian matrushka doll (nesting dolls). Connect to another computer with SSH, and there’s another shell (one one each machine working together, I think?). Other programs –such as a Python interpreter– may have a shell of their own.

Not all shells are intended for human interaction. Somewhere below the graphical environment is logically a shell either running directly atop the kernel (I don’t actually know if the kernel itself counts as a shell) optimized for running quickly.

Most important to this conversation: running a script will open a shell for its own use and close it afterwords. Fancier shell scripts can leverage many powers characteristic of typical programming languages. Flow control allows logic to branch and loop depending on the state of a whole assortment of variable types. And thanks to shell manipulation, variables can be isolated from one another in ways I’m totally unfamiliar with. And all this exposed power comes packaged directly into the operating system itself.

Takeaway

Shell scripting is a powerful tool. This single lesson is enough to unlock a wealth of potential, yet only a fraction of its total capabilities. Variables –for example– turned out more involved than I thought, so I scrapped a section them after writing about shells to support it. While it’s OK to run with only a partial knowledge, it’s also good to be aware of additional capacities when reading scripts written, polished, and published for use by other people.

Final Question

What projects have you designed with scripts?

Privacy Policy