The "bash" shell is so basic to all work that often I don't even think of it as an application (but just as part of the system). Nevertheless, it is, and it can (and should) be configured. Here's my current .bashrc file, with comments in it which, I hope, will be sufficient: dot-bashrc
The programs in imagemagick (e.g., "convert") use temporary files on disk when working with large images (and also when assembling PDFs out of series of images). By default, Arch Linux sets up its /tmp directory in a memory-based file system. This means that in a default configuration imagemagick is limited by swap space (which is rarely enough for really big images or composite PDFs). One way in which you'll see this is a failure to build a composite PDF and an error message to the effect that imagemagick was unable to expand the pixel cache.
The solution is to set the "MAGICK_TMPDIR" environment variable to point to a directory on some disk which does have sufficient space. For example, assuming the disk your home directory is on is big enough:
To make this durable, put it in your ~/.bashrc file. If you want to use imagemagick in your current bash session, or any already open bash session, don't forget to re-execute your ~/.bashrc file in the session:
Inkscape is a GTK-based application, so of course you have to configure GTK for sane FileChooser behavior before attempting to use it. See ../ Basic Principles: The CWD.
But even after you do this, you'll open up Inkscape and find that when you try to load or save a file the current working directory is nowhere to be seen. It is, though. Inkscape appears to invoke the GTK FileChooser in such a way that it highlights the "HOME" "Place" by default for opening and saving files, even if you've configured GTK to use the CWD behavior.
The solution is to click on the button in the "Place" list on the left side of the open or save dialog which is labelled "directory". This button means "Current Working Directory." During the remainder of your session, Inkscape will remember this.
By default, Inkscape will try to use the nowhere-space of GTK "recent" files for its File -> SaveAs dialog. In order to make Inkscape SaveAs into the CWD, you have to make sure that in File -> Inkscape Preferences -> Save the "Use current directory for 'SaveAs...'" checkbox is checked.
When you go to Save (or SaveAs) a file in Inkscape, it brings up a list of files. (We'll presume here that you've got the GTK CWD behavior configured properly, so that these files are in the CWD.) The files shown are not all of the files in the directory, though. They're limited to just the kinds of files that Inkscape thinks that you can save an Inkscape drawing to. Moreover, while there is a file type selector menu available, it is limited only to file types that Inkscape thinks you should be able to save an Inkscape document to. There is no way at all in Inkscape to have it show you all of the files in a directory, regardless of their type.
No doubt this seemed pretty slick to the developer. But here's an example of why it is not. Let's say you want to use Inkscape to annotate a bitmap image. (Example: you have a photograph of a machine and you want to label all of the parts for a parts diagram.) Inkscape is really good at this, while bitmap editors such as the GIMP are not.
The procedure here is to fire up Inkscape, create a blank New document, import the bitmap file into it (typically a PNG or JPG) and then draw away with Inkscape to label and annotate the image. When you're done, you save it in two ways: First, you probably want to save it as a regular Inkscape file, just in case you want to do more editing later. Second, you certainly want to export it to a bitmap format so that you can use the annotated bitmap image somewhere.
When you go to do either of these things, your file does not yet have a name (you created it as a new file, after all). But the chances are very good that you want to give it a name which is based on the name of the bitmap image file.
That's a perfectly reasonable file name (it describes a part on a machine that I am in fact documenting). But it's a long filename, and you don't want to have to retype it. Nevertheless, you probably want to SaveAs and ExportBitmap to files which have names like:
Wouldn't it be nice if your SaveAs dialog listed all of the files in the directory? You then just click (once!) on the PNG filename. It comes up in the text editing box. You change its end and suffix, and there you go - a very long (appropriate) filename with almost no typing.
Worse, this behavior will continue after the KDE application you started terminated. Running the first KDE application will set up durable KDE dameons (kdeinit4, kdelauncher, kded4). Any time a new KDE application starts, or any time KDE is poked in any way (e.g., by pacman during an upgrade), these will spew informational messages to the terminal window from which the first KDE application you ran was invoked (which of course messes up anything you're now doing there).
It is necessary, further, to alias each KDE application in my .bashrc so as to redirect both stderr and stdout (where no messages should be written in the first place!) to the bitbucket. For example, in ~/.bashrc:
alias okular='okular > /dev/null 2> /dev/null'
But even this may not be enough. It may be necessary to set aside the window you opened your first KDE application in. Just move it to a seldom-used position within your viewport and workspace configuration and forget about it (until you have to remember to do this again the next time you reboot or restart FVWM).
When using pysheng, I prefer manually to assemble the downloaded image files into a PDF. Sometimes this results in PDFs which appear at first to be invisible (or at least unviewably small - nearly single-pixel) when viewed with mupdf.
The problem is that pysheng sometimes creates images with incorrect resolutions (e.g., 7200.78 PixelsPerCentimeter). mupdf takes these values seriously, and displays an image that might be (in the same example) 0.09 cm wide.
convert -density 72 -units PixelsPerInch pages*.png document.pdf
One of the most worrying things about current Linux/GNU development is the way in which, time and again, the current developers try very carefully - after deep deliberation - to break things which work. As of late 2014, the "top" utility for displaying system usage was the latest victim.
The "top" program can display all kinds of information, but by default it has always displayed a brief system summary and then a list of running processes sorted by current usage. The busiest processes appear at the top of this list (no doubt why the program is called "top").
As of late 2014, the default was changed. It now appears in a shocking red, with orange highlights (in other words, about as ugly as it could be). Worse, it now displays a list of processes sorted by PID, not activity. This renders the program entirely useless - it simply isn't doing what "top" should do (show the top active processes). This is an important point: the program as it now is (in late 2014) is in its default configuration entirely broken - and its developers are proud of this.
Here is the git commit by Jim Warner describing, with some satisfaction, how he broke top: https://gitorious.org/procps/procps/commit/8ef6cd91fc5df6372a93bc4a37cbad34ead9654e
First, it may be revoked by rebuilding top using a "-disable-modern-top" compile-time option. There is an Arch Linux AUR package which does this: https://aur.archlinux.org/packages/procps-ng-classic/
The other option is to keep the official (that is, broken) top and write your own ~/.toprc file to restore something close to a workable version (in particular, to give a list of processes sorted by activity). One way to do this was outlined by user "procps-ng-sucks" (a fitting name) in an Arch Linux forum thread at: https://bbs.archlinux.org/viewtopic.php?pid=1475101#p1475101 The process described is:
remove your ~/.toprc (if any) start "top" press z press V press 1 press y press m m press t t t press W this will write a ~/.toprc fairly similar to what you are used to.
The vim editor is a splendid replacement for vi. Unfortunately, default configurations often enable some of its more annoying features. The worst of these are "syntax highlighting" (which results in a screen full of garish, unreadable colors) and parentheses-matching (which results in equally annoying colors, and a situation where it is impossible to know where the cursor really is in the string "()"). There is a place for the florid colored lettering of the circus, but it is not in vi(m).
syntax off let loaded_matchparen=1
(Note: don't type "loaded_matchparens" (as I did once) by mistake; it won't work. This line means that the module which matches parentheses is not to be loaded, not that the number of parentheses to be matched is 1.)
Some of the fancy features of vim are good (which is of course why I'm using vim in the first place). One that I have come to expect is vim's ability to open up an editing session on a file at the same location in the file that I was at when I closed the previous editing session on it.
It turns out that this is not vim's default behavior and that it must be added by some (slightly) tricky configuration and function definition in the ~/.vimrc file. This in turn saves the position to the automatically generated ~/.viminfo file each time. There are a couple of solutions to this, actually. I'm using the one documented by Charles E. Campbell in the vim wiki: http://vim.wikia.com/wiki/Restore_cusor_to_file_position_in_previous_editing_session
Here it is in my own ~/.vimrc file: dot-vimrc
The stock /usr/bin/vi with Arch Linux is (quite reasonably) a port of the "classic" vi (/ex) text editor. In particular, it appears (at least through 2014-03) to be the fork of "The Traditional Vi" by Gunnar Ritter (see http://ex-vi.sourceforge.net/). In either this classic vi or in vim if you type the
This is a good, very basic choice for Arch Linux. However, there are two ways in which this particular vi interacts with nmh which are problematic. One is just a minor surprise, but the other is a more serious issue.
When using nmh, if your .mh_profile file specifies "vi" as your editor rather than "vim" explicitly, nmh will pick up /usr/bin/vi rather than /usr/bin/vim because the shell invoking it is not an interactive one.
The second problem, though, is the "classic" vi returns a nonzero value when exiting if, previously, a vi operation such as ":r" had failed. This is a bug, because the editor itself is exiting correctly.
There is a packaging error in the Arch Linux k3b package which does not identify and pull in its two most important dependencies: the tools used for burning CDs and the tools use for burning DVDs. It isn't much use without them.
sudo pacman -S cdrdao sudo pacman -S dvd+rw-tools
All portions of this document not noted otherwise are Copyright © 2014 by David M. MacMillan and Rollande Krandall.
Circuitous Root is a Registered Trademark of David M. MacMillan and Rollande Krandall.
This work is licensed under the Creative Commons "Attribution - ShareAlike" license. See http://creativecommons.org/licenses/by-sa/3.0/ for its terms.
Presented originally by Circuitous Root®
Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]