As idle musing, and a way to show off my mastery of shell pipelines, I was wondering what my most-used shell commands are. It’s an easy few commands to pipe.
history | sed 's/^ *//;s/ \+/ /g' | cut -d' ' -f 2 | sort | uniq -c | sort -n | tail -n 20The outcome is rather expected. I feel validated (by my shell) in my own self-perception!
Continue reading
It’s always a bit confusing to reason about which startup files bash(1) is going to run in a given situation. It is documented, but the logic is not trivial.
So I made a chart (using PlantUML!). You’re welcome.
EDIT: There is also one for zsh(1) (PlantUML).
The main takeaway from this exercise is:
Continue readingIn
shmode,bashandzshdo slightly different things.
I finally mastered the shell (beit bash or zsh, but really, this is readline)’s history with command replacement. It took me 19 years and my entire family fortune to gather enough wits to read that part of the manual with enough attention and will as to learn to use it.
Essentially, you can recall previous commands from the history with !number. You can then change some content of the previous command programmatically before running it by adding :s/PATTERN/REPLACEMENT/ or :gs/PATTERN/REPLACEMENT/ (the first one will replace the first occurrence, the second one will replace them all).
We’ve been here before, but Oracle keeps being a pain in everyone’s rear end. This time, we want to keep testing against version 7 of the JDK with Travis CI.
security export -k /System/Library/Keychains/SystemRootCertificates.keychain -t certs -p
Useful for plain Unix/OpenSSL tools.
I’ve long been meaning to store all my passwords in a single, safe, location, as a way to remain sane as well as safe. But which one? Every operating system (or desktop environment) now has its own store, but choosing one casts a lot of things into stone, and most have a lot of third-party dependencies.
KeePass seems to be a good cross-platform solution, with clients for Linux, Windows, OS X and even Android, and nice features such as filling on demand. But I don’t like the whole clicky interface, if only for use without graphical display. It also doesn’t offer a native way to synchronise the stores across boxes.
For a while, I have been storing all my important configuration files in a git repository, with some make magic to install and update the files on the system. This magic would also store all passwords in a GPG-encrypted files, and replace them when installing the files.
The problem, of course, is that the passwords are still in plaintext in the live systems. And it came back to bite me when I sent an innocuous script (the ics2dav.sh script from this post) to a friend… with the password nicely sitting there. Fortunately, I noticed this before him, and changed my password. In addition, this doesn’t cater for passwords stored in other applications, such as Firefox.
So things had to change. And I discovered pass(1), a simple command-line tool based on GPG-encrypted flat files, with an option to sync natively with Git. So there is finally an option for me to store passwords in a way which fits my workflow.
Continue reading
I recently realised that the QNAP TS-212 NAS (running the latest QTS 4.2.0) can be used as a print server. No need to keep another machine on to print from anywhere!
Both UNICES, through CUPS, and Windows, through Samba, can use the printer straight-away. In the case of the Samsung SCX-3205, the driver under ArchLinux is the samsung-unified-driver (from AUR) which, fortunately, doesn’t install any useless binary beyond those needed by the PPD used by CUPS.
client$ pacman -Qs samsung local/samsung-unified-driver 1.00.36-2
The problem is that this is a combo printer/scanner. Moving the printer to the NAS requires a similar solution to CUPS to scan from the network. Fortunately, SANE can do this, and there is some documentation about setting it up on a QNAP NAS. In this case, however, this did not work smoothly, so I had to fix a few things.
It is bad practice to use make install. Period.
Why? Because it installs files everywhere on your system—if you’re lucky, only in /usr/local—with no guaranteed way to cleanly remove them afterwards.
Yet, sometimes, there is no other option, for example if some software is not packaged for your Unix of choice and you don’t have time to do it yourself. There are some easy and rather straightforward ways around it, which I usually recommend to beginners.
It happened again today. So I recommended the use of /opt/PKG-VER as an installation prefix and stow(8) to make the software seamlessly available to the rest of the system. Nothing fancy or novel, but I thought I’d share the summary email in the hope it would help others.