Troubleshooters.Com® and Linux Library Present:
Sakura: The Versatile Terminal Emulator
Copyright © 2018 by Steve Litt
See the Troubleshooters.Com Bookstore.
CONTENTS
Sakura is a terminal emulator with the features and versatility like gnome-terminal, Konsole, xfce4-terminal and lxterminal. Tabs, several different color combos switchable by hotkeys, setting the font, all specified in a single file used only by Sakura. Unlike gnome-terminal, Konsole, xfce4-terminal and lxterminal, Sakura isn't beholden to a specific desktop environment. And unlike xterm, aterm and rxvt, it has an easy configuration file and works well with tabs.
This document overviews how to use Sakura.
Sakura manages multiple shell sessions using tabs, just like Konsole and Gnome-Terminal and xfce4-terminal. Here are the relevant keystrokes (by default as defined in the shipped sakura.conf):
You can change these hotkeys by editing ~/.config/sakura/sakura.conf. Note that the "Shift+Ctrl" part is contributed by an accelerator value in ~/.config/sakura/sakura.conf. Accelerator values have their own section later in this document.
You configure Sakura in file ~/.config/sakura/sakura.conf. And every time Sakura closes, it writes its current state to that same file. If you have the config file open in Vim and keep opening and closing Sakura, they can overwrite each other's changes to the file.
The best way to avoid such overwrite is the following simple recipe, repeated over and over:
Sometimes you forget and change Sakura's state, or perhaps you were forced to change Sakura's state in order to make your observations. Either way, you now need to follow the following recipe to smoothly change things. This recipe starts with closing Sakura after changing its state:
Nothing messes you up like having multiple Sakuras open while you're configuring Sakura. Use whatever facilities your WM/DE (Window Manager or Desktop Environment) gives you to check for other running Sakuras, or simply use ps ax | grep -i sakura. Make sure no Sakura sessions are running when you modify ~/.config/sakura/sakura.conf.
I like comments in config files. One great use of comments would be to state the terminal usage (local/normaluser, local/root, remote/localuser, etc) above each colorset in the config file. Unfortunately, every time Sakura exits and saves its state, it dumps any files starting with a pound sign (# while rewriting. Ugh!
If you need your ~/.config/sakura/sakura.conf comments enough to do some extra work and modify your config workflow, you can write your config to config.skel somewhere, and via a shellscript copy config.skel to ~/.config/sakura/sakura.conf. That way, your comments will always remain in config.skel. The downside is that you'll always need to remember to change the config in config.skel and then run the shellscript.
One other benefit of the config.skel method is that it gets rid of overwrite problems. After closing Sakura, you can just run the shellscript that copies config.skel to ~/.config/sakura/sakura.conf. As a matter of fact, an entire section later in this document is devoted to Config.skel Techniques
Wouldn't you rather have a GUI configuration tool than a config file? Let's pause for you to consider the question...
GUI config is easy and discoverable. A well written GUI config program spares you the responsibility of remembering config details.
Trouble is, though, that GUI config programs are seldom well written. Either they leave out important config options, or they contain logic preventing you from putting the config into a certain desirable and legal state, or the GUI config program doesn't stay in sync with the program it's supposed to configure. And all too often, the GUI config program is designed badly, lacking the discoverability that's the main benefit of GUI config programs in the first place.
In many cases, if your choice is between a config file only and a GUI config program only, the config file is the superior choice. This is especially true if the config file is less than 40 lines or it faithfully reflects the hierarchical nature of all configurations.
~/.config/sakura/sakura.conf represents this hierarchy using naming conventions, so if you really look, everything's relationship to everything else is clear. For more clarity, try the following manual procedure, which you can even use as a shellscript:
cd ~/.config/sakura mv sakura.conf sakura.conf.bup sort sakura.conf.bup | grep -i -v "\[sakura\]" > temp.tmp echo "[sakura]" > sakura.conf cat temp.tmp >> sakura.conf rm temp.tmp
The preceding shellscript (or manual procedure) alphabetically sorts the lines of your ~/.config/sakura/sakura.conf file. Because all lines start with the variable to be set, sorting these makes naming conventions very clear and makes for very easy configuration. However, the top line must be [sakura], so this script deletes the line with that string, places that string on top of the newly constructed file, and then appends the sorted file contents.
As discussed earlier, Sakura saves its state in ~/.config/sakura/sakura.conf. Such state saving is both a convenience and a hassle. Convenient because you can permanently configure with the user interface and never touch sakura.conf. A hassle for several reasons:
So I made the following shellscript, which copies the .skel to .conf each time Sakura is run:
#!/bin/sh cp -p ~/.config/sakura/sakura.skel \ ~/.config/sakura/sakura.conf if test $# -gt 0; then exec /usr/bin/sakura --colorset $1 else exec /usr/bin/sakura fi
I make all mods to the .skel file, keep all my comments, but if I ever need to, I can manipulate Sakura, see what changes are made to the .conf file on exit, and then incorporate those changes in the .skel file.
The preceding shellscript is enough for me, but using the .skel technique, you can enhance the shellscript to do more, like substituting a different font. You could even make the .skel file a superset of what's legal in the .conf file, you can give Sakura capabilities it's never had before. As just one example, you could have thirty colorsets defined in the .skel.
In the preceding section of this document, "Configuration Tips", it was pointed out that lines typically are in the form key=value. So the question at hand becomes, what if the file has more than 1 line for a given key, and those lines have different values? The answer is that, going down, every line setting the value of a key overwrites any previous settings of that key done in earlier parts of the config file.
DANGER!
In the config file, later settings of a given key overwrite earlier settings of that same key. If not caught, this can lead to confusing and ambiguous symptoms. There's never any reason to have multiple settings of the same key, so please delete one.
The sorting shellscript described in the preceding section, "Configuration Tips", is your best defense against such key duplication. Just look down the sorted file for duplicates. Or better yet, use the following command:
sort sakura.conf | find_sakura_dups.awk
The preceding assumes you've created the following AWK script, called find_sakura_dups.awk (tested in gawk), and placed it on the executable path:
#!/usr/bin/gawk -We
BEGIN{
prev = "initt"
reps = 0
FS = "="
}
END{
reps = reps + 1
if(reps > 1){
msg = "%d versions of %s: "
msg2 = "This is a problem, "
msg = msg msg2 "fix it!\n"
printf(msg, reps, prev)
}
}
{
reps = reps + 1
if($1 != prev){
if(reps > 1){
msg = "%d versions of %s: "
msg2 = "This is a problem: "
msg = msg msg2 "Fix it!\n"
printf(msg, reps, prev)
}
reps = 0
prev = $1
}
}
The preceding script, with a sorted version of ~/.config/sakura/sakura.conf piped into it, lists all lines with redundant keys. If no two lines have the same key, the command has no output, meaning the config file is OK as far as dupes are concerned.
The "Shift+Ctrl" is specified as an accelerator. Accelerators have their own section in this document.
Quickly and easily increasing/decreasing font size is a benefit bestowed by all too few terminal emulators.
Sakura gives you six colorsets to deal with. Why exactly six? I don't know, look in the source code. A colorset consists of a foreground color, a background color, a color for the cursor, and a hotkey (remember to combine it with the keys represented by accelerator set_colorset_accelerator, which is 5 (Shift+Ctrl) in the ~/.config/sakura/sakura.conf that ships with Sakura. The following is an example of a colorset specification:
colorset2_fore=rgb(255,255,0) colorset2_back=rgba(0,0,96,1) colorset2_curs=rgb(255,255,255) colorset2_key=F3
The preceding specifies a terminal with yellow text on a dark blue backround, the cursor is white, and you get to that colorset by typing Shift+Ctrl+F3. Note that the rgba() denotation is the same as the rgb() denotation, except that rgba() has the final argument, a floating point number between 0 and 1, corresponding to darkness. I've found no use for setting this to anything except 1, which mimics rgb(), so feel free to use rgb() without the fourth argument instead of rgba(). Also, if you want to express colors in hexidecimal, then precede the hex representation by "0x", as in "0xcc" instead of "204".
You can specify the starting colorset at the command prompt with the --colorset command line argument. For instance, sakura --colorset 5 runs Sakura with colorset 5.
Have you ever deleted a directory tree on your local computer, and then oops, you realize you were logged into the production machine? You'd better have good backups, and it's very embarrassing to tell the admin what you did.
It's for this reason I color code my terminal emulators. Normal user work on the local computer is black text on white background. Local computer, as root is lightcyan on darkred. An ssh session to another computer is yellow text on darkblue background, unless I'm logged in as root on the remote machine, in which case it's very dark violet on lightgreen.
So, if I wanted to root ssh to another computer, I'd want very dark violet on lightgreen, which on my computer is colorset 3, so I'd create the following shellscript, called term_remote_root, that looks like the following:
#!/bin/sh exec sakura --colorset 3Sometimes special cases can include different fonts to distingquish different situations. And keep in mind, because you can specify a non-default config file, you can have all sorts of such terminals.
Although there are six colorsets, and although you can change the font size in real time, there is only one font in a Sakura session. You specify the font with a single line in ~/.config/sakura/sakura.conf. The following are some examples of such lines:
So the canonical form of this line is as follows:
font=<TypeFaceName>,<Attribute> [<Attribute> ...] <Size>A few observations about the preceding:
A little trial and error is required to find an adequate font. Part of that trial and error is listing your computer's fonts. The modern way to list all your computer's fonts is with the fc-list program:
fc-list | less
But you don't need just any old font. You need a fixed width (monospace, non-proportional) font because that's what makes sense in terminals, and because Sakura renders non-fixed fonts by sliding skinny letters and symbols as far left as they'll go, rendering the text almost unreadable. Here are three examples of how you go looking for fixed fonts:
The following are three examples of listing probable fixed fonts:
fc-list | grep -i mono | less
fc-list | grep -i fixed | less
fc-list | grep -i typewriter | less
Between the preceding three commands, you'll probably find most of the fixed fonts on your system.
If you were to accidentally specify a proportional font for Sakura, skinny letters would move all the way to the left of their allotted spaces, making holes in the text and making it very hard to read. If you see a symptom like that, you've probably either specified a proportional font or you've written the specification with the wrong syntax.
Depending on your computer, your fonts installed, your WM/DE, and your visual acuity, your choice of fonts will be specific to you. The best way to find a good one is to trial and error through the fixed fonts listed by the fc-list command.
Accelerator values are defined in ~/.config/sakura/sakura.conf. They specify the non-printing keys in a hotkey combo. For instance, Shift+Ctrl is defined by an accelerator value of 5.
An accelerator key is a bitmask of anded constants of powers of 2. The following is a partial list of such powers of 2:
So an accelerator value of 5 specifies that the Shift and Ctrl keys must be pressed along with the key to invoke the action. Alt plus Windows would yield an accelerator key of 72.
Somewhat confusingly, hotkeys don't indicate the whole key combo. The following is the
add_tab_key=T
Obviously, typing the sentence "The tot tattled on Tommy for taking the turtle" would not add 9 tabs, so there must be some missing information. In fact, that information is elsewhere in the file:
add_tab_accelerator=5
In the preceding, 5 bitmaps out to 1 and 4, which represent the Shift and Ctrl keys. So typing Shift+Ctrl+t produces a new tab.
Sakura is much more featureful than discussed in this document, and its features are easy to use. Perform command sakura --help for more details, peruse the ~/.config/sakura/sakura.conf file for even more, and for the utmost info on this program's behavior, look at its source code.
[ Training | Troubleshooters.Com | Email Steve Litt ]