Return to Answer

Similarly, I saw no problem with the use of $ over an (actual) root prompt. In Linux, a plain $ pretty much always means "this is a command meant to be run in a shell" while a # can mean a root shell, a comment, or a few other things that I'm too tired to remember at the moment. It's mostly just a stylistic choice, and one that everyone makes differently according to however they learned/are used to.

And regarding point 2:

That said, removing sudo from the OP's post does change the post's intent (something edits typically shouldn't do), and therefore should be discussed (at least briefly) in the comments section about whether sudo is (or isn't) necessary instead of leaving it up to the editors to know.

We can usually (safely) assume that anyone reading the answer will actually read it thoroughly. It's the same reason we don't use bold to emphasize things like Ubuntu 14.04. Therefore, the transition from regular-land to container-land is already well-defined.

This concept of "prompt compression" (so, turning user@host:~$ into $) is pretty common, as the additional information is almost always excessive. We don't need to know your username or hostname, we just need to know that we're typing this into a prompt somewhere.

Now, I am fully aware that lxc internally is root and will have a # prompt. This is where clarity becomes important -- # can mean a comment just as easily as it means a root shell. In this case, it really doesn't matter. You enter a container, you get a root shell automatically, no other actions required. And, as we've already entered the container, it doesn't matter much.

We can change it to # (although that may still cause some confusion whether it's a comment or not), but we shouldn't include the username/hostname, just for the sake of brevity. It's often a good writing practice to say what you need to say as clearly as possible, using as few words as possible.

Regarding point 2:

That said, removing sudo from the OP's post does change the post's intent (something edits typically shouldn't do), and therefore should be discussed (at least briefly) in the comments section about whether sudo is (or isn't) necessary instead of leaving it up to the editors to know. See Zanna's answer on editing code. Personally, I'd consider removing sudo to fall under the "simplification" category as opposed to an error correction.

I'm one of the people who rejected the review. Hello. Let me try to rationalize my decision based on the data I had at the time I clicked the button according to my own opinion.

Regarding point 1:

To me, it was clear what was and wasn't supposed to run in the container. The context of the commands (in the answer itself) shows that the first block of commands are meant to be run inside the container (emphasis mine):

Consider the following: I created a file /tmp/bar containing the line --foo. The following commands were run in the container:

$ ...

Similarly, I saw no problem with the use of $ over an (actual) root prompt. In Linux, a plain $ pretty much always means "this is a command meant to be run in a shell" while a # can mean a root shell, a comment, or a few other things that I'm too tired to remember at the moment. It's mostly just a stylistic choice, and one that everyone makes differently according to however they learned/are used to.

However, I do agree that the transition out of the container should be made more clear. I can edit that in, or let you do it. It doesn't really matter. Just some blurb somewhere saying that the grep command is meant to be run on the host machine.

And regarding point 2:

I checked the edit history of the post in question, and did not see muru add sudo. It was present in the original post.

However, even if it was not, it would have still been a sensible addition. Not every user automatically has permission to manage lxc (see here), and we can't make that assumption. It's safer to add sudo to the command and let someone take it out on execution if they feel is unnecessary.

Note that this advice goes against pretty much every security principle ever, but it's easier for usability to just add it instead of having to go through the entire explanation of root, and privilege escalation for sudo (why, when, how, etc.). Really, though, the decision for when to or when not to include sudo is really a judgement call based on what the command does and what the case for execution usually is.

I'm one of the people who rejected the review. Hello. Let me try to rationalize my decision based on the data I had at the time I clicked the button according to my own opinion.

And, for the sake of having everything in one thread, here is the suggested edit we are discussing.

Regarding point 1:

To me, it was clear what was and wasn't supposed to run in the container. The context of the commands (in the answer itself) shows that the first block of commands are meant to be run inside the container (emphasis mine):

Consider the following: I created a file /tmp/bar containing the line --foo. The following commands were run in the container:

$ ...

Similarly, I saw no problem with the use of $ over an (actual) root prompt. In Linux, a plain $ pretty much always means "this is a command meant to be run in a shell" while a # can mean a root shell, a comment, or a few other things that I'm too tired to remember at the moment. It's mostly just a stylistic choice, and one that everyone makes differently according to however they learned/are used to.

However, I do agree that the transition out of the container should be made more clear. I can edit that in, or let you do it. It doesn't really matter. Just some blurb somewhere saying that the grep command is meant to be run on the host machine.

And regarding point 2:

I checked the edit history of the post in question, and did not see muru add sudo. It was present in the original post.

However, even if it was not, it would have still been a sensible addition. Not every user automatically has permission to manage lxc (see here), and we can't make that assumption. It's safer to add sudo to the command and let someone take it out on execution if they feel is unnecessary.

Ok, I was wrong here. Turns out, I don't know how lxc and lxd usually work with permissions. Therefore, I (and I think most editors) will tend to defer to the OP's knowledge being correct unless they know otherwise. Actually doing the research into lxc and doing recon with this shows that your edit is technically accurate (and should have been approved, at least on that front). With that in mind, sorry. I screwed up here.

That said, removing sudo from the OP's post does change the post's intent (something edits typically shouldn't do), and therefore should be discussed (at least briefly) in the comments section about whether sudo is (or isn't) necessary instead of leaving it up to the editors to know.

I'm one of the people who rejected the review. Hello. Let me try to rationalize my decision based on the data I had at the time I clicked the button according to my own opinion.

Regarding point 1:

To me, it was clear what was and wasn't supposed to run in the container. The context of the commands (in the answer itself) shows that the first block of commands are meant to be run inside the container (emphasis mine):

Consider the following: I created a file /tmp/bar containing the line --foo. The following commands were run in the container:

$ ...

However, I do agree that the transition out of the container should be made more clear. I can edit that in, or let you do it. It doesn't really matter. Just some blurb somewhere saying that the grep command is meant to be run on the host machine.

And regarding point 2:

I checked the edit history of the post in question, and did not see muru add sudo. It was present in the original post.

However, even if it was not, it would have still been a sensible addition. Not every user automatically has permission to manage lxc (see here), and we can't make that assumption. It's safer to add sudo to the command and let someone take it out on execution if they feel is unnecessary.

Note that this advice goes against pretty much every security principle ever, but it's easier for usability to just add it instead of having to go through the entire explanation of root, and privilege escalation for sudo (why, when, how, etc.). Really, though, the decision for when to or when not to include sudo is really a judgement call based on what the command does and what the case for execution usually is.

I'm one of the people who rejected the review. Hello. Let me try to rationalize my decision based on the data I had at the time I clicked the button according to my own opinion.

Regarding point 1:

To me, it was clear what was and wasn't supposed to run in the container. The context of the commands (in the answer itself) shows that the first block of commands are meant to be run inside the container (emphasis mine):

Consider the following: I created a file /tmp/bar containing the line --foo. The following commands were run in the container:

$ ...

Similarly, I saw no problem with the use of $ over an (actual) root prompt. In Linux, a plain $ pretty much always means "this is a command meant to be run in a shell" while a # can mean a root shell, a comment, or a few other things that I'm too tired to remember at the moment. It's mostly just a stylistic choice, and one that everyone makes differently according to however they learned/are used to.

However, I do agree that the transition out of the container should be made more clear. I can edit that in, or let you do it. It doesn't really matter. Just some blurb somewhere saying that the grep command is meant to be run on the host machine.

And regarding point 2:

I checked the edit history of the post in question, and did not see muru add sudo. It was present in the original post.

However, even if it was not, it would have still been a sensible addition. Not every user automatically has permission to manage lxc (see here), and we can't make that assumption. It's safer to add sudo to the command and let someone take it out on execution if they feel is unnecessary.

Note that this advice goes against pretty much every security principle ever, but it's easier for usability to just add it instead of having to go through the entire explanation of root, and privilege escalation for sudo (why, when, how, etc.). Really, though, the decision for when to or when not to include sudo is really a judgement call based on what the command does and what the case for execution usually is.