Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS

[Alan McKinnon]

On 01/02/2015 02:18, Adam Carter wrote:
>
>           If you've su'd to root, try 'su -' instead.
>
>
>     Thank you, that was it?
>     What difference does it make and why on some boxes it has to be "su
>     -" and on others simple "su" works.
>
>
> Read 'man su'. I dont really understand this stuff well enough, but a
> 'login shell', that is, one started by /bin/login, is setup with a
> different environment to a shell that's started by su (or by, say,
> cron). This is why a shell command or script may work for you when
> you're logged in, but not if you run it from cron. I'm sure other's can
> explain it more correctly and fully.


This stuff is complex the first time you run into it.

There are three kinds of shell depending on how you start them: login
shell, interactive shell, and non-interactive shell.

When you get a login prompt on the console and type your
username/password, you get a login shell. bash will have done it's full
complete start-up routine, will have read all the .bashrc and.profile
files, and will set up your default environment just the way you like it.

If you then type say "vi" at the command line, bash will launch it. vi
does not try and set up a complete new environment for you - what would
be the point? the shell already did it for you. So if you are at a bash
prompt, and type "bash", the running bash will start a new bash but
won't do the whole startup routine for you (exactly the same way vi also
doesn't try do it). The kind of bash shell is called an "interactive
shell", and it's different from a login shell. It's called interactive
because you get a prompt, you can type stuff at the keyboard and get a
response on the screen.

A non-interactive shell is what a daemon/service like cron gets when it
starts bash to run some program in the background. Almost all
programming languages have an exec() function where you can run shell
commands - these shells are also non-interactive. Why non-interactive?
Because a daemon can't type stuff the keyboard, doesn't have a screen,
and doesn't need $PATH set. It's a program, it doesn't need cute shortcuts.

When you run "su" you might want an interactive shell, or you might want
a login shell. Maybe you want to quickly run a command as the effective
ID of the apache user, but don't need to change your entire environment.
You run that as "su"

Maybe you want to run su and log in as root to do a whole lot of
maintenance. You decide you need root's full setup with PATH and
everything else for this, so you run "su -" (the "-" means "start a
login shell")



Well, OK, that's how it SUPPOSED to work. Usually it doesn't because
distros decide to be clever.

The files bash reads when it starts follow a convoluted path (see
INVOCATION in man bash) and your average user gets confused. So distros
"helpfully" make it easy for the user and rig it so that when you start
an interactive shell, it goes and reads all the startup files anyway. So
you don't get an interactive shell, you get a full-blown login shell!
So how do you get an interactive shell in a distro like that? Well,
errr, you don't.

This explains the different behaviours of su vs su - between distros.
Some, like SuSE have rigged it so there's no difference. Gentoo doesn't
do that because a) Gentoo sticks closely to upstream and b) Gentoo users
are not morons and don't need helpful distros dicking around with their
shells.



The topic of cron came up. A common issue is you run myscript.sh at the
command line and it works. Run it in a cron as you and it doesn't work.

Cron gets a non-interactive shell and $PATH is not set. So in cron, you
must call it like this:

/path/to/bin/myscript.sh

In cron, it's always best to use fully-qualified paths to all files
everywhere and always. Don't rely on startup profiles - those have
always been to make life easier for human users, and were never intended
to be used by system daemons.






-- 
Alan McKinnon
alan.mckinnon@×××××.com