bash

58 Articles

Linux-Fu: Help Messages For Shell Scripts And Here Documents

August 3, 2020 by 20 Comments

Imagine that you want to output multiple lines of text in Bash, or any shell script. Maybe it’s for a help string for a particularly convoluted shell script you’re writing. You could have a separate echo command for each line.  Or you could use the “here document“.

The “here document” construction takes the text between two delimiters and passes it, as if it were piped, to a command.

if [[$# == 0 ]] || [[ "$1" == "-h" ]]; then
cat << EOF
This is my help message. There are many like it but this one is mine.
My help message is my best friend.
EOF

All of the text, as written, with line breaks and spaces and all, get passed to cat and your helpful formatted message is printed to the user.

Continue reading “Linux-Fu: Help Messages For Shell Scripts And Here Documents” →

Linux Fu: Alternative Shells

May 21, 2020 by 38 Comments

On Unix — the progenitor of Linux — there was /bin/sh. It was simple, by comparison to today’s shells, but it allowed you to enter commands and — most importantly — execute lists of commands. In fact, it was a simple programming language that could make decisions, loop, and do other things to allow you to write scripts that were more than just a list of programs to run. However, it wasn’t always the easiest thing to use, so in true Unix fashion, people started writing new shells. In this post, I want to point out a few shells other than the ubiquitous bash, which is one of the successors to the old sh program.

Since the 7th Edition of Unix, sh was actually the Bourne shell, named after its author, Stephen Bourne. It replaced the older Thompson shell written in 1971. That shell had some resemblance to a modern shell, but wasn’t really set up for scripting. It did have the standard syntax for redirection and piping, though. The PWB shell was also an early contender to replace Thompson, but all of those shells have pretty much disappeared.

You probably use bash and, honestly, you’ll probably continue to use bash after reading this post. But there are a few alternatives and for some people, they are worth considering. Also, there are a few special-purpose shells you may very well encounter even if your primary shell is bash.

Continue reading “Linux Fu: Alternative Shells” →

Typing By Slamming Your Laptop Closed. Repeatedly

April 4, 2020 by 26 Comments

Do you sometimes feel that your custom mechanical keyboard is not quite loud enough to proclaim your superior hacking powers? Or do you need a more forceful way shout in all caps at someone who is wrong on the internet? For all this and more, [Jesse Li] has got you covered, with a set of bash scripts that allows you to type by slamming your laptop closed repeatedly, using Morse code.

Not the fastest way to type, but definitely the most forceful

The scripts are quite simple, and work receiving the lid open/close events from ACPI (Advanced Configuration and Power Interface), recording the open and close timestamp and converting the timing to dots and dashes. After slamming to the required rhythm, you keep the lid open to see the character appear.

Why would want this? Well, you can now type the letter E by closing your laptop, instead of locking it. Maybe use it to send an emergency message while you’re being held by terrorists in a B-grade action movie. Otherwise, we think this is just an entertaining little hack that’s probably the product of quarantine induced boredom.

Morse code, otherwise known as CW, is still in surprisingly widespread use by ham radio operators, because it’s good at getting messages across intercontinental distances when signal conditions are bad and CW-only ham radio gear is cheap and easy to build yourself. We’ve also covered the Koch Method of learning CW, so don’t be afraid to dabble a bit during the quarantine.

Linux Fu: Leaning Down With Exec

December 30, 2019 by 11 Comments

Shell scripting is handy and with a shell like bash it is very capable, too. However, shell scripting isn’t always very efficient. Think about it. If you run grep or tr or sort to do some operation in a shell script, you are spawning a whole new process. That takes time and resources. But there are some answers to reducing — but not eliminating — the problem.

Have you ever written a program like this (in any language, but I’ll use C):

int foo(void)
{
  ...
  bar();

}

You hope the compiler doesn’t write assembly code like this:

_foo: 
....

      call _bar
      ret

Most optimizers should pick up on the fact that you can convert a call like this to a jump and let the ret statement in _bar return to foo’s caller. However, shell scripts are not that smart. If you have a shell script called MungeData and it calls another program or shell script called PostProcess on its last line, then you will have at one time three processes in play: your original shell, the shell running MungeData, and either the PostProcess program or a shell running the script. Not to mention, the processes to do things inside post process. So what do you do?

Continue reading “Linux Fu: Leaning Down With Exec” →

Linux Fu: Debugging Bash Scripts

December 11, 2019 by 23 Comments

A recent post about debugging constructs surprised me. There were quite a few comments about how you didn’t need a debugger, as long as you had printf. For that matter, we’ve all debugged systems where you had nothing but an LED to flash or otherwise turn on to communicate with the user. However, it is hard to deny that a debugger can help with complex code.

To say you only need printf would be like saying you only need machine language. Technically accurate — you can do anything in machine language. But it sure makes things easier to have an assembler or some language to help you work out your problem. If you write a simple bash script, you can use the equivalent to printf — maybe that’s the echo command, although there is usually a printf command on a typical system, if you want to use it. However, there are other things you can do with bash including a pretty cool debugger if you know how to find it.

I assume you already know how to use echo and printf, but let’s dig into how to use trace execution line by line without the need for echo statements on every other line. Along the way, you’ll learn how to get started with the bash debugger.

Continue reading “Linux Fu: Debugging Bash Scripts” →

Linux Fu: Shell Scripts In C, C++, And Others

September 17, 2019 by 44 Comments

At first glance, it might not seem to make sense to write shell scripts in C/C++. After all, the whole point to a shell script is to knock out something quick and dirty. However, there are cases where you might want to write a quick C program to do something that would be hard to do in a traditional scripting language, perhaps you have a library that makes the job easier, or maybe you just know C and can knock it out faster.

While it is true that C generates executables, so there’s no need for a script, usually, the setup to build an executable is not what you want to spend your time on when you are just trying to get something done. In addition, scripts are largely portable. But sending an executable to someone else is fairly risky — but your in luck because C shell scripts can be shared as… well, as scripts. One option is to use a C interpreter like Cling. This is especially common when you are using something like Jupyter notebook. However, it is another piece of software you need on the user’s system. It would be nice to not depend on anything other than the system C compiler which is most likely gcc.

Luckily, there are a few ways to do this and none of them are especially hard. Even if you don’t want to actually script in C, understanding how to get there can be illustrative.

Continue reading “Linux Fu: Shell Scripts In C, C++, And Others” →

Secret Messages Could Be Hiding In Your Server Logs

August 28, 2019 by 13 Comments

[Ryan Flowers] writes in with a clever little hack that can allow you to hide data where nobody is going to go looking for it. By exploiting the fact that a web server will generally log all HTTP requests whether or not it’s valid, he shows how you can covertly send a message by asking the server for a carefully crafted fictitious URL.

We aren’t talking about requesting “yousuck.txt” from the server that hosts your least favorite website, either. As [Ryan] demonstrates, you can compress a text file, encode it with uuencode, and then send it line by line to the destination server with curl. He shows how the process, which he calls “CurlyTP” can be done manually on the command line, but it would be a simple matter of wrapping it up in a Bash script.

To get the message back, you just do the opposite. Use grep to find the lines in the log file that contain the encoded data, and then put them through uudecode to get the original text back. Finding the appropriate lines in the log file is made easier by prepending a prearranged keyword to the beginning of the URL requests. The keyword can be changed for each message to make things easier to keep track of.

If you’re still wondering why anyone would go through the trouble to do this, [Ryan] provides an excellent example: a covert “dead drop” where people could leave messages they’d rather not send through the usual channels. As long as the sender used a service to mask their true IP address, they could anonymously deliver messages onto the server without having to use any special software or protocol they might not have access to. Even the most restrictive firewalls and security measures aren’t likely to be scanning URLs for compressed text files.

We’ve seen web-based dead drops done with Python in the past, and even purpose built “PirateBoxes” that allow people to covertly exchange files, but we like how this method doesn’t require any special configuration on the server side. You should check your server logs, somebody might be trying to tell you something.