Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shell Productivity Tips and Tricks

blog.balthazar-rouberol.com

Post reply on HN
Print view View original

91–97 of 97 posts

Re: Shell Productivity Tips and Tricks

#91

Post by capableweb »

jpxw wrote: 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…

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.

Re: Shell Productivity Tips and Tricks

#92

Post by wazzaps »

usefulcat wrote: post #61

If you care about your command history, I would advise against doing this unless you are truly a sed expert: $ sed -i '/secret-command/d' $HISTFILE # deletion of history line containing 'secret-command' Because if you get it even slightly wrong, you could easily hose your entire history. If it were me, I would just use an editor to delete that line (or two, if timestamps are enabled).

And if you know don't want a command in your history, prefix it with a space.

Re: Shell Productivity Tips and Tricks

#93

Post by fragmede »

LEARAX wrote: post #84
ASTP001 wrote: post #43

Earlier quoted context omitted.

I really enjoyed using fish for a short while, but soon I learned that it was not POSIX compliant. This was a deal breaker for me since my colleagues would often share scripts that wouldn't just work for me. I use zsh nowadays.

Well, you could always just use a shebang or call bash/sh directly on the file.

Without the same fluency in bashism from using it for day-to-day activities, the colleague provided script is less readable and less editable for the fish-fluent, bash-inarticulate. Any fish-specific scripts are also of low-value to colleagues.

It's not that it's impossible to be a shell polyglot, but GP deemed it easier to learn !fish.

Re: Shell Productivity Tips and Tricks

#94

Post by jedimastert »

fooblat wrote: post #53
jedimastert wrote: post #22

Earlier quoted context omitted.

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.

Would it? Poo. That's my bad.

Re: Shell Productivity Tips and Tricks

#95

Post by jedimastert »

lmz wrote: post #24
jedimastert wrote: post #22

Earlier quoted context omitted.

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…

How would backticks help with hiding it from ps?

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

Re: Shell Productivity Tips and Tricks

#96

Post by fitzn »

mturmon wrote: post #54
fitzn wrote: post #38

Earlier quoted context omitted.

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.

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

Re: Shell Productivity Tips and Tricks

#97

Post by gimboland »

__Joker wrote: post #67
alufers wrote: post #27

The single best shell productivity tip for me was to use z: https://github.com/rupa/z It automatically makes a list of directories you frequently use in your shell and if you type `z a-small-substring-of-the-directory-path` it does a cd to that directory. (e.g. I type `z and` and it changes my current directory to $HOME/Work/Projects/android`). Saved me tons of typing.

Sound similar to autojump. https://github.com/wting/autojump

I use autojump, but I liked the idea of having an fzf-powered menu pop up when invoked without any args (which is not how autojump behaves). So I made rustled this up (zsh): https://pastebin.com/aLmqJVRy
Post reply on HN