Should I be using su or su - for software installation?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
As far as I can see it, su - is the same as su -l whereby the 'l' stands for login. So this gives a 'true' login shell as opposed to su which simulates a root environment without changing environmental variables. So su -l means the user is performing tasks as if they had logged in as root as a primary user.
As for PATH, so this is the variable that tells the OS where to locate a particular program. I have never had a problem launching a program from the command line after installing with su [mind you, I often don't launch via the command line].
Last edited by Lysander666; 05-21-2018 at 09:10 AM.
I think you misinterpreted it a bit:
su will start a new shell which is owned by root (or owned by the user specified with -l <user>). It does not simulate anything, just start a new shell.
The difference between using and omitting - is: how the environment of the new shell will be set. Using - it will be reinitialized like a login shell, without - it will be just inherited from the parent process.
see man su:
Quote:
A mere - implies -l. If USER not given, assume root.
if you add them to your user, you can compile even via fakeroot
and install via sudo or su, if wanted
I listed PATH as only one example. There are often others one needs as root. Why take the risk of just doing "su" when you know "su -" will setup the environment the way it should be for root? Why put things in user environments that they may not need and/or shouldn't run even if they could?
In addition to things being in root's environment that may not be in the regular user's (that did the su) environment is the opposite issue. There may be things inherited from the regular user's environment that you don't want in root's if you only did "su".
I listed PATH as only one example. There are often others one needs as root.
not for building software, if there would be , than this is a problem in the software
Quote:
Originally Posted by MensaWater
Why take the risk of just doing "su" when you know "su -" will setup the environment the way it should be for root? Why put things in user environments that they may not need and/or shouldn't run even if they could?
In addition to things being in root's environment that may not be in the regular user's (that did the su) environment is the opposite issue. There may be things inherited from the regular user's environment that you don't want in root's if you only did "su".
why take the risk and build software as root? because it has been done so 1993 and hasn't been charged since then?
and if /sbin and /usr/sbin are in your path, pkgtools are available and you can use su or su- or sudo , it doesn't matter, and this is a valid answer to the topic, see first post
not for building software, if there would be , than this is a problem in the software
why take the risk and build software as root? because it has been done so 1993 and hasn't been charged since then?
and if /sbin and /usr/sbin are in your path, pkgtools are available and you can use su or su- or sudo , it doesn't matter, and this is a valid answer to the topic, see first post
Yeah but ...
Why bother with /sbin/ and /usr/sbin/ if they're going to be added to every mere mortal user's PATH ?
If a regular user can execute /sbin/makepkg within a proper fakeroot environment, then maybe /sbin/makepkg should be moved to /bin/ ?
If a regular user can execute /sbin/makepkg within a proper fakeroot environment, then maybe /sbin/makepkg should be moved to /bin/ ?
No need for that. I always build packages using fakeroot (e.g. fakeroot sh something.SlackBuild). This just needs to call makepkg with its full path. Which is the case for all recent SlackBuilds provided by Slackware iirc, else just edit the SlackBuild and write /sbin/makepkg instead of makepkg.
And we still need to have all files in the package owned by root or specific system user, not a regular user.
Last edited by Didier Spaier; 05-21-2018 at 05:43 PM.
Reason: Ugly typos fixed?
I think you misinterpreted it a bit:
su will start a new shell which is owned by root (or owned by the user specified with -l <user>). It does not simulate anything, just start a new shell.
The difference between using and omitting - is: how the environment of the new shell will be set. Using - it will be reinitialized like a login shell, without - it will be just inherited from the parent process.
see man su:
Understood, thank you.
Slackware:
Code:
lysander@lyslackertest:~$ su
Password:
bash-4.3# exit
exit
lysander@lyslackertest:~$ su -
Password:
In the future, there will be fewer but better Russians.
-- Joseph Stalin
root@lyslackertest:~#
Debian:
Code:
lysander@psychopig-xxxiii:~$ su
Password:
root@psychopig-xxxiii:/home/lysander# exit
exit
lysander@psychopig-xxxiii:~$ su -
Password:
root@psychopig-xxxiii:~#
Hmm something is not right in Slack since I'm getting bash-4.3. Maybe I need to edit bash.rc.
EDIT: Amusing Stalin quote.
Last edited by Lysander666; 05-21-2018 at 03:51 PM.
And we still need to have all files in the package owned by root or specific system user, not a regular user.
Hmmm ...
I gotta get with the `fakeroot.sh somepackage.SlackBuild` program here
I am going to experiment with that a tad.
Thanks for the tip Didier Spaier !
-- kjh
P.S. Back to Lysander666's original Q:
YMMV
I was taught 'way back when' to always invoke `su -` unless there was a good reason not to ...
One occasional good reason not to for me is: I use a simple `su` instead of `su -` when I need to invoke chmod root:root <<FileOrDirectory>> on a file or directory in-or-relative-to my current working directory.
Invoking `su` gives me root privileges but leaves me 'where-ever I am at', directory-wise ...
Anyhow, I learned all this before there were `sudo` or `fakeroot` commands ... so ...
No need for that. I always build packages using fakeroot (e.g. fakeroot sh something.SlackBuild). This just needs to call makepkg with its full path. Which is the case for all recent SlackBuilds provided by Slackware iirc, else just edit the SlackBuild and write /sbin/makepkg instead of makepkg.
And we still need to have all files in the package owned by root or specific system user, not a regular user.
All my buildscrips run as a non-root user. I wrote a wrapper around makepkg (which gets run via sudo) that does some of the common stuff that every slackbuild does (compress manpages, info files, remove the .la (recent change), etc.) so that I don't have to include them in my build scripts themselves.
I can remember reading some stuff about fakeroot's use of LD_LIBRARY_PATH/LD_PRELOAD causing issues with configure runs for some software, so I never really liked the idea of using it. Once in a while I find a makefile that needs fixing to run as non-root, but most things just build straight out of the tarball. Obviously, Pat's stock slackbuilds and SBo scripts can't be used by non-root users without something like fakeroot.
P.S. As for installing packages. I usually ctrl-alt-f1, login and install from there.
Why bother with /sbin/ and /usr/sbin/ if they're going to be added to every mere mortal user's PATH ?
If a regular user can execute /sbin/makepkg within a proper fakeroot environment, then maybe /sbin/makepkg should be moved to /bin/ ?
Just wondering ...
-- kjh
fakeroot is, unfortunately, not part of Slackware and/or the Slackware philosophy, or whatever, there have been threads about this in the past.
however, if you have sudo rights, or you can su, than you a defacto admin, and not having everything in */sbin in you path is annoying anyway.
so extending you wheel group's users path is something that can be easy done, as installing fakeroot. without waiting for a change that will never come.
I was taught 'way back when' to always invoke `su -` unless there was a good reason not to ...
One occasional good reason not to for me is: I use a simple `su` instead of `su -` when I need to invoke chmod root:root <<FileOrDirectory>> on a file or directory in-or-relative-to my current working directory.
Invoking `su` gives me root privileges but leaves me 'where-ever I am at', directory-wise ...
I do the same thing. Occasionally as root I will issue a 'su chris' to do something as my self in the same directory.
I build my packages from su - or logged in as root. FYI you could also issue su - root, same result. To much extra typing
Last edited by chrisretusn; 05-22-2018 at 06:36 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.