It isn’t uncommon these days for a programmer’s editor to offer you help about what you are typing, ranging from a pop up with choices to a full-blown code template. If you have written a million lines of code in the language, this might even annoy you. However, if you use it only occasionally, these can be very helpful. I’ve used Unix and Linux for many years, but I realize that there are people who don’t use it every day. With the Raspberry Pi, Linux servers, and Windows 10 having a bash shell, there are more people using a shell “every once in a while” than ever before. Could you use a little help? If so, you might try
bashelp: a little something I put together while writing about bash completion.
There’s good news and bad news. The good news is that Unix has a built-in help command —
man — and has for some time. The bad news is that you need to stop what you are typing and enter a
man command to use it.
Man, by the way, is short for manual.
There are GUI front-ends to
yelp, on the left) and you can even use a web browser locally or remotely. However, none of these are connected to what you are typing. You have to move to another window, enter your search term, then go back to your typing. That got me to thinking about how to get a sort of context-sensitive inline help for bash.
Continue reading “Linux Fu: A Little Help for Bash”
If you aren’t a Linux user and you watch someone who knows what they are doing use Bash — the popular command line interpreter — you might get the impression they type much faster than they actually do. That’s because experienced Linux users know that pressing the tab key will tend to complete what they are typing, so you can type just a few characters and get a much longer line of text. The feature is very smart so you may not have realized it, but it knows a good bit about what you could type. For example, if you try to unzip a file, it knows the expected file name probably has a .zip extension.
How does that happen? At first, you might think, “who cares how it happens?” The problem is when you write a shell script or a program that runs on Linux, the completion gets dumb. Someone has to make Bash smart about each command line program and if you are the author then that someone is you.
Continue reading “Linux Fu: Custom Bash Command Completion”
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”
My apologies if you speak the Queen’s English since that title probably has a whole different meaning to you than I intended. In fact, I’m talking about Git, the version control system. Last time I talked about how the program came to be and offered you a few tutorials. If you are a dyed-in-the-wool software developer, you probably don’t need to be convinced to use Git. But even if you aren’t, there are a lot of things you can do with Git that don’t fit the usual mold.
Continue reading “Stupid Git Tricks”
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”
If you’ve used Linux from the early days (or, like me, started with Unix), you didn’t have to learn as much right away and as things have become more complex, you can kind of pick things up as you go. If you are only starting with Linux because you are using a Raspberry Pi, became unhappy with XP being orphaned, or you are running a cloud server for your latest Skynet-like IoT project, it can be daunting to pick it all up in one place.
Recently my son asked me how do you make something run on a Linux box even after you log off. I thought that was a pretty good question and not necessarily a simple answer, depending on what you want to accomplish.
There’s really four different cases I could think of:
- You want to launch something you know will take a long time.
- You run something, realize it is going to take a long time, and want to log off without stopping it.
- You want to write a script or other kind of program that detaches itself and keeps running (known as a daemon).
- You want some program to run all the time, even if you didn’t log in after a reboot.
Continue reading “Linux-Fu: Keeping Things Running”
A lot of us spend a lot of time switching between Windows and Linux. Now that platforms like the Raspberry Pi are popular, that number is probably increasing every day. While I run Linux on nearly everything I own (with the exception of a laptop), my work computers mostly run Windows. The laptop is on Windows, too, because I got tired of trying to get all the fancy rotation sensors and pen features working properly under Linux.
What I hate most about Windows is how hard is it to see what’s going on under the hood. My HP laptop works with a cheap Dell active stylus. Sort of. It is great except around the screen edges where it goes wild. Calibration never works. On Linux, I could drill down to the lowest levels of the OS if I were so inclined. With Windows, it is just tough.
War is Shell
One place where Linux always used to have an advantage over DOS and Windows was the shell. There are lots of variations available under Linux, but bash seems to be the current pick for most people. If you want more power, you can move to some alternatives, but even bash is pretty powerful if you learn how to use it and have the right external programs (if you don’t believe it, check out this web server).
Continue reading “Shell Game”