Anyone familiar with splitvt?
 

Hi: when I run splitvt (with no options) I see that I loose some of the environment variables, namely: ls -l in my system prints the date as numbers (e.g., 2013-02-17). Within splitvt, it displays the month as a name, 'jun' for example. Also, the aliases are lost. In the man page there are listed the options, which are only a few, but I do not see a way to preserve the environment.

The shell is the same as when outside splitvt: bash. But the instances of bash launched by splitvt do not inherit the environment. I'll see in the /etc scripts if the ls options are exported or not. Any particular file to look for those options? Specially that which governs the date format.

maybe not the answer you need, but for that I use the splitting functionality of tmux (libevent is the only dependency not already in Slackware, both are on SBo).
it has substituted screen on my installs and I've never looked back since.

side note: if you want to use it with "ctrl-a" like screen, you need just a minimal ~/.tmux.conf
(but be aware that in this way "ctrl-a a" -to go at the beginning of the line- won't work -in screen it does)

Thanks, I'll investigate the advantage of usin tmux. For the moment, the offending variable seems to be LS_OPTIONS. This variable is set and exported in /etc/profile.d/coreutils-dircolors.sh. The ls man page does not mention any environment variable that governs its behavior.

In fact, what happens is that 'ls', in that script, is aliased so:

alias ls='/bin/ls $LS_OPTIONS --time-style=long-iso'

splitvt, or any other utility for that matter, does not inherit the aliases, in particular this one, time-style is given the value long-iso. I wonder if it inherits (this is slackware 14.0 x86_64) the $LS_OPTIONS, which the script exports. If it does, then I could include the time-style option within LS_OPTIONS.

However I really do not know who uses this variable. What is it purpose? Do you know?

the answer is written at the beginning of /etc/profile.d/coreutils-dircolors.sh (the options set there apply to the ls command already, as it's aliased)

I see ...! Its only purpose is to build (or set) the alias. It is NOT used outside the script. And yet, why is it exported?

Anyways, splitvt starts bash as a non login shell, and then bash does not execute the /etc/profile.d/ scripts. I assume I could place the necesssary stuff in ~/.bashrc. But is there not a way to set things up for non login shells in a system wide way?

No, you're still not understanding it. Notice the use of single-quotes on the alias definition: $LS_OPTIONS will be treated as a literal and only expanded when you actually use the alias. If they had been double-quotes then your above statement would have been correct.

I do not see any relevant difference. LS_OPTIONS is not used outside the script that sets it. This is the fact that took me so long to understand. Hummm...

When I type 'ls', the shell gets 'ls $LS_OPTIONS et cetera'. It then substitutes the variable value, and everything happens as if i had typed 'ls -F -b -T 0 color=never etcetera'. So, I was wrong. LS_OPTIONS _is_ used outside the script! It is used by bash.

In view of my other thread on the more specific question of shell scripts and non login shells is not getting any feedback (holy impatience), I'll tell you the following, guys:

splitvt launches non login shells. Therefor, bash does not read the /etc/profile.d/ scripts when when called by splitvt. And therefor I lack the ls alias, so carefully set by coreutils-dircolors.sh.

My solution: I wrote the following ~/.bashrc:
And voilà. Still it's only provisional, as I intend to make this behavior for non login shells system wide. But in order to do that I will have to read some 10000 lines of the bash man page, to find where it speaks about login/non login shells and interactive/non interactive shells (perhaps some strokes of the slash key will help).

Slackware's bash is not compiled to support a global /etc/bashrc (or /etc/bash.bashrc) so you could either add a default .bashrc in /etc/skel that gets copied to a new user's home directory upon account creation or recompile bash to enable global bashrc support. If you do want to recompile bash, then adding the following to the CFLAGS variable in the SlackBuild should work (though I haven't tried this):
(There may be some quoting issues so you may need to surround /etc/bash.bashrc with \" but again I haven't tried it.)