5

I am aware of the editing help topic, but I'm still not sure how I am supposed to format the text I copy/pasted from my terminal.

I want to be able to share these details from my terminal and I want to make sure that the information is not lost in translation.

How can I include a paste from my terminal in a way that preserves the original line breaks and monospace formatting?

2 Answers 2

7

Please use code fences. Here's how to do it:

  • Copy/Paste directly from your terminal into the editing box on Ask Ubuntu.
    Do not make any alterations to the text you just pasted.

  • Add a new line before your paste with three backticks ( ``` )

  • Add another new line after your paste with three backticks. ( ``` )

The contents between two lines with three backticks will keep their original line breaks and monospace formatting.

✅ Here's what this should look like in the editing box:

```
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
```

✅ This is how the same text will appear in questions and answers:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


Please Don't...

Please go back and edit your question or answer if the paste from your terminal looks like any of the following. These bad examples either add unwanted ambiguity to your details, or they are difficult to parse, or difficult for us to work with. Posting details in these ways can make it more difficult to understand your details well enough to help you get a relevant answer:

No formatting at all:

Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


Contents of the paste have been manipulated:

Reading package lists... Done - 
Building dependency tree... Done - (Can someone explain this line to me?)
    Reading state information... Done
> Calculating upgrade... Done
Everything seems okay here.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Using block quotes:

Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

A screenshot of your terminal or photograph of your screen:

screenshot of a terminal

5
  • 2
    In the case of block quoted text, the line breaks may be unrecoverable and it may be necessary to fetch the output again :(
    – Zanna Mod
    Nov 9 at 2:38
  • 3
    I would like to note that one might wish to include a screenshot of the terminal if it shows something significant that pasting text will not show, for example ls colours (which indicate permissions), or other formatting, that relates to the subject of the post.
    – Zanna Mod
    Nov 9 at 2:43
  • I'd like to add to what @Zanna said with the note that screenshots should only be used when the appearance of something is the problem (e.g., the colours due to permissions, but not the permissions themselves; or the effect of output of some special control charcater, etc.)
    – muru
    Nov 9 at 11:58
  • By the way, you can also format a code block by adding four spaces before every line. I prefer the backticks. But the four spaces are the default behaviour of the editor when clicking the {} icon or the relevant keyboard shortcut (Ctrl/Cmd + K) on a multiline code block.
    – Dan
    Nov 9 at 12:51
  • @Dan Yes you can achieve the same end result by adding 4 spaces to each line, but in my view, that method is inferior because it changes the raw content of the paste itself.
    – Nmath
    Nov 9 at 18:52
0

Agree with @Nmath's recommendations overall (wouldn't mind seeing a Community Wiki question and answer for this), but I'd add that there are some situations where Block Quotes + Inline Code improves readability.

  • ❌ Using code-block (triple-backticks) or inline code (single-backticks): Difficult to read. Critical information can be difficult to find while manually sliding the horizontal scrollbar:

    A really long error message or output that is easily readable on your screen due to the terminal automatically wrapping. It includes important information throughout the output.  It may even include multiple sentences since some output just assumes it will line-wrap, and  forgoes any line-breaks.  These can sometimes be hundreds of characters long and therefore very difficult to read with a scrollbar in a pure code-fence.
    

  • ❌ Using a block-quote: Semantically correct (you are, after all, quoting the error message), but doesn't fully provide the "visual indicator" that this is output:

    A really long error message or output that is easily readable on your screen due to the terminal automatically wrapping. It includes important information throughout the output. It may even include multiple sentences since some output just assumes it will line-wrap, and forgoes any line-breaks. These can sometimes be hundreds of characters long and therefore very difficult to read with a scrollbar in a pure code-fence.


  • ✅ Using a block-quote + inline (single backtick): Best compromise between being semantically correct, readable, and providing proper visual queues

    A really long error message or output that is easily readable on your screen due to the terminal automatically wrapping. It includes important information throughout the output. It may even include multiple sentences since some output just assumes it will line-wrap, and forgoes any line-breaks. These can sometimes be hundreds of characters long and therefore very difficult to read with a scrollbar in a pure code-fence.

8
  • 3
    Hmmm... Your last example does not use code fences (triple backticks) but inline code formatting (single backticks). And I'm not sure I agree with this usage. I would very much prefer manual line breaks of a long error output inside code fences. The method you propose (blockquote+single backticks) would only work for a single line error. If the error spans multiple lines, these get lost. Even worse, if the error has empty lines, the code formatting completely breaks and only the quote formatting gets applied. Nov 10 at 18:55
  • @BeastOfCaerbannog "Would only work for a single error line. If the error spans multiple lines, these get lost." - Yes, as I said, this is only for long single-line output. If the output has line-breaks already, then it shouldn't be needed. Nov 10 at 21:19
  • Regarding, "I would very much prefer manual line breaks of a long error output inside code fences." -- Sure, an alternative is to manually add line-breaks in a code-block, but that violates Nmath's rule to "not make any alterations to the text you just pasted." And I agree with that. It's better to paste the output exactly as it has been generated to avoid inserting any errors, but then it may be unreadable with standard code-blocks or inline. Nov 10 at 21:23
  • Also, edited to disambiguate the "code-fences". Nov 10 at 21:24
  • It is not very often that you get a single-line error output and you didn't explicitly mentioned that your suggestion is for this case only, thus my comment. Usually error outputs span multiple lines. In a case of a long single-line error, I would leave the error output exactly as presented, without violating Nmath's rule. If I would decide to have it in multiple lines though, I would break it manually (also adding a note in the post), instead of using the method you describe in your third example. That's a matter of personal preference I guess, that's why I haven't voted your post. Nov 10 at 21:34
  • @BeastOfCaerbannog "It is not very often that you get a single-line error output" -- I have to disagree. I've seen it quite frequently across the Stack sites I frequent, which is why I've arrived at this method. Perhaps more so on Stack Overflow, where it seems to be commonly agreed that block-quotes without backticks is the best method. But do agree that it's a clearly matter of personal preference. Nov 10 at 21:42
  • 2
    More users would probably have caught the error in this post, if the first quote was done in the way you suggested. I spotted it anyway, but I guess most people didn't (including the one that voted to close). 😉 Nov 11 at 16:56
  • 1
    @ArturMeinild Exactly! And good plan pointing out the multi-line approach for entering long commands like that as well in your answer. Nov 11 at 17:05

You must log in to answer this question.

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