Launchpad needs a way of highlighting requested terminal input in comments.

[Patrick Kilgore]

Currently, it is very difficult for a triager to differentiate the commands they want a user to enter the terminal from their comments.

This has resulted in a variety of different methodologies, from quotes, to "$" signs, to new lines depending on the person triaging the report. The end result is that is is difficult for a new user to figure out what, exactly, we want them to do. It would be nice if there could be a psudo-wiki/forum-style syntax within which a bug triager or developer could put terminal commands into that would visually differentiate them from the rest of the comment in launchpad itself. It would have to be simple enough that it wouldn't look completely stupid or confusing in an email as well.

My suggestion, which is quite obviously up for discussion and modification, is this:

Have every new line starting with a unique character set be a terminal input. The line is indented and the background is changed to a lighter gray when viewed in lauchpad. It would have to be both simple, unique, and not likely to be confused as something other than a terminal input when viewed in an email. My suggestion would "|$" since "$" is the last character in the ubuntu terminal prompt, with the "|" character added to make it unique from the (probably rare) times when someone wants to start a line with the dollar sign and is actually talking about money. The downside is see to this is the increased server overhead from parsing this command out and translating it into relevant css/(x)html.

And example comment by a triager would then look like this:

>Hello and thanks for taking the time to submit this bug and help make Ubuntu better.
>Can you please attach the output of
>|$ uname -a
>in a comment to this bug report? Thanks in advance!

This is pretty distinctive in emails, without adding any more clutter than usual. I also believe that new bug submitters will be more comfortable with following up a bug report with "scary" terminal commands if they know exactly what they are doing and that is conveyed to them in a clear visual fashion. The [code] tags helped me immensely as a beginner in the forums, and I think they would have the same effect here.

Thanks as always for listening/feedback.

Page Independent

[Eleanor Berger (intellectronica)]

Once again, the solution is to provide some kind of general markup system that's usable across LP.

[Patrick Kilgore (patrick-kilgore)]

I'm always open for discussion, but the intention of this bug report is far different than supporting mono space fonts (Which launchpad already does???).

I'm am specifically interested in a stylistic, visual differentiation of terminal commands with other text in a bug response. Heck one of the actual problems is that ALL text in current responses is monospace. It is visually very difficult to notice terminal commands or code embedded in blocks of commentary and other instructions.

I'm going to remove the duplicate - please explain why you think the bugs should be merged before re-duping it.

Thanks,
Patrick

[Patrick Kilgore (patrick-kilgore)]

Again, the basis of this bug is to distinguish terminal INPUT, from all other text, including commentary and terminal OUTPUT.

Bug #127755 is about confusing or poorly formatted terminal OUTPUT (which seems to me can be solved w/ attachments...)

I find that the larger issue is encouraging that majority of users who are not familiar (or comfortable) with using the terminal to assist us in debugging. We can do this by providing a clear indication of when/what we would like them to type into the terminal.

This could be accomplished with either a general markup system as suggested by Tom, or a very specific one for this purpose. Perhaps even one that limits this ability to bugsquad or bugcontrol.

Either way, I believe the suggested duplicate does not represent, in a specific or general way, the intent of this bug report.

Thanks,
Patrick

[Curtis Hovey (sinzui)]

We do want to support input and output. We certainly do not want to build half a solution.