search

sashahart / vex

Run a command in the named virtualenv.
MIT License
372 stars 26 forks source link

share bash history with new process? #30

Closed rsyring closed 9 years ago

rsyring commented 9 years ago

I frequently run into the situation where I run "command1", realize I'm not in a virtualenv, run vex somevenv to get a new bash working in the venv, and then hit the up arrow key to get to "command1" in bash history, only to realize that the original bash process has not exited so "command1" isn't in the new bash process.

Maybe this is just a bash thing and not in the pervue of vex. If so, feel free to close. :)

sashahart commented 9 years ago

This is worth looking at. I don't know how bash handles this. Do you have any initial ideas on the mechanism?

sashahart commented 9 years ago

Does setting histappend help? I guess you could set up .bashrc to periodically use something like history -a to read in stuff?

rsyring commented 9 years ago

It does look like bash might give me the ability to share history. I'm just not sure that I would want history shared across all process. I can look into it further from a bash-only perspective.

sashahart commented 9 years ago

I think that will be most productive because to vex, bash is just another process it doesn't know anything about. I do try to provide optional completions through --shell-config as an extra but that is the end of my control over bash processes, unless I start to do crazy things like munging bash's files out from under it or something.

rsyring commented 9 years ago

sounds good, thanks for your thoughts and for looking into it.

sashahart commented 9 years ago

zsh has SHARE_HISTORY, even if sometimes I wish that each process were its own context - I just barely leave it enabled, because I hit up and get stuff from other concurrent sessions when I mean the last thing in this session.

As far as I understand, bash can be made to write history to disk automatically, but has to be specifically asked to read that in from other processes. So one possibility is for whatever periodically triggers that read, simply not to be activated from some processes (e.g. based on an environment variable). Another possibility is that you could tell different bash processes to use different history files.

I'm envisioning some kind of system where you can tell shell processes a certain 'tag' and that is set by whatever is launching the terminal, and then a little shell ensures that history is specific to the tag so that there is sharing but also some intelligent context separation.