It is easy to think that a Linux shell like Bash is just a way to enter commands at a terminal. But, in fact, it is also a powerful programming language as we’ve seen from projects ranging from web servers to simple utilities to make dangerous commands safer. Like most programming languages, though, there are multiple layers of complexity. You can spend a little time and get by or you can invest more time and learn about the language and, hopefully, write more robust programs.
If you use just about any modern command line, you probably understand the idea of pipes. Pipes are the ability to connect the output from one program to the input of another. For example, you can more easily review contents of a large directory on a Linux machine by connecting two simple commands using a pipe:
ls | less
This command runs ls and sends its output to the input of the less program. In Linux, both commands run at once and output from ls immediately appears as the input of less. From the user’s point of view it’s a single operation. In contrast, under regular old MSDOS, two steps would be necessary to run these commands:
ls > SOME_TEMP_FILE less < SOME_TEMP_FILE
The big difference is that ls will run to completion, saving its output a file. Then the less command runs and reads the file. The result is the same, but the timing isn’t.
You may be wondering why I’m explaining such a simple concept. There’s another type of pipe that isn’t as often used: a named pipe. The normal pipes are attached to a pair of commands. However, a named pipe has a life of its own. Any number of processes can write to it and read from it. Learn the ways of named pipes will certainly up your Linux-Fu, so let’s jump in!
In an earlier installment of Linux Fu, I mentioned how you can use inotifywait to efficiently watch for file system changes. The comments had a lot of alternative ways to do the same job, which is great. But there was one very easy-to-use tool that didn’t show up, so I wanted to talk about it. That tool is entr. It isn’t as versatile, but it is easy to use and covers a lot of common use cases where you want some action to occur when a file changes.
One of the great things about Linux and similar operating systems is they are configurable. If you don’t like something, there’s a great chance you can change it easily with a few entries in a file somewhere. For example, take bash — a very popular shell by any measure. If you want a different style of command line editing, there’s an option. You want the tab key to match files regardless of case? Another option. Usually, these are set in one of your so-called profile files like .bashrc in your home directory.
As long as you are sitting in front of your single computer working, this is great. You customize your .bashrc and other files to your heart’s content and then you work in an environment that acts the way you want it to. The problem is when you have a lot of computers. Maybe you have a web server, a desktop, a firewall machine, and a few dozen Raspberry Pi computers. How do you keep all the configurations the same? Then once they are the same, how do you keep them up to date?
The title of this post says it all: GoTTY is a program that lets you share Linux terminal applications into a web browser. It is a simple web server written in Go that runs a non-GUI program and can push it out a socket in such a way that a browser can display it and, optionally, let the user interact with it.
With the emphasis on security these days, that ought to alarm you. After all, why would you want a shell running in a browser? Hang on, though. While that is possible — and not always undesirable — the real value to this technique is to run a specific command line program in a browser window. Here’s a use case: You want users to remotely monitor a system using top (or htop, if you are fancy). But you don’t want users logging into the system nor do you want to require them to have ssh clients. You don’t want to install monitoring tools, just use what you already have.
If you could get the output from top to show up in a browser window — even if the users had no ability to input — that would be an easy solution. Granted, you could just run top in batch mode, collect the output, and write it somewhere that a web server could find it. Assuming you have a web server installed, of course. But then what if you did want some other features like taking command line options or having the option for (hopefully) authenticated users to interact with the software? Now that would be more complicated. With GoTTY, it is easy.
I hate to admit it. I don’t really use Linux on my desktop anymore. Well, technically I do. I boot into Linux. Then I do about 95% of my work in Chrome. About the only native applications I use anymore are development tools, the shell, emacs, and GIMP. If I really wanted to, I could probably find replacements for nearly all of those that run in the browser. I don’t use it, but there’s even an ssh client in the browser. Mail client? Gmail. Blogging? WordPress. Notes? OneNote or Evernote. Wouldn’t it be great to run those as actual applications instead of tabs in a browser? You can and I’ll show you how.
Having apps inside Chrome can be a real problem. I wind up with dozens of tabs open — I’m bad about that anyway. Restarting chrome is a nightmare as it struggles to load 100 tabs all at once. (Related tip: Go to chrome://flags and turn “Offline Auto-Reload Mode” off and “Only Auto-Reload Visible Tabs” on.) I also waste a lot of time searching since I try to organize tabs by window. So I have to find the window that has, say, Gmail in it and then find Gmail among the twenty or so tabs in that window.
What I want is a way to wrap web applications in their own window so that they’d show up in the task bar with their own icon, but external web pages that open from these apps ought to open in Chrome rather than in the same window. If applications were outside of the single browser window, I could move them to different desktops and organize them like they were any other program, including adding them to a launcher. Hopefully, this would let me have fewer windows like this:
Continue reading “Linux Fu: Turn A Web App Into A Full Program”
One of the best things about working at the Linux (or similar OS) command line is the use of pipes. In simple terms, a pipe takes the output of one command and sends it to the input of another command. You can do a lot with a pipe, but sometimes it is hard to work out the right order for a set of pipes. A common trick is to attack it incrementally. That is, do one command and get it working with the right options and inputs. Then add another command until that works. Keep adding commands and tweaking until you get the final results.
That’s fine, but [akavel] wanted better and used Go to create “up” — an interactive viewer for pipelines.
Pipes can do a lot. They match in with the original Unix philosophy of making each tool do one thing really well. Pipe is really good at allowing Linux commands to talk to each other. If you want to learn all about pipes, have a look at the Linux Info project’s guide. They even talk about why MSDOS pipes were not really pipes at all. (One thing that write up doesn’t touch on is the named pipe. Do a “man fifo” if you want to learn more for now and perhaps that will be the subject of a future Linux Fu.)
This program — called up — continuously runs and reruns your pipeline as you make changes to the pipe. This way, every change you make is instantly reflected in the output. Here’s the video, here’s a quick video which shows off the interactive nature of up.
The GitHub page assumes you know how to install a go program. I tried doing a build but I didn’t have a few dependencies. Turns out the easy way to do it was to run this line:
go get -u github.com/akavel/up
This put the executable in ~/go/bin — which isn’t on my path. You can, of course, copy or link it to some directory that’s on your path or add that directory to your path. You could also set an alias, for example. Or, like I did in the video, just specify it every time.
This seems like a neat simple tool. What could be better? Well, I was a little sad that you can’t use emacs or vi edit keys on the pipeline, at least not as far as I could tell. This is exactly the kind of thing where you want to back up into the middle and change something. You can use the arrow keys, though, so that’s something. I also wished the scrollable window had a search feature like less.
Otherwise, though, there’s not much to dislike about the little tool. If writing a pipeline is like using a C compiler, up makes it more like writing an interactive Basic program.
