Should we have a convention for commands requiring root?

Question

Often a question can only be answered with a command that must be run as root. Depending on your distribution of choice you might be used to doing this with sudo. However, it is probably undesirable to post the command with sudo attached since someone who is looking for a quick fix might just run the command (which might not be what they need to run) without actually looking at the command and what it does. Additionally, sudo isn't necessarily used on the user's system. Should we have a conventional way for denoting when something needs to be run as root?

Here are some possible conventions:

• Place a # before the command, denoting the common character used at the root prompt. The problem with this is that many who are new to unix might not recognize this.
• Placeing something like "(as root):" before the command. The problem with this (and the above option) is that the user may not know how to run something as root.

Any ideas?

Answer 1

I think we should have a convention for this and that we should try to implement both of your suggestions.

The first one being there for purely conventional reasons and for the regulars... However, using '#' might not be most suitable because it could also indicate a commented line in a bash piece of code.

The second one for new people, accompanied with a link (run this as root) to a google search or another question that addresses running stuff as root.

update: I created a question that you can link to for this purpose.

Answer 2

I'm not sure if there really is a need for a convention like this.

If root privileges are required, in most of the cases you will get an appropriate error message. Its often also clear from the context of the command/question. Even if you stuck sometime with a "command not found" error because /sbin isn't in your path, its likely that you won't repeat that fault.

However, it is probably undesirable to post the command with sudo attached since someone who is looking for a quick fix might just run the command (which might not be what they need to run) without actually looking at the command and what it does.

Nobody should never ever run any commands without having a clue what they are doing, especially if they are prefixed with sudo. If this happens and somebody breaks his system he learned a important lesson.

sudo and root are the essential basic concept of linux/unix and I don't see the point to support someone who didn't do his homework about that.

If we decide we need a convention, I really like the first one (append a # to the shell).

Answer 3

I'm definitely not a fan of including sudo, I think it gets people in the habit of using it without knowing what it is, and it's not part of the command -- if you need to run X as root, the command is X; sudo X is just one way to run it as root. I would prefer using # to explicitly saying as root (I probably should've used # instead of $ on this question), but you're right that some people might not realize what it means, so I suppose something like this will work:

To solve your problem, run the following as root:

# ./do-stuff-as-root

Answer 4

This answer exists to list suggested improvements to the canonical answer to “How do I run a command as root”. Please add todo items here and remove them when done. Discuss the current contents and planned changes in the comments here or on the unix.se chat.

• sudo

  • Older versions of sudo didn't have -e or -i.

• su

  • Are there OS-dependent su options worth mentioning?
  • What variants use the wheel group?

• other programs

  • calife: give a usage example; website link; where is it found?
  • op: give a usage example; website link; where is it found?
  • super: give a usage example; website link; where is it found?
  • kstuss: give a usage example; is it in fact a wrapper around su?
  • beesu: give a usage example; website link

• Running X programs

  • There are frontends like gksu and gksudo that do everything automatically, but they're not available everywhere. Discuss the general case (there might already be something on unix.se or superuser).

• Editing files

  • briefly discuss vipw and friends on various OSes (e.g. mention OSes where the password database is generated by vipw and won't be updated if you just edit /etc/passwd)

• single user mode

  • Should we include a section on single user mode? How detailed should it be with regards to how to edit your kernel parameters via grub?