34

I noticed a minor 'edit war' in an answer (NB: broken link, I'm guessing the answer was deleted) regarding whether or not we should promote $ at the front of command line instructions.

Is one of these preffered over the other? Or should it be left to the original author's discretion?

  1. sudo apt-get dist-upgrade
  2. $ sudo apt-get dist-upgrade
  3. # apt-get dist-upgrade

(I'd imagine we generally discourage #3)

  • 1
    the link in your question is broken. – koushik Oct 4 '10 at 8:21
  • @koushik Thank you, I think the answer/'post' must have been deleted. – 8128 Oct 4 '10 at 17:39
  • 5
    As a bit of a trick, you can write an executable script called $ with the contents $@ then place it in $PATH to execute commands even when they have $ in front of them. – kiri Oct 16 '13 at 9:29
34

I agree with the tenet "keep text copy+pasteable", but I think there are cases where a $ or # can be actually justified for readability reasons.

I like to put $ or # in front of commands when I have a block of text that mentions a command / series of commands together with its intended output. Example:


If you remove the "r" permission from a directory, you will not be able to list its contents:

$ chmod -r /tmp/test.d
$ ls /tmp/test.d
ls: Permission denied

In this case, the $ marks the commands that a user would enter at the terminal prompt (I would have used # for root terminal), and the un-prefixed lines are the command output.

I agree this can be formatted in a different way to keep it copy+pasteable, but I find this formatting more natural as it mirrors what would actually be seen on the terminal screen.

  • 1
    I use the "Kernighan book" session style also, but will refrain from doing so when there is no interesting interaction to show. – msw Oct 10 '10 at 3:23
  • 1
    zsh allows alias '$'='' - no problem with prefixed $ at all ;) – Volker Siegel Sep 11 '14 at 4:22
19

Wasn't an edit war. Dana clicked edit before I edited, then clicked save after I had. My change was lost. It happens sometimes ;)

But on topic, I think it makes most sense to have something that is copy-paste-able. When you start munging dollars and hashes onto the front of lines, you break that.

There is scope for confusion (if you have multiple commands and then an example of some text you'd like the user to add to a file) but if that's possible, you just make sure you explain what each code block is with some text between the blocks.

16

In with what Oli said:

When something is looking like this it's generally meant to be code in SO - this isn't SO though, it's Ubuntu and has been come to be recognized as command line (Especially in context with the question) So there's no need to place identifiers like $ or (even worse) #. Here are a few examples of ways to effectively use code syntax.

Q: How do I install the marcoceppi-rules application?


You will first need to add the marcoceppi-rules PPA to your system:

sudo add-apt-repository ppa:marcoceppi-rules/ppa
sudo apt-get update

Once that has been added you will need to install marcoceppi-rules from either Applications -> Ubuntu Software Center or via command line:

sudo apt-get install marcoceppi-rules

First you will need to add the marcoceppi-rules PPA then run apt-get:

sudo add-apt-repository ppa:marcoceppi-rules/ppa
sudo apt-get update
sudo apt-get install marcoceppi-rules

There are many ways to word this most all answers I've seen demonstrate a basic workflow and don't just arbitrarily respond with a "code" block. However the format of the answer and what the code block means will be largely dictated by the context of the question.

6

I differentiate between "Type these commands to do the task" (which should be copy/paste-able), and "Here is what my answer produces on MY system (YMMV)", where the $ and # are used to show context.

A recent example is my answer to this question

-2

Since they are specific command lines, I prefix the commandline with the actual default linux prompt. I use the $(dollar sign) to prompt Ubuntu's encouragement logging in as a normal user for and using the sudo elevated for systemwide or other specific intentions.

When I first started using Unix/Linux, I always logged in as Root to save time. For years there was confusion on my various machines of my files and space and the systemwide files and space. I had to log in as root just to access many of my personal files.

When I eventually moved to Ubuntu, I started using many defaults and following the convention. So the prompt I almost always have is the $(dollar sign) prompt.

There are some commands and work that can be done without sudo, then there is the commands to make the changes system wide. Without specifying the commandline is at the normal user's prompt, there can be some confusion as to why the sudo command when many people are already at an elevated level after having issues a sudo su - command. If I had a reason to do that in one of my answers, I would change the prompt to the # symbol... so far I haven't had a reason to do that.

Then, it's not like I'm giving a script to copy and paste. It's one command line at a time (when I use the $ symbol). So I expect for the user to select the text following the dollar sign, copy and paste it one line at a time.

There are occasions where there might be many commands of which I would make a convenient script and not use the $ symbol.

Script to copy and paste

On occasions I might give a script to copy and paste. I consider that different. If there are lots of lines indented to be executed exactly, I'll use the bash scripting language facility to put the lines one by one. I'll also include a description of what the lines are intended to do in case the user might one to customize it in a text editor before saving it to execute the lines.

While there there is a little learning curb when it comes to the terminal commandline. I wouldn't consider the small element of a user recognizing pasting the prompt as part of the commandline will give an error a bigger inconvenience over the visual provision of actually seeing the prompt with the provided answer. At a glance (in no time) the user will recognize this is a terminal command. Outside of having the $ prompt, at a glance it might be an entry to add to a file and not a command.

I still make that mistake from time to time. I see a couple of text lines to fix a problem, and try to execute them, but find they are lines to append to a configuration file.

On the few occasions where the $ prompt has been edited from my answers, it appears to take away clarity.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .