Every once in a while it happens to me that while working on one of the 6 virtual consoles an error message pops up that I want to look up on Internet. But copy-paste between a virtual console and the desktop doesn’t work, let alone being able to select some text on the console with your mouse.
As long as the text is on screen in the virtual console, it is relatively simple to grab it from an xterm in the desktop with the command below. Just replace the number `2` with whichever console number you want to grab:
$ sudo setterm -dump 2 -file /dev/stdout
Ubuntu 12.10 diablo tty2
diablo login: jhendrix
Last login: Sat Dec 15 09:26:02 CET 2012 on tty1
Welcome to Ubuntu 12.10 (GNU/Linux 3.5.0-17-generic x86_64)
* Documentation: https://help.ubuntu.com/
*** System restart required ***
One of the most common little annoyances on Linux machines is troubleshooting cronjobs. You write a little script that you want to be run from cron and you test it extensively on you command line. Once the script runs flawlessly you schedule it to run somewhere during the night, only to find out the next morning that nothing happened.
Puzzled by why nothing happened you start running the script from the command line where, of course, all works fine. Searching for the problem you realize the environment when run from cron must be different from your normal shell. You start running the job from cron, adding debugging messages, redirecting the errors to a temporary file, and reconfiguring the crontab to run the job in one or two minutes … and again in one or two minutes … and again in one or two minutes … . Step by step every little (usually PATH-related) problem is solved by manually rescheduling the job. Struggling to find more details, waiting for cron to re-run the job, it can take a long time to solve all issues with the script.
If only you were able to run an interactive shell with an environment set identical as if it was run from cron! The script below does exactly that. It sets an excellent environment to debug scripts that are required to run from cron. It allows you to execute individual commands and inspect its result one by one, just like you would troubleshoot a regular shell script. No more waiting for cron to fire the job only find out you still overlooked another little issue.
The ‘cronShell.sh’ script below is an optimized version that can be directly used on most Linux machines. It automatically adapts for the current user.
# This script starts a shell with an environment that has
# identical environment as a shell script started from cron.
# More info: https://blog.linformatronics.nl/16/linux/troubleshooting−cronjobs
user=$( id -nu )
cd && env -i sh -c "
### Ubuntu Linux 12.10
And this is what it looks like when you run the script:
$ # Type your commands here ...
Credit where credit is due: This post is heavily inspired on an excellent answer by Stephane Chazelas on Unix.StackExchange.com.