Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
The program itself isn't letting you do anything useful as an unprivileged user. The purpose of the setuid bit is to deal with exactly this kind of situation. Try `chmod +s /sbin/shutdown`.
It's unrelated, but I just want to check this - when you're in /sbin, does `shutdown` run shutdown, or is it `./shutdown`? If the latter, no problem; if the former, could you `echo $PATH` and post it here?
ok thanks a lot.. setting the user id worked... although i had to make links to reboot, halt, and shutdown on my home directory for them to work (if not I have to navigate into /sbin before running command, not sure if home was the best place to put links in)
just "shutdown" will run shutdown when in /sbin fine. Here is the path
Okay, path stuff - when you run a program 'foo' by giving only its name, your shell searches each directory in the $PATH variable for an executable file named 'foo' and runs the first one it gets. If it makes it to the end and hasn't found anything, you get a 'command not found' error. (If you try to run ./shutdown, or /sbin/shutdown, you've given the shell the full path to the program you want to run and so no searching is required.) The reason why you are able to run shutdown without ./ when in /sbin is that . (which always means the current directory) is last in your $PATH variable. I have never used Slackware, so I don't know if that's something they do, but I can tell you that it's very unusual. If it's a default, don't worry about it, but . is not in most people's paths.
So, delete those symlinks, and add this line to .bashrc in your homedir to add /sbin to the front of your $PATH:
This will not take effect until you run `source ~/.bashrc`, but will be in effect for all future shells. It should make it so you can call shutdown from any directory in the future. Note that it is important that /sbin is at the front, especially if . is in your path. Imagine if you somehow ended up with a shell script named shutdown somewhere and wanted to kill your machine - you'd be, at best, unpleasantly surprised if instead you got that script.
(thank God I pasted my path in the forum... this is where I got the line from)
Anyway, now that the PATH is fixed... I'm still getting "shutdown: you must be root to do that!" when I type shutdown (from any directory now)
I added the suggested line to sudoers (really just uncommented, it was already there as an example)
The problem might be ~/.bashrc, it wasn't there!
I created the file and "alias shutdown='sudo /sbin/shutdown -h now'" is THE only line in the file...
Please help!.. not sure what exactly went wrong
btw, I really appreciate the input from both of you, and the explanation of PATH... nice and clear.
No worries about the $PATH business - values like that (called environment variables) are reset with each new shell, and the reason why we're telling you to put modifications to them in your .bashrc is that every line in that file is run every time you run bash (i.e., every new login shell), which makes the setting essentially permanent. However, I do suggest you put /sbin at the front, not the end, for the reasons in my last post. It's a small security hole, but there's no reason to create it when the difference is just the order of some characters. : )
Now, it's entirely possible you didn't already have a .bashrc - I don't think one is created by default. You might have a .profile or something - there's a couple other files that are used in only subtly different ways. Similar to the $PATH-modifying line, adding the alias line to .bashrc isn't enough - when you `source .bashrc`, it should register with the shell that from then on, `shutdown` will be transformed into `sudo shutdown -h now`. Is that not working?
Edit: Just read that. Good to hear - good luck in the future.
you're right.. I rebooted and now its no longer in my $PATH
I went ahead and added 'PATH="/sbin:$PATH"' to my .bashrc (thanks for explaining why sbin should go before) and ran source .bashrc
but still when I reboot it's not being added to the $PATH
I still have to cd /sbin before run reboot or halt
Okay, did some quick Googling and it seems that bash may not actually source .bashrc in all cases, which would be my bad. Try copying .bashrc to .profile and see if that fixes it.
By the way - to save yourself some trouble, when testing stuff like this, you don't need to reboot every time. Just exit your terminal emulator and start a new one, or even just run bash from within bash (exit will then kill the second bash and drop you back to the first). The second one will check the files anew and will reflect changes you've made since you ran the first one.
Edit: Sorry for fumbling. I should know this, but I don't use bash - if you ever find you wish your shell were better, look into zsh. : )
And the "normal" way to go about .bashrc and something that
gets pulled on login is to have a ~/.bash_login or ~/.bash_profile
that sources ~/.bashrc if it exists ...
if [ -f ~/.bashrc ]; then
No duplication of files, no copying when you edit one of them
to make the other the same.
As for z - it's nice, it's strong, it's powerful.
Don't rely on it being installed everywhere you're
ever gonna use a unix-/linux type computer. bash
today is ubiquitous (even though AIX or Solaris
hardliners will tell you the same thing I just said
about z about bash ;}). Learn the smallest common
denominator, learn it well. Don't rely on advanced
features of certain products too much - they may
not be there on a different machine, and then it's
normally not a good time to start learning "old skool".
allright, so I did 'vi .bash_profile' and added the line
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
then did rm .profile, closed and reopened my terminal, and echo $PATH still contains /sbin at the beginning
I know ~/.bash_profile, ~/.bash_login, ~/.profile, and ~/.bashrc are all startup files; but other than the order they are run in I don't know what they are really there for. I guess what I'm asking is, what is the difference between adding my startup commands in ~/.bashrc and using that line in ~./bash_profile to run them, and just putting the commands straight into ~/.bash_profile (or ~/.bash_login!)?
bashrc will be valid for *any* shell you invoke, *profile and *login
will only be pulled for login-shells. What constitutes a login-shell
may depend on your DE/WM and how it invokes terminal emulators.