Grateful Disclaimer:

All content on this webpage is intellectual property of Adrian Vogel.
My sole contribution is the preservation of this page which has proven
to be of avail beyond expiration of Adrian's DESY account.


Adrian Vogel's "Technical Odds and Ends"


  1. Using Your Unique E-Mail Address in Alpine
  2. Default Values of Parameters in the Geant4 User Interface
  3. Mounting Your Windows Network Drives Using Samba
  4. Extracting Images from OpenOffice Presentations
  5. Sending Mails from Outside the DESY Network
  6. Logging In to Other Computers
  7. Composing Characters on the Keyboard
  8. Saving a Keystroke with Alpine
  9. Restoring Your Screen Resolution at Login Time
  10. Using a Digital Certificate with Apple Mail
  11. Finding Memory Leaks in a Program
  12. The Expert’s Tip on Using emacs
  13. Fast Copying from Host To Host
  14. Getting Rid of the xterm at Startup
  15. Pretty-Printing Mails from Alpine
  16. Accessing Additional Software Packages
  17. Worshipping the Forces of Evil
  18. Cronjobs with AFS Access
  19. Getting and Releasing TURLs
  20. Relieving EPS Files of Dead Freight
  21. Finding Files in the AFS
  22. Disposing of Mountpoints in the AFS
  23. Talking to the DESY LDAP Server
  24. Avoiding Subpixel Rendering on Your LCD Screen
  25. Decrypting S/MIME-Encrypted Mails
  26. Finding What You Found with grep
  27. Using Kerberos Under Mac OS X
  28. Tracing the Startup of Your Shell
  29. Storing Default Options for MySQL
  30. Recovering the Backspace Key in the Terminal
  31. Resetting the Terminal
  32. Changing Window Titles
  33. Listing Files in Strict Order
  34. Finding Dangling Symlinks with find
  35. Fetching Files via HTTP with Session Cookies
  36. Fending Off Batch Jobs
  37. Finding Hard Links in Your Filesystem
  38. Telling What cmake Makes make Do
  39. Distinguishing 32-bit and 64-bit Object Code
  40. Default Search Paths for Headers and Libraries
  41. Public-Key Authentication with SSH
  42. Using an Alternate Kerberos 5 Configuration
  43. Interesting Manpages to Read
  44. Running Parallel Processes with xargs
  45. Finding Volume Mountpoints in the AFS
  46. Using S/MIME with Grid Certificates in Alpine
  47. Building Geant4 on a Multi-Core Machine
  48. Suspending a Subshell
  49. Exchanging the Standard Output Streams
  50. Converting HTML to Lowercase
  51. Bending Symlinks to Another Target
  52. Sorting Items by First Occurrence
  53. Selecting a Language for Spell-Checking

Using Your Unique E-Mail Address in Alpine


Default Values of Parameters in the Geant4 User Interface

  1. Many commands in the Geant4 user interface have parameters with default values – either fixed or taken from the current value. You can display these default values by preceding the command name with a question mark on the command prompt:

    /gun/position 1 2 3 m
    ?/gun/position
    Current value(s) of the parameter(s) : 100 200 300 cm

    Please note that this will only work if the method “G4UImessenger::GetCurrentValue” is implemented properly.

  2. You can use the default value by replacing a parameter with an exclamation mark. This can be useful if you only want to change one of the rear parameters – maybe even without knowing the default values of those at the front:

    /vis/sceneHandler/create OGLIX
    /vis/viewer/create ! ! 200

    Note that this will only work if the parameter is marked as “omittable”. Maybe you remember that programs like PAW used the same convention.

  3. All commands in the user interface and their parameters will be explained when you put “help” in front. A single “help” will show you the whole command tree with the possibility to navigate around.

    help /event/stack/clear

    Be aware that the actual content of useful information in this built-in help may vary. However, the tree view will at least show you which commands (with which parameters) exist in the first place.


Mounting Your Windows Network Drives Using Samba


Extracting Images from OpenOffice Presentations


Sending Mails from Outside the DESY Network

  1. The DESY SMTP server (smtp.desy.de) will not let you send mails to non-DESY addresses when your mail client is running on a host that is not inside the DESY network. If you have written a mail on a non-DESY machine and want to send it to a recipient with a non-DESY address, you can use authenticated SMTP instead:

    In your mail client, set the outgoing mail host to smtp-auth.desy.de, enable a secure connection over SSL, make sure you connect to port 587 (instead of the usual port 25), enable authentication by username and password, and finally enter your DESY username and your common DESY password. Note that you need a Windows account to use authenticated SMTP – but you should have one by default, even if you have never used it. For further information, see the DESY IT pages on authenticated SMTP and on the Configuration of Mail Programs in general.

  2. Another possibility is to use a VPN connection to get an IP address within the DESY network. To do this, you need a VPN account and the proper client software on your local machine – see the DESY IT pages on Virtual Private Network at DESY.


Logging In to Other Computers


Composing Characters on the Keyboard


Saving a Keystroke with Alpine


Restoring Your Screen Resolution at Login Time


Using a Digital Certificate with Apple Mail

  1. If you’d like to use a digital certificate to sign and encrypt e-mails with Mail, you first have to convert the certificate and your private key to a format that can be imported into your keychain. Open “Terminal”, make sure you have your certificate and private key files at hand, and use the openssl tool to create a PKCS#12 (or p12) file:

    openssl pkcs12 -export -in usercert.pem -inkey userkey.pem -out usercert.p12 -name your_name

    Replace your_name with your full name (enclosed in quotes), if you like. You will first be asked for your PEM pass phrase, then you’ll have to enter an arbitrary password (twice) by which the contents of the PKCS#12 file should be protected. See the manpage of pkcs12(1) for details.

  2. Import the PKCS#12 file into your keychain. You can either select “Import…” from the “File” menu in the “Keychain Access” utility or simply open the file from the Finder – “Keychain Access” should be launched automatically. You’ll have to enter the password of the PKCS#12 file that you created just a moment ago. When asked for the keychain to which the certificate should be added, select your personal one (or a dedicated keychain that you only use for your personal certificates, if you wish). After that, your certificate and the corresponding private key should appear in your keychain.

  3. Your certificate must have been signed by a CA, but some of these authorities may be unknown and untrusted by default. This is not a major problem when you work with your certificate in a web browser, but the full chain of trust (including all CAs down to the Root CA) must be established in order to use the certificate in a mail client. Therefore, go to the web site of the CA that signed your certificate (e. g. the GridKa CA) and get the corresponding CA root certificate, if needed. Note that you should choose PEM format if possible.

  4. Import the certificate of your Root CA with “Keychain Access”. When asked where the certificate should be added, you should first verify the SHA1 and/or MD5 fingerprint of the certificate you are about to import (click on “View Certificates” to browse the contents of the file). Then select “X509Anchors” as the destination.

  5. Now you should be ready to sign and encrypt your mail using your digital certificate. Open “Mail” and make sure that the sender address you are using is the same as in your certificate. On the right-hand side of the toolbar in the message composing window, you should now see a small star-shaped icon, which you can select to digitally sign your message. If you have a certificate of at least one of your mail recipients in your keychain, another padlock-shaped icon will appear with which you can also encrypt the message.

  6. Your personal keychain is directly accessible with “Keychain Access”, but if you’d like to have a closer look at the “X509Anchors” file, you can inspect it with “Add Keychain…” from the “File…” menu. Open /System/Library/Keychains/X509Anchors to browse the contents of this file with “Keychain Access”. Once you’re done, you can remove it again with “File → Delete Keychain “X509Anchors””. Make sure you select “Delete References” in the dialogue that will pop up in order not to delete the file itself.


Finding Memory Leaks in a Program


The Expert’s Tip on Using emacs


Fast Copying from Host To Host


Getting Rid of the xterm at Startup


Pretty-Printing Mails from Alpine


Worshipping the Forces of Evil


Cronjobs with AFS Access


Getting and Releasing TURLs


Relieving EPS Files of Dead Freight


Finding Files in the AFS


Disposing of Mountpoints in the AFS


Talking to the DESY LDAP Server


Avoiding Subpixel Rendering on Your LCD Screen


Decrypting S/MIME-Encrypted Mails


Finding What You Found with grep


Using Kerberos Under Mac OS X


Tracing the Startup of Your Shell


Storing Default Options for MySQL


Recovering the Backspace Key in the Terminal


Resetting the Terminal


Changing Window Titles


Listing Files in Strict Order


Finding Dangling Symlinks with find



Fending Off Batch Jobs



Telling What cmake Makes make Do


Distinguishing 32-bit and 64-bit Object Code


Default Search Paths for Headers and Libraries


Public-Key Authentication with SSH

  1. SSH with public-key authentication allows you to log in to a remote host via ssh (or to transfer files with scp or sftp) without entering your password. To use public-key authentication, first create a public/private key pair with “ssh-keygen -t rsa” on your local host, then use ssh-copy-id to transfer the public key (usually named “~/.ssh/id_rsa.pub”) to the file “~/.ssh/authorized_keys” on the remote host.

    Take care of the access permissions for your private key – it must not be readable by anyone but you. ssh-keygen will automatically set the Unix access permissions (“mode bits”) to “600”, but keep in mind that this won’t help you if the file is stored in the AFS. Make sure that the ACL of the “~/.ssh” directory does not grant read access to anybody else, or move the private key to another, protected directory and create a symbolic link that points to it.

  2. When the private key is generated, you will be asked for a passphrase to protect it. On the one hand, an unprotected private key with an empty passphrase is dangerous, except you happen to trust all system administrators and everybody who might have access to backup data. On the other hand, a private key with a passphrase doesn’t seem to make much sense because you’ll need to enter its passphrase instead of the password for the remote system. The solution is the SSH agent, which can store passphrase(s) for your private key(s) in a secure way. Chances are that an ssh-agent is already running in local session after login. Just execute ssh-add once, type the passphrase of your private key, and you’re ready to go. Whenever you use ssh, scp, or sftp now, the SSH agent will provide the private key automatically. See the manpages of ssh-add(1) and ssh-agent(1) for further information.

    If you already have an existing public/private key pair, you can still add a passphrase to the private key by running “ssh-keygen -p”. Note that there is no need to make any changes to the “authorized_keys” file on the remote host(s) afterwards – this file contains only the public key, which never needs to be protected. The passphrase-protected private key will still match the initial public key.

  3. Keep in mind that public-key authentication is often not a good idea when AFS is involved, because you will not get an AFS token on the remote machine. Instead, try to obtain a Kerberos ticket for the remote host on your local host with kinit, and then log in via SSH with GSSAPI authentication instead of public-key authentication. Have a look at the manpages of ssh_config(5) and ssh(1) for details on ssh, and kinit(1) and krb5.conf(5) for further information on Kerberos.

    If you are sure that you want to access an AFS host via public-key authentication, keep in mind that “~/.ssh/authorized_keys” has to be readable for system:anyuser, because you will not have a token at the time you try to log in. Because “~/.ssh” should not be world-readable, you should only grant the “lookup” permission to system:anyuser, put “authorized_keys” into another, public directory, and create a symbolic link that points to it.


Using an Alternate Kerberos 5 Configuration


Interesting Manpages to Read


Running Parallel Processes with xargs


Finding Volume Mountpoints in the AFS


Using S/MIME with Grid Certificates in Alpine


Building Geant4 on a Multi-Core Machine


Suspending a Subshell


Exchanging the Standard Output Streams


Converting HTML to Lowercase


Bending Symlinks to Another Target


Sorting Items by First Occurrence


Selecting a Language for Spell-Checking


This page is valid XHTML — Last change: 2013-08-05 by Adrian Vogel, to be contacted via Michael Steder <michael.steder@desy.de>