On more handy set of emacs-derived keystrokes: Ctrl-a ctrl-k to clear the current command, or redo a hidden password prompt if you know you fat-fingered it. ctrl-a jumps the cursor to the beginning of the line, and ctrl-k deletes from current position to the end of the line. The mnemonic to remember these: "a" is the first position in the alphabet, and jumps you to the first position. "K" is short for "kill.”
Shell Productivity Tips and Tricks
51–60 of 97 posts
Re: Shell Productivity Tips and Tricks
#52Best shell productivity trick ever: don't use the shell for anything more complicated than launching executables and use a reasonably modern programming language to achieve all other tasks.
Re: Shell Productivity Tips and Tricks
#53Earlier quoted context omitted.
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=jedimast…
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.
Re: Shell Productivity Tips and Tricks
#54> If you want to remove a sensitive command from your history, you can simply edit your $HISTFILE history file and remove it. It’s already too late at this point. Anybody on your machine can read the commands you are running, for example with ps. You should instinctively avoid entering anything in plaintext into a terminal which you don’t want other people to see. Any command line tool worth its salt will provide alt…
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…
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.
Re: Shell Productivity Tips and Tricks
#55Best shell productivity trick ever: don't use the shell for anything more complicated than launching executables and use a reasonably modern programming language to achieve all other tasks.
What is a reasonably modern language? Everything seems to be at least 20 years old now.
But there's the truth in there that even programming languages that are 20 years old had a completely different mindset applied to their design process than the original Unix shell which was much more ad-hoc.
40 years ago IT was a completey different environment than 20 years ago.
Re: Shell Productivity Tips and Tricks
#56fzf fizzy history search with ctrl-r is my favorite new shell trick. Fzf is a wonderful program
Re: Shell Productivity Tips and Tricks
#57Best shell productivity trick ever: don't use the shell for anything more complicated than launching executables and use a reasonably modern programming language to achieve all other tasks.
'rename .txt _1.txt *' is quite a few lines in a language that's super simple, like Python, and it turns into code golf with even more terse languages.
I'll stick to the terminal.
Re: Shell Productivity Tips and Tricks
#58Best shell productivity trick ever: don't use the shell for anything more complicated than launching executables and use a reasonably modern programming language to achieve all other tasks.
Perl is maybe the closest here, but it certainly has it's fair share of annoyances, and I more or less dropped perl for python decades ago and don't particularly feel like going back.
Re: Shell Productivity Tips and Tricks
#59> If you want to remove a sensitive command from your history, you can simply edit your $HISTFILE history file and remove it. It’s already too late at this point. Anybody on your machine can read the commands you are running, for example with ps. You should instinctively avoid entering anything in plaintext into a terminal which you don’t want other people to see. Any command line tool worth its salt will provide alt…
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.
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)Re: Shell Productivity Tips and Tricks
#60Earlier quoted context omitted.
Note that CDPATH can break shell scripts that assume `cd` hasn't been adulterated. A huge block of "unalias" calls at the beginning of shell scripts used to be a common practice, but they don't seem to be found in more widely-used tools these days.
Except with CDPATH the `cd` is usually not an alias. Even `/usr/bin/cd` is aware of CDPATH. It's a bug in the script, just like reacting badly to $IFS or $LANG.
EDIT:
$ cat /usr/bin/cd
#!/usr/bin/sh
builtin cd "$@"