The worst is when you expect a password prompt so you type the password and hit enter, but you mistyped the original command and you end up typing your password in plaintext onto the command line. oops.

If you're using `bash`, A quick remedy for this is:

  unset HISTFILE
  exit

This prevents `bash` from updating the `~/.bash_history` file on exit with the command you don't want memorialized. (assuming you don't also have some hook that updates your history file after every command)

I understand what you're saying but if anybody on your machine can read the commands, can't they also read your configuration files? Or are you saying a different user on the machine can run `ps` and see my processes but not necessarily my portion of the file system? My thought is if the file is not encrypted on the disk, then any desktop application can read it. So, while I agree that preventing a user from reading bash history is not worth it if they can read your processes, aren't configuration files (if unencrypted) just as insecure?

In a Unix system, files have 3 levels of permissions — for the user who owns the file, the group-of-users that owns the file, and any system user.

So, a given config file can have permissions so that the file owner can read and write, but other users cannot. Like your ssh keys.

But ‘ps’ can be run by anyone, and it can typically access the whole command line you used.

Ah, right. This makes a lot of sense. Thank you!

This is true but in a typical desktop usecase there is one user.

This doesn't have to be true. You can mount /proc with hidepid to prevent users from seeing other users' processes: https://access.redhat.com/documentation/en-us/red_hat_enterp...

Indeed! One thing that at least works on zsh is to prefix the command with a space, then the command doesn't go into the history file.

So if you do `date`, it'll end up in the history file but if you do ` date` (one space prefixed), it won't. One `clear` later and it's like the command was never run.

> Anybody on your machine can read the commands you are running, for example with ps.

This is why I always mount /proc with the "hidepid=2" option (as well as the "gid=<n>" option to ensure that doesn't apply to the members of a specific group, such as the "admins" of the box).

Not a real solution, but you can assign new values to argv/argc to hide things from ps.

With Perl, for example, assign to $0.

$0="what /bin/ps will see";

How exactly?

I think what OP meant was closer to "if it could have been entered into the bash history than there's other ways it could be seen".

Most CLI programs that need sensetive information as input should either do it interactively (a la sudo), as standard input, or configuration file. If worst comes to very worst, you can put the sensitive info in a text file and use backticks. For example:

  some-command --username=jedimastert --password=`cat secret.txt`

> some-command --username=jedimastert --password=`cat secret.txt`

This will not work in the way that you suggest. The output of ps will show the result of `cat secret.txt` and thus reveal the password.

Would it? Poo. That's my bad.

How would backticks help with hiding it from ps?

I thought that's how it would show up in ps. Apparently I was incorrect. :(