Hacker News Reader

Comment by teamhappy | Hacker News Reader

I used to do the same thing to figure out which commands I should create short aliases for. Sounded like a good idea at the time but then I realized that I'm creating a file with an awful lot of interesting information in it and I not getting a lot in return. So I set my HISTSIZE to 1000 which is more than enough for interactive shell use and I don't have to worry about having stuff like "youtube-dl fuckmesilly.com/${insane_porn_title}" lying around on servers I have access to. (Or which server you can connect to with my private key -- you might as well remove HashKnownHosts from your ssh config if you log it all yourself.)

TLDR: Overwriting history is a feature.

View on HN

not sure about "not getting a lot in return", there have been plenty of times where I have had to hand build something with strange defaults or additional commands, then six months later I am downloading the new version of the source and having the history of what I did back then is a lifesaver. Not to mention the times you remember you edited something somewhere and partially remember where/when but not exactly so you can just fuzzy search vim dirname and filter.

It does depend on what one does on their computer, obviously, but in my opinion for developers having a more or less permanent history with a fuzzy matcher (fzf is what I use) is extremely important.

I personally have bash set up so it saves a new history file each month, and a custom fzf alias to search on all of them, and I wouldn't want to have it any other way, I also treat these history files as confidential and make sure they are not in git etc. and if I have to input any passwords on the command line I just prepend the command with a space so it's not saved

Servers should have zero history saved on the disk. It gives any intruder an easy place to look for passwords, private keys, etc that may have been accidentally recorded and gives clues about related systems.

If you have administrative stuff you need to do more than once, write a little script or alias for it. Depending on history for this is just lazy.

OTOH what about audit trail? Are there any standard solutions for saving commands input at servers without giving person inputting those commands access to the logs?

Also, silly idea for a DOS attack vector: script-spam enough commands to have the audit history consume all available space on server.

We use rootsh[1] logging to syslog, which gets forwarded to a logging server, which in turn is periodically copied to a wholly separate AWS account, so that in case of breach of the main account the audit logs are intact.

[1] http://linux.die.net/man/1/rootsh

Excellent point if anyone can get access to your home directory files.

I work around the security issues by not backing up history and having encrypted file systems on all of my Linux laptops. I don't save history on my servers.

A better solution for that problem is to not screw around with personal garbage on work computers.

Yep, also back in the day it was common protocol to have .history files chmod'd to 600 by default.

Having an unlimited history is great. Sometimes there'd be a tool or resource I'd vaguely remember skimming (e.g., "oh yeah, I was working on ___, so it must have been on (day +/- 24 hours)". I'd find a command that more or less is chronologically synced with the command, then go into Chrome's SQLite history db in my User Profile to find it.

The porn example was a joke; the ssh example wasn't.

That wasn't necessary. You could easily have made the very same point without calling someone's personal pastime/hobby, "garbage".

It's one thing to use porn as an example of "things that may be awkward if found in my bash history", it's something else to get judgemental about it. Unnecessary and off-topic.

If you don't want one command to end up in your history, type a space before the command.

FYI, if you want your bash history to go dark temporarily run:

  export HISTFILE=

The rest of your session will not be logged.

The default bash setting is to not write history until the session terminates. In which case the whole session will be forgotten, not just the stuff after overwriting HISTFILE (I always set it to /dev/null FWIW, didn't know blank was sufficient).

you can also update your HISTIGNORE to do things like not log 'youtube-dl' commands, or not log 'mysql -u root -p<password>', etc.

Reply on news.ycombinator.com