Live data from Hacker News

Shell Productivity Tips and Tricks

blog.balthazar-rouberol.com

51–60 of 97 posts

Re: Shell Productivity Tips and Tricks

#51

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.”

Any ideas why ctrl+k doesn't work in my iTerm2? All other readline shortcuts work.

Re: Shell Productivity Tips and Tricks

#52

Best 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.

Re: Shell Productivity Tips and Tricks

#53
post #18

Earlier 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…

> 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.

Re: Shell Productivity Tips and Tricks

#54
post #38
post #11

> 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…

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.

Re: Shell Productivity Tips and Tricks

#55
post #52

Best 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.

OP might have made their statements tongue in cheek.

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

#57

Best 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.

no thanks.

'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

#58

Best 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.

I'd love a good answer here. Shell is clunky and annoying as hell, but a "better" language like python is very verbose for typical shell stuff like process management (processes, pipes, signal handling), small text handling tasks like regex matching or string splitting.

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
post #23
post #11

> 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.

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)

Re: Shell Productivity Tips and Tricks

#60

Earlier 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.

What is /usr/bin/cd for? cd is supposed to be a shell built-in, because running /usr/bin/cd will make another process and that cannot change the current working directory of the shell you are in.

EDIT:

  $ cat /usr/bin/cd
  #!/usr/bin/sh
  builtin cd "$@"
Post reply on HN