3 ms·

Ah yes, the instructions should say "Run this in your console (Do not paste into file)" or similar. I really appreciate the quick test to show whether this pro

Ah yes, the instructions should say "Run this in your console (Do not paste into file)" or similar. I really appreciate the quick test to show whether this problem exists for you.

jandrese 5y ago
In the old days it was common in documentation to prefix anything you were going to run with the prompt, just to make it obvious that it is a shell command. Like so: % echo 'stuff' >> ~/.zprofile If something had to be run as root the prefix was # instead, just like in Bourne Shell. Of course this makes it more difficult to copy and paste, you have to do each line one at a time.
- dylan604 5y ago
  this is actually something i never thought about. if you did copy the lines to be run as root with the preceding #, would it be interpreted as a comment and ignored? some sort of built-in safety from running blindly copied commands?
  - bewuethr 5y ago
    I once read that's the reason why the root prompt is #.
    - a1369209993 5y ago
      I can't speak for whoever came up with it originally, but that is the reason I retained that behaviour in my own shell, and it certainly sounds plausible.
  - irjustin 5y ago
    If nothing else, it would simply error.
- ddalcino 5y ago
  I’ve been involved with two different open source projects where, within the last couple of months, users have opened issues complaining about the shell prompts in the documentation, or PRs removing them, because it makes it too hard to copy-paste commands. The PRs were accepted over my objections. I was taught that you NEVER copy paste anything from the internet into a terminal. You learn what the commands do, and you type them yourself. Am I just old?
  - actually_a_dog 5y ago
    No, you were taught the right thing. You never know what some random JavaScript is gonna do to the contents of your clipboard when copying from a web page. Best practice, IMO, is to open as dumb an editor as you can find and pasting the commands into an editor buffer for inspection before running anything in the shell. And, if you don’t understand what it’s ask you to paste into your shell, don’t do it. Even if you run with JavaScript off entirely, this at least makes you think before you do anything potentially destructive.
  - pope_meat 5y ago
    What we're supposed to do, and what actually happens are different things. Especially in a situation where you're trying to install something just to get some other thing to work.
  - MattGaiser 5y ago
    In theory, yes you are right. In practice, I have deadlines and people wanting things and I often need to get things I don't understand up and running pretty quickly.
  - irjustin 5y ago
    Goals of focus and trust to gain speed. The sentiment makes sense locally, but at some point you either need to trust the thing you're working with or you do it yourself. There's not enough time in a day to "learn the commands yourself" for everything you do, but if you personally choose to learn and type the commands yourself, great! It's also okay to trust others with what you're doing. If you run brew, you literally are trusting other's install scripts not to do something malicious. (Seems ironic to run the brew command, but not trust the copy/paste it tells you to do?) Even if you don't run brew and install/compile the software yourself, you haven't read every line of code that the software is running to know if that's truly safe. It's not ideal, but you need to trust at some level or you're never going to move forward.

Ah yes, the instructions should say "Run this in your console (Do not paste into file)" or similar. I really appreciate the quick test to show whether this problem exists for you.

jandrese 5y ago

In the old days it was common in documentation to prefix anything you were going to run with the prompt, just to make it obvious that it is a shell command. Like so: % echo 'stuff' >> ~/.zprofile If something had to be run as root the prefix was # instead, just like in Bourne Shell. Of course this makes it more difficult to copy and paste, you have to do each line one at a time.

dylan604 5y ago
this is actually something i never thought about. if you did copy the lines to be run as root with the preceding #, would it be interpreted as a comment and ignored? some sort of built-in safety from running blindly copied commands?
- bewuethr 5y ago
  I once read that's the reason why the root prompt is #.
  - a1369209993 5y ago
    I can't speak for whoever came up with it originally, but that is the reason I retained that behaviour in my own shell, and it certainly sounds plausible.
- irjustin 5y ago
  If nothing else, it would simply error.
ddalcino 5y ago
I’ve been involved with two different open source projects where, within the last couple of months, users have opened issues complaining about the shell prompts in the documentation, or PRs removing them, because it makes it too hard to copy-paste commands. The PRs were accepted over my objections. I was taught that you NEVER copy paste anything from the internet into a terminal. You learn what the commands do, and you type them yourself. Am I just old?
- actually_a_dog 5y ago
  No, you were taught the right thing. You never know what some random JavaScript is gonna do to the contents of your clipboard when copying from a web page. Best practice, IMO, is to open as dumb an editor as you can find and pasting the commands into an editor buffer for inspection before running anything in the shell. And, if you don’t understand what it’s ask you to paste into your shell, don’t do it. Even if you run with JavaScript off entirely, this at least makes you think before you do anything potentially destructive.
- pope_meat 5y ago
  What we're supposed to do, and what actually happens are different things. Especially in a situation where you're trying to install something just to get some other thing to work.
- MattGaiser 5y ago
  In theory, yes you are right. In practice, I have deadlines and people wanting things and I often need to get things I don't understand up and running pretty quickly.
- irjustin 5y ago
  Goals of focus and trust to gain speed. The sentiment makes sense locally, but at some point you either need to trust the thing you're working with or you do it yourself. There's not enough time in a day to "learn the commands yourself" for everything you do, but if you personally choose to learn and type the commands yourself, great! It's also okay to trust others with what you're doing. If you run brew, you literally are trusting other's install scripts not to do something malicious. (Seems ironic to run the brew command, but not trust the copy/paste it tells you to do?) Even if you don't run brew and install/compile the software yourself, you haven't read every line of code that the software is running to know if that's truly safe. It's not ideal, but you need to trust at some level or you're never going to move forward.