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.mckin...@gmail.com
