[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multilingual setup ...



On Wed, Feb 26, 2020 at 01:50:30PM +0100, tomas@tuxteam.de wrote:
> On Wed, Feb 26, 2020 at 01:34:13PM +0100, Albretch Mueller wrote:
> >  Most of us are multilingual. I want to set up different users with
> > different languages as default and then when I su into a shell as a
>                                                  ^^^^^^^^^^^^^^^
> > particular user and start, say, libreofice, firefox and Eclipse as a
> > certain user that would automatically change all Settings

> In this case, by setting the appropriate LANG (and/or LC_*, for
> finer-grained control) variables in whatever shell init code of
> said users (~/.profile, ~/.login -- if it's a login shell, but
> if you "su" it's probably not), younameit).

You'd definitely want to create a login shell as the target user,
not just a regular shell.

So,   su - targetuser

Not just   su targetuser

Then, as Tomas says, make sure the target user's shell's dot files are
set up to configure the locale variables correctly for that user.

If the target user's shell is bash, then you want to use either
~targetuser/.bash_profile if that exists, or ~targetuser/.profile
if the former does not exist.

If the target user's shell isn't bash, read the documentation for
that shell to see where and how to export the environment variables.

But wait!  There's more.

> > particular user and start, say, libreofice, firefox and Eclipse as a

You're talking about GRAPHICAL applications here.

Doing "su" in a terminal doesn't give you a graphical session as the
target user.  It only gives you a login shell session as the target user.

That login shell will not have the necessary mojo to run X11 or Wayland
applications against your X server (or whatever the hell Wayland is).

There are allegedly ways to use xauth in some sort of complicated
pipeline to pass the authentication credentials between the various
processes... but a much simpler way is to use ssh -X instead.

ssh -X targetuser@localhost

That gives you a login shell session as the target user, but it also
forwards X11 protocol communications over the ssh connection.  So,
the shell session can run X11 applications as the target user, and
have them talk to your X server, which is running as you, not as the
target user.

That should suffice to run *basic* X11 applications, like xclock.

But wait!  There's more.

You're not just talking about basic X11 applications.  You're talking
about web browsers, doing glob knows what, possibly involving
accelerated video hardware magic.

It may not be possible to forward the stuff that makes video hardware
acceleration work, over an ssh connection.

So, if "ssh -X targetuser@localhost" doesn't work out for you, then
you may actually have to fall back to the original plan of using
"su - targetuser", and then arranging for the XAUTHORITY stuff to
be transferred to the new session.

Good luck.  You're going to need it.


Reply to: