I installed Slackware Current a couple of weeks ago -- am finding little tweaks that need to be addressed. For years I've added "--time-style=long-iso" to OPTIONS env variable in /etc/profile.d/coreutils-dircolors.sh to set my ls time style. This gets exported in LS_OPTIONS.

When I log in using Konsole, LS_OPTIONS is empty. Maybe this is normal and I just never noticed it before. I suppose that's possible as I usually ssh from there to other hosts.

If I su to myself (su - myid), LS_OPTIONS are set.

How to I get this to set when I simply open Konsole? Do I have to source /etc/profile.d/coreutils-dircolors.sh in .bashrc? That seems wrong, but it that's what I should do, I'll do it.

An easy check is to make sure that the /etc/profile.d/coreutils-dircolors.sh file is set to executable. The /etc/profile script checks /etc/profile.d for executable scripts and sources them if they are set to be executable.

This is what I have. This is what is set in /etc/profile.d/coreutils-dircolors.sh. This is the default.

In the profil menu and the main tab, what command do you have : I have '/bin/tcsh -l'. You can have '/bin/bash -l'

'-l' is for login shell. Else it won't call '/etc/profile.d'

Personally I think running a 'login shell' inside of a terminal emulator is a mistake. Better to put your aliases, PS settings, and what have you in ~/.bashrc.

Then, if you want to tie profile and bashrc together, so that your customisations are also available to login-shells, then just add this to the end of /etc/profile, or your user's ~/.bash_profile

1 members found this post helpful.

As mentioned above by @BrunoLafleur I have this the "Command:" field for the Konsole default profile "/bin/bash -l"

I've been doing this for years. I see nothing wrong with it.

I have /etc/profile.d/coreutils-dircolors.sh "sourced" in .bashrc,
then I edit LS_OPTIONS
export LS_OPTIONS="$(sed 's/-F//' <<<"$LS_OPTIONS")"

Depends what's in your /etc/profile.

Simple example:

/etc/profile resets PATH, so any additional directories that might be in the $PATH of your X11 environment may be removed if you start a terminal window with a login shell. I guess it all boils down to whether you want that behaviour or not, and whether you see the terminal window as conceptually part of your X11 environment, or a standalone tty.

Thanks all for your feedback. chrisretusn - that did the trick! Adding -l to the Command; field of the profile invoked coreutils-direcolors.sh and set the LS_OPTIONS as I configured. Thanks. I don't think I'd have ever figured that out!

Thanks for the explanation. I don't change things in /etc/profile. The only things I setup are aliases. I do that with .profile in the user home directory.

I'd be interested in hearing your reasons for this. I've long not understood why someone would want to have a different environments when using a login vs non-login shell. For me, I just make EVERYTHING a login shell to make sure I know that my environment will be the same no matter how I access the shell.

In response to your post later on:

Is this a real thing? I've never noticed WMs/DEs add additional directories to the PATH variable. I checked this on my 14.2 install running KDE4 by launching xterm (I normally use konsole with a login shell), echo'd $PATH, then ran bash -l and echo'd $PATH again and they were the same. I don't have a .profile or .bashrc. I could tell they were non-login and login shells respectively since my PS1 changed when I ran bash -l.

NOTE: This isn't to call you out or anything, but to try and improve my knowledge on the subject. I've read things throughout the years on the subject, but nothings seemed to stick on why I should use non-login shells over login shells.

Yes, no worries.

For the PATH example, I'm not aware of anything that does this out of the box, it was just an obvious example of why it could potentially be an issue. As an actual example of why one might want to do something like that, one might not want all the X11/GUI programs in the PATH of a tty shell that isn't even able to run them (well not without setting DISPLAY to point to a remote X11 server anyway), so having them in a separate directory that only gets added to the PATH of an X11 session would make sense. In fact, didn't we used to have something like a /usr/X11R6/bin in the old days for exactly this reason?

On the more general topic, clearly the designers of the UNIX shell decided that it was important to differentiate between login and non-login shells and that some programs might need to only be started for login shells: things like gpg-agent spring to mind, where one might want gpg-agent starting in /etc/profile of a tty console login shell, but that an X11 equivalent would be started by xinitrc/xsession and so it would be inappropriate to have another instance started in each and every terminal emulator shell.

It's also worth mentioning that unless run as /bin/sh, bash doesn't follow the traditional shells invocation methods: using /etc/profile and $ENV. Putting a call to bashrc at the end of /etc/profile goes some way to making bash work something akin to the more traditional invocation model, though not exactly the same.

As I said in my original post here, I still think it's a mistake to run a terminal shell as a login shell, but in practice, these days, I doubt it will make any practical difference to most people, and I'm probably just being a purist.

I suspect much of the reasons why these things are done the way they are have been lost to time, except for a few old farts like me who still remember and cling to the old ways.

Hope that made at least some sense.

1 members found this post helpful.

I appreciate the response. It's always interesting to read peoples' reasonings when they do something different than I do. I can definitely see examples like gpg-agent being a valid reason to separate login vs non-login shells.

I think this is ultimately the conclusion I come up with when I do research this. There's probably good reasons it was designed this way, but most software probably doesn't take those into account anymore. If I run into an issue using login shells everywhere, then I'll likely decide to switch to using both, but I just haven't noticed any issues in my particular usage.

Again, I really appreciate the response! I definitely learned some stuff with it.

Personally, I use always login shells in a terminal, with some exceptions of dedicated terminals lauched by an application.

Also scripts are non login shells as they need less generic initialisation.

But everyone is free to have his strategy.

I do like that since maybe 30 years or more.