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?
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 https://netsarang.atlassian.net/wiki/spaces/ENSUP/pages/135136512/Using+Scripts . In order to achive the forward, the following code is sufficient (don’t ask my why a sleep is needed here):
Setting up an enriched, system-wide prompt again raised the question where to put the definition code. Spreading the snippet all over the home-located profile-(.bash_profile) and resource(.bashrc)-files is a bad idea, tedious to maintain, you know, don’t ever think about it.
Changing the global profile- and resource-files (/etc/profile , /etc/bashrc) won’t be of any much more brain either, since yet another system update may cause conflicts with the maintainers version. Just reading along the web, I found that there is some mechanism integrated with /etc/profile to source homebrewed definitions from a file within /etc/profile.d . Great, this is what I want, but, as far as I remember correctly, a profile will only be sourced once, upon login, in a login shell, right?!
Oohhm, still can’t recite that poem on command. On login, we source the environment (profile). We won’t do that for sub-shells because the environment will be derived. However, since a login shell is also an interactive shell usually, we still addionally source the aliase- und function-resources as well… And so on and forth in bare theory, which has been depicted nicely in man bash, in the invocation section in particular. Read this now for reference!
On the other hand, living system may not stay with the initial ideas very long, in practice a question may have a multiple of answers (or the other way round). So I parsed and instrumented the profile- and resource-loading process to see what really happens under the bonnt. See what I’ve found.
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 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:
I’m not shure, though, whether tmp.mount.hm4: After swap.target 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.