Forward the $term variable to debian the xshell-way

Xshell is yet another putty-like terminal client for windows that features a couple of nice extensions. See the net for a multitude of alike “top-10 terminal clients for windows” posts. Among the features, Xshell does not only provide a raw terminal pane but also runs a so called local shell that actually embeds remote shells. In other words, initially (standard configuration) you get your xshell window, running the Xshell shell and offering a number of internal commands to act in the realm of Xshell by means of simple keystrokes. If you’re addicted to the keyboard, like me, this is a very pleasent way to go. For example, see the help output, a list of available sessions (connect profiles already configured) and an open to eventually connect to the remote host:

Anything keyed and, by the way, the session name even tab-expanded after a few characters. Cool, right?

Ok, that much for the preface, important to understand what followes next, the forwarding of a dedicated environment setting, namely TERM=xterm-256color with this terminal client (see why e.g.:, see others e.g.:

The point is, based on the local shell, Xshell is able to inject/communicate code the the remote shell in an after-login but pre-(final-)prompt fashion. All you need to do is to code a snippet to call some member functions of the current local shell Screen object. Three language binding are possible so far: js, py and vbs. Examples are given in AppData\Local\NetSarang Computer\6\Xshell\Scripts\ScriptSample, documentation resides as . In order to achive the forward, the following code is sufficient (don’t ask my why a sleep is needed here):

def Main():
	xsh.Screen.Synchronous = True  # True or False
	xsh.Screen.Send("export TERM=xterm-256color\r")

The file location can be configured in the sessions connect profile dialog like so. Done!

After all, the tiled and full screen view modes are also worth a try. Like it.


Some useful terminal color scheme settings (mc, yast) on sles linux

I’m not very much into suse linux, only lately for a couple of times. However, I want to share these settings to be injected on each and every new system for essential readabilty of some console screens. Problem is, for some apps, midnight commander and yast so far, the default color scheme settings provide that less contrast, see below, that you’re literally guessing pixels instead of just reading text.
As given in the referenced posts, only small tweaks are actually necessary to achieve much better results, I’ll give examples as well, so go for it, don’t postpone to the next and the next and the next… login 😉


Getting LauncherFolders up and running on Ubuntu 16.04.4

LauncherFolders ( , is a great extension to the unity launcher, in being lightweight abd shipping a lot of bang when it only comes to set up containers organizing your apps. However, obviously the code has been crafted back in the Ubuntu 14.04 era, leaving open issues for installation on more modern Ubuntu releases.

First of all, the official ppa (ppa:asukhovatkin/unity-launcher-folders) will no longer register successfully for security reasons such that one has to ressort back to the original deb installation medium (

The next fixes, run the app from the console to see the error messages, are documented in ( and ( , comment #5):

sudo apt install python-gobject python-pil
gksudo gedit /usr/lib/python2.7/dist-packages/unity_launcher_folders/
#17 change: "import Image" -> "from PIL import Image"

Getting this far, the app itself comes up and is operable as expected. Pity is but, that the folder pane does not show up when clicking the generated launcher item (though it worked in the preview mode). The launcher item itself is nothing more than some .desktop file in (~/.local/share/applications/Browser.desktop). On inspection, we have this exec entry:

Exec=/usr/share/unity-launcher-folders/ "/home/anyone/.appDrawerConfig/Browser.pickle"

Giving it another console output run reveals another missing python dependency:


Oracle linux 7.x reboot systemd swap target timeout workaround

There is an issue around currently for Red Hat based systems, Oracle Linux here, in version 7.3. running systemd version 219-30.0.1, having a shutdown or reboot seemingly hang on a failed swap unit (deallocation). A lot of posts on the net discuss the issue, After switching to Ubuntu 15.04 laptop won’t shutdown suggested the w/a, doing a swapoff/swapon bounce in advance, that worked for me, referencing reboot hangs at ‘Reached target Shutdown’. Systemd: Hangs indefinitely on >90% of reboot attempts comprises in in-depth analysis.

I’m not shure, though, whether tmp.mount.hm4: After is releated, really, because the implemented change is already present on my systems (systemd‘s). I’m much more tending to suspect widespread storage fragmentation on the swap area to cause the relatively long term swap off run-times. In addition, I almost only experienced the issue for systems that have been up for a longer number of days, say from 90 days onwards.