There are people who would not be wary of sending this kind of information remotely to be stored by someone else.
But I think the intersection of these types would be small.
Apart from some, like myself.
How would you go about it, given the need for 2-way sync? I've ruled out rsync, could see Git working but not particularly performant to run every 20 seconds to keep the history in sync between machines.
should you do this? no.. but people do, all the time.. take for example this MySQL bug report with many complaints that the command now issues a warning when you specify a password on the command line: https://bugs.mysql.com/bug.php?id=66546
Also from your FAQ what the hell is "strong level encryption", can you not name it? Can you go into the extreme technical details of what encryption you are using, how data is protected in memory and at rest?
A space at the start of the command will do the same in Bash itself - with this work for bashhub?
Actually just added a filter command as well. You can export BH_FILTER="some-regex" and it'll ignore all those commands. Just released in 0.0.14!
https://github.com/joshuacronemeyer/shellsink
(Besides being actively developed.)
[In case it wasn't clear, above was mildly tongue-in-cheek; secrets should not be in your bash history, but of course things approaching (and including) PII may well be]
I think client side encryption by Bashhub would alleviate this security concern.
Of course, client side encryption would be great in any case.
Also accidental pastes from other windows occasionally.
That said, this seems to use PROMPT_COMMAND to log off history, which would not give the opportunity for such tidying. Worrisome.
Splitting history is done fundamentally by setting HISTFILE - nothing too surprising about that.
But for my particular setup, I more broadly divide my shell use by context. I have a script called "session". `session $somename` looks for a screen (feel free to prefer tmux) session named $somename. If one exists, it attaches it. If not, it spawns it. Before doing so, it sets a shell variable SESSION to $somename. My bash_profile then customizes a lot of things based on the contents of that variable, including adding $SESSION to the prompt, and sourcing ~/.session/$SESSION/bash_profile. This lets me set context-specific aliases and such. Because SESSION is set above the terminal multiplexer, new windows spawned while in one context share the same context.
I've found most of this quite nice, but the history is the biggest win.
Any particular reason for that? It seems devastating to usability, for unclear benefit...
I view abusing your shell history as a symptom of lack of automation and functions/aliases.
Results May Vary, but in a way it made me more organized.
"A file with the `a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute."
Very clever, +1.
If the histappend shell option is enabled (see the description of shopt
under SHELL BUILTIN COMMANDS below), the lines are appended to the history
file, otherwise the history file is overwritten.
histappend
If set, the history list is appended to the file named
by the value of the HISTFILE variable when the shell
exits, rather than overwriting the file.> The bash session that is saved is the one for the terminal that is closed the latest.
http://man7.org/linux/man-pages/man1/script.1.html
I have thereby had it on my todo list for a month or so, ever since I learned of the bash DEBUG trap, to instead store my history into an sqlite3 database and have it separated by host. Seeing this reminded me "oh yeah, I really should do that" (as no: there's no way in hell I'm going to just send all of the commands I type to some random guy with a website ;P).
This is "the simplest thing that could possibly work" and might very well break if you set some crazy history configuration variables I don't use. Note that it works for pipes specifically and only because it can overwrite the same entry to the database multiple times using "insert or replace" (prevention of which is what normally makes these scripts so complex).
histsql=~/.bash_sqlite3
sqlite3 "${histsql}" '
create table if not exists "session" (
"id" integer not null primary key autoincrement,
"address" text not null,
"process" integer not null,
"tty" text not null,
"user" text not null,
"start" timestamp not null default current_timestamp,
"end" timestamp null
);
create table if not exists "command" (
"session" integer not null,
"line" integer not null,
"time" timestamp not null default current_timestamp,
"pwd" text not null,
"text" text not null,
primary key ("session", "line")
);
'
histmac=$(ifconfig | sed -e 's/ *$//; /\(ether\|HWaddr\) / { s/.* //; q; }; d;')
histtty=$(tty)
histssn=$(sqlite3 "${histsql}" "
insert into \"session\" (
\"address\", \"process\", \"tty\", \"user\"
) values (
'${histmac//\'/''}', '${$//\'/''}',
'${histtty//\'/''}', '${USER//\'/''}'
);
select last_insert_rowid();
")
function histend {
sqlite3 "${histsql}" "
update \"session\" set
\"end\" = current_timestamp
where
\"id\" = '${histssn//\'/''}';
"
}
trap histend EXIT
function histadd {
local data="$(HISTTIMEFORMAT= history 1)"
if [[ -z $data ]]; then return; fi
data="${data#"${data%%[![:space:]]*}"}"
local line="${data%%' '*}"
data="${data#*' '}"
data="${data#"${data%%[![:space:]]*}"}"
sqlite3 "${histsql}" "
insert or replace into \"command\" (
\"session\", \"line\",
\"pwd\", \"text\"
) values (
'${histssn//\'/''}', '${line//\'/''}',
'${PWD//\'/''}', '${data//\'/''}'
);
"
}
trap histadd DEBUGI've been doing this for on-call work, actually. It really helps to be able to review what was seen, what was done, how long things took, &c.
For me, the purpose of a typescript is almost entirely unrelated to the purpose of a history, though - history is things I reach for, more than things I review.