On Sun, Oct 17, 2021 at 06:35:01PM +0200, deloptes wrote:
> 2. and another pesky thing is starting a konsole to do work, needs a
> $PATH modification that we used to put in ~.profile. But opening a
> terminal hasn't called a ". .profile" since about jessie. So thats
> another PITA.
>
> So, what has replaced .profile as the function for such as that in recent
> releases?
AFAIK bash is not reading profile when you login, but not sure - it
could be
also that it is not a login shell.
AFAIK you should open the terminal with "bash --login" to read the
profile.
So try in the terminal "bash --login"
I have put in my .profile
alias bash='bash --login'
long time ago
OK, first thing first: that alias won't do *anything* useful. If Gene
is talking about starting a terminal from his window manager or desktop
environment, that terminal is going to run $SHELL which is /bin/bash.
It will not look at his aliases, no matter where they're defined. It's
just going to run bash. Not "bash --login".
Now let's step back a bit.
When you run an instance of a shell, there are two ways you can do it.
You either run a "login shell", or a "non-login shell".
The purpose of a login shell is to be executed when you login. That's
the original intent. Back in the 70s and 80s, there was no such thing
as a "desktop". There was just the shell. You logged in by connecting
your terminal or your modem to the host system, and getting a textual
prompt. After authentication, you were "logged in", and the system
would
run your account's shell with a "-" character in front of it. This is
the ancient way that your system said "this should be a login shell,
not
a regular shell".
It looks like this:
unicorn:~$ ps -ft tty1
UID PID PPID C STIME TTY TIME CMD
root 699 1 0 Oct09 tty1 00:00:00 /bin/login -p --
greg 851 699 0 Oct09 tty1 00:00:00 -bash
greg 863 851 0 Oct09 tty1 00:00:00 /bin/sh
/usr/bin/startx
[...]
See where it says "-bash"? That's my login shell.
The purpose of having a "login shell" and a "regular shell" is because
you probably have some things that you need to do once per session,
when you login. Like, setting up your environment variables. Or
printing today's calendar, or today's message from the administration.
All of those things are unnecessary in a regular shell. The
environment
is already set up, and you've already seen today's calendar or
whatever.
Any other time you started a shell, it would not have a "-" in front of
its
name, so it would be a regular shell. This included shell escapes from
your text editor or mail reader or news reader or pager. Any time you
escaped to a new shell from inside your editor, you didn't need to go
through all the gyrations that a login shell did. You don't want to
see the calendar again, etc.
A decade or two later, some people developed a windowing system.
In this windowing system, there's a terminal emulator. Normally when
you
run a terminal emulator, you run a shell inside it. (Not always, but
usually.) This shell doesn't need to be a login shell. You're
probably
going to open half a dozen terminal emulators with shells in them,
maybe
more. You don't need to run the day's calendar, or set up the session
environment, in every single terminal. All of that has been taken care
of already. (Right?)
So, in an X terminal emulator, you normally run a NON-login shell.
Just
a regular shell.
That's how it's supposed to work.
However.
Some people found that they had a really hard time getting their
initial
environment set up during their X logins. This was common among
newbies
especially, because they didn't understand the new login procedure, and
had no idea how to customize it.
And where did we have a shit-load of Unix newbies? Universities.
So, in the world of academia, there is a whole different paradigm. In
this world, where everyone is expected to be incompetent, the old way
of setting up your environment one time and inheriting it in every
shell... that doesn't work.
In the newbie-centric environment, where nobody knows how to do
anything
correctly, terminal emulators are configured to run login shells.
There's an option for it, of course. The people who wrote xterm
realized
that one might wish to run either a regular shell or a login shell. So
xterm has this option:
-ls This option indicates that the shell that is started in
the
xterm window will be a login shell (i.e., the first
character
of argv[0] will be a dash, indicating to the shell that
it
should read the user's .login or .profile).
Universities configured things so that their users' terminals would all
run with this option, which means the users would get a login shell in
each terminal.
And then the users, who were all newbies and don't know any better,
could
simply be told "if you want to change your environment, edit this one
dot file". (In academia, csh was the dominant shell, so the file in
question would usually be .login as the xterm man page hints at. In
most Linux distributions, the shell is bash, so the file is .profile
or .bash_profile. But in any case, there's just *one* file for the
user
to worry about, and support calls are reduced.)
In modern times, the place where we find nothing but newbies as far as
the eye can see... is called Ubuntu. If you get a question from an
Ubuntu
user, they're probably completely inexperienced, and know virtually
nothing. Therefore, in an Ubuntu setup, it would make sense to strip
everything down so there's only one way to do things. That makes it
easier to answer questions. You don't have to *educate* the user. You
don't have to help them understand anything. You don't have to explain
why things work they way they do. You just tell them "edit this file".
In Gene's old environment, someone had clearly gone Academia/Ubuntu on
him, and had configured his terminals to run login shells.
This isn't *wrong*. It's a way to do things. But what it means is
Gene
was operating in Ubuntu-user mode for all that time. He never learned
the original way to do things, or why he was using the simplified way,
or
even that there *was* a choice of ways.
So, that's the history and background.
Now we're back to the present. The question, I believe, is:
**** How do I set up my environment? ****
This is not a trivial question to answer, because there are so many
different possible setups. It all depends on how you login.
1) If you ssh into the system, then you get a login shell. This login
shell *is* your session. So, all you have to do is set up your
login
shell environment.
If your shell is bash, then you edit the file .bash_profile if that
exists, or .bash_login if that exists, or .profile if neither of
the other two files exists.
On a regular Debian system, there is no .bash_profile or .bash_login
file, so you'd simply edit .profile. That's the only file you have
to worry about for your login enviroment.
2) If you login on the Linux console (/dev/tty1 and so on), in text
mode,
then you *also* get a login shell. So everything is the same as the
ssh case. See above.
Even if you start an X session (by typing "startx"), your
environment
has already been set up by your login shell. You don't need to set
it up again inside the X session. The X session inherits the
environment from the login shell, and then the terminal emulators
inherit it from the X session, and the shells that run inside the
terminal emulators inherit it from the terminals.
3) If you login to X11 with a graphical display manager, everything
is completely different. You do *not* get a login shell as your
session. You don't get a login shell at all. Ever. (Unless
someone
went and Ubuntu-fied your terminals.)
In this case, you can have one of a few different types of session.
Because why would anything ever be simple?
If you use a standard Debian X11 session, you can configured it in
one
of two different ways:
a) If you have a .xsession file, this overrides the system's X11
session. You control exactly what gets executed. You can
configure your environment in the .xsession file, or you can have
it dot in a shell configuration file. You just have to know what
you're doing.
b) If you use the standard system session, Debian lets you customize
it in the .xsessionrc file. This gets dotted in by the session
before it starts running X apps. So you can configure your
environment in this file.
.xsessionrc is unique to Debian. It's not found on other Linux
variants. Some other Linuxes introduce .xprofile or other files.
And then there's GNOME. Because obviously GNOME has to be unique
and
have its own separate session type, and its own way of doing
everything,
none of the answers above applies to GNOME. Except maybe the
.xsessionrc file. I think Debian still arranges for GNOME sessions
to dot that in. Maybe. Don't quote me on it.
(But don't think that your job is done if you manage to export
environment variables from .xsessionrc. Oh no. GNOME is *so* much
worse than that. It's so bad that I won't even try to describe
it here. It needs a whole thread of its own. We've had several
over the years.)
4) And finally there's Wayland. I don't know what the hell Wayland
does.
Nobody who uses it has ever told us how it works. You won't find
any
useful information about it on the Debian wiki, etc.
See also:
https://wiki.debian.org/Xsession
https://wiki.debian.org/EnvironmentVariables
