Live data from Hacker News

Bashhub – Bash History in the Cloud

bashhub.com

31–40 of 49 posts

Re: Bashhub – Bash History in the Cloud

#31

Earlier quoted context omitted.

I wonder if this solves the issue of multiple bash instances clobbering history.

From the bash manpage: 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.

http://askubuntu.com/a/80380/288724 looks like it might be my issue, specifically

> The bash session that is saved is the one for the terminal that is closed the latest.

Re: Bashhub – Bash History in the Cloud

#32

Earlier quoted context omitted.

Not saying I make of habit of this, but sometimes you have to pass sensitive things as arguments (passwords, api tokens, customer data, etc), it happens. I think client side encryption by Bashhub would alleviate this security concern.

One of the AWS config utilities comes to mind - you have to paste in your AWS key if running interactively.

Actually `aws configure` is interactive when it asks for input. Those values won't be stored in `history`.

Re: Bashhub – Bash History in the Cloud

#33

Earlier quoted context omitted.

I expect I might take more care about maintaining a tidy history (see my other comment about splitting out separate histories by context), and reflexively clear bits of my history when I don't want them hanging around in the way of a ctrl-r - which would certainly include bits of passwords and anything pasted. That said, this seems to use PROMPT_COMMAND to log off history, which would not give the opportunity for suc…

I can't see your comment about splitting history - this sounds like something I'd use, though.

https://news.ycombinator.com/item?id=10695029 is the comment, but it didn't contain much detail.

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.

Re: Bashhub – Bash History in the Cloud

#35

Earlier quoted context omitted.

You are giving all your bash history to a third party, that is incredibly scary and if you can't see the security implications then you need to rethink your product.

Agree privacy is a concern. You can configure what you do and don't send as well.

the problem is, theres a pretty good chance people will still send all sorts of passwords and access credentials. that's a big liability if you get exploited.

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

Re: Bashhub – Bash History in the Cloud

#36
post #20
post #19

There are people who use bash enough--and in such a way--that they'd benefit from this kind of .bash_history backup and analysis. 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.

Well, the people in the first category will usually be smart enough to setup a sync without using an external "cloud service".

> Well, the people in the first category will usually be smart enough to setup a sync without using an external "cloud service".

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.

Re: Bashhub – Bash History in the Cloud

#37
I have routinely kept my history "best effort" for many many years now by exporting HISTSIZE=10000 and HISTFILESIZE=1000000, and then occasionally doing a cp -a ~/.bash_history{,-$(date +%s)}. I actually use this history archive, and wish it was higher fidelity. (In practice, I am thinking I should just run all my sessions through script... ;P.)

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 DEBUG

Re: Bashhub – Bash History in the Cloud

#39
post #37

I have routinely kept my history "best effort" for many many years now by exporting HISTSIZE=10000 and HISTFILESIZE=1000000, and then occasionally doing a cp -a ~/.bash_history{,-$(date +%s)}. I actually use this history archive, and wish it was higher fidelity. (In practice, I am thinking I should just run all my sessions through script... ;P.) http://man7.org/linux/man-pages/man1/script.1.html I have thereby had it…

"(In practice, I am thinking I should just run all my sessions through script... ;P.)"

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

Post reply on HN