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:
MAGICK_TMPDIR=$HOME/.magick_tmpdir;export MAGICK_TMPDIR
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:
source $HOME/.bashrc
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.
See also ../ Basic Principles: The CWD -> A Hiccup.
But you'll need to click on this button each time you invoke Inkscape. There doesn't seem to be a way to configure correct default behavior.
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.
On my Arch Linux installation it was checked in the default configuration (good).
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.
So for example say you have a photograph with the filename:
thompson-typecaster-vertical-mold-blade-cam-lever-2013-02-04-hires.png
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:
thompson-typecaster-vertical-mold-blade-cam-lever-2013-02-04-hires-annotated.svg thompson-typecaster-vertical-mold-blade-cam-lever-2013-02-04-hires-annotated.jpg
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.
Inkscape refuses to let you do this. You are not allowed to view a PNG or other bitmap image file in an Inkscape SaveAs dialog (you can from ExportBitmap, but that doesn't help).
This is, in my opinion, a bug. I know of no way around it through just Inkscape configuration.
KDE applications seem to be designed to spew endless warning and informational messages to both stderr and stdout.
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).
This is due to a combination of bad design (it's a poor way to handle messages; they should go to an appropriate log file) and bad testing (apparently nobody in KDE ever runs a terminal window.)
In theory one should be able to disable this by running:
kdebugdialog
(You can run it even without KDE.) Then turn all debugging information off.
In practice I find that this is not enough. Not all of the messages are debugging messages. Many (most?) of them are simply KDE acting like a verbose happy puppy telling you everything it did.
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.
The solution is to specify a rational resolution in the PDF conversion. Thus (continuting this same example):
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
Fortunately, this vandalism is fixable in two ways.
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/
Unfortunately, this approach means that you have to maintain your version of top manually via AUR; it won't get updated automatically with pacman -Syyu.
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).
To fix these, in your $HOME/.vimrc file, add the lines:
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
(Of course, change this file's name back to ".vimrc" if you want to use it.)
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
:version
command, you'll get the identity of the editor. If it returns something like "Version 4.0 (gritter) 3/25/05" then it is Gunnar Ritter's classic vi. vim will always return "VIM - Vi IMproved ..."
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.
If you set up your system to use vim by aliasing vi to vim in your .bashrc, then non-interactive bash shells will not pick this up. They'll use /usr/bin/vi instead.
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 minor annoyance here is that the "classic" vi does not implement filename autocompletion on ":r". This is not important, but can be startling the first time you use it.
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.
This bug in turn causes the nmh "whatnow" program to fail, and thus nmh as a whole to fail for mail sending.
The solution is to specify vim (or, to be paranoid, /usr/bin/vim ) explicitly in your .mh_profile file. See ../ Mail with nmh -> The ~/.mh_profile Configuration File.
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]
