I wrote this thing and I'd like to source a Python virtualenv activate script whenever a new window is created in a running session.
Is it possible? The default-command option is related to the shell, not an additional command.
I am making the following assumptions:
You are using bash
Your .bashrc file is source for each new window that starts a shell
You only want to start your virtualenv in a window that runs a shell
Add the code you want to run to your .bashrc:
if [[ $TMUX ]]; then
# code here
fi
This code will only run for new shells which are in an existing tmux session.
Related
So in my rifle.conf I have
ext org, has emacs, terminal, flag f = emacs "$#"
However it opens the file with the GUI version of emacs?
How do I open it with 'emacs -nw filename'?
I tried what Tom had said but I found that there were too many steps to open my org file. I wanted to be able to just press enter on an orgfile within ranger and have it open emacs -nw file.org, within the tmux pane running ranger.
The following solved my dilemma:
!mime ^text, label editor, ext org = emacs -nw -- "$#"
Edit: Interesting dig - after a look at OPs solution above: It turns out ranger does indeed open a terminal program 'on top of itself', so to speak.
The culprit in OPs first attempt is the flag f, in fact the minimal
ext org = emacs -nw "$#"
works like a charm.
Old attempts:
As far as I read the docs, you cannot open a file with a program running in the same terminal as ranger itself is running
in (I may be wrong, though).
Following the documentation I exported TERMCMD, since I'm using tmux with TERM=screen-256color, ranger cannot infer the terminal to use from that:
# just a test, I don't use xterm
export TERMCMD=xterm
And simply added the t flag and -nw to the command in rifle.conf:
❯ cat ~/.config/ranger/rifle.conf
ext org, has emacs, terminal, flag tf = emacs -nw "$#"
Hitting r in ranger
0 | emacs -nw "$#"
:open_with 0
This opens a new xterm, starting a new emacs editing the file in question. You can simply press the Return key while on the file in question with this setup; using r would show all available options.
If you are living in the terminal and don't want to start another graphical terminal, I suggest using something like tmux - you can use tmux commands to open files, in this case like so
ext org, has emacs, terminal, flag f = tmux splitw -h emacs -nw "$#"
splitting the current pane (with ranger running), launching a new pane to the right of the current one and starting emacs there. The pane will be closed when you quit emacs. I'd probably start an emacsserver and use emacsclient -nw in this scenario.
I have sciprt that launches my development environment with multiple tmux tiles. I want to spawn a shell that sources my environment so I dont have to source it myself.
I usually do the following each time I open the tmux tile:
source env/bin/activate
I spawn my shell with $SHELL, I use zsh. I see that bash has the --init-file flag which sources a file, this also does not load the bashrc. I guess thats close but not good enough.
I am looking for something like this $SHELL --source ~/env/bin/activate. Or any workarounds also help
I don't think this is possible; Your best bet is to implement a workaround in your own .zshenv file, e.g.,
if [[ test -e "$MY_INIT_SCRIPT_675" ]] ; then
source "$MY_INIT_SCRIPT_675"
fi
I have as on single command "new" in my $HOME/.tmux.conf so I can call tmux attach as a command automatically using ssh. Recently (I believe since version 2.7) I am seeing a strange effect that if I use "tmux attach" and I do not have a session running a new session is started as expected (as I have the new command in my .tmux.conf) but the current working directory is "." if I use echo $PWD. If I use tmux without arguments to create a new session anyways I get a normal $PWD, in my case it is $HOME as I always call tmux right after logging in.
This wreaks havoc with a few shell scripts, for example the mvim script is not able to open any files in macvim any longer. If I use "cd $HOME" after using tmux attach for the first time when it created a new default session it works OK. Does anybody have any clue on how to fix that without issuing "cd $HOME"?
I just found that tmux version 2.8 fixes the problem.
I am trying to use PS1 to customise my command prompt in mac, but the changes are not saved, when I try to re-open the terminal.
I have edited the .bashrc file, and the changes are effective only for that session. If I close and re-open the terminal, all saved changes are lost.
Below is the .bashrc file that i have edited.
export PS1="\u#\h \d \# \w >"
export PATH="/Users/avbanerj/test_script1:$PATH"
Could you please tell me what shall I add in my .bashrc or .profile so that changes are reflected everytime I open the terminal?
This is from info bash.
-Erik
6.2 Bash Startup Files
======================
This section describes how Bash executes its startup files. If any of
the files exist but cannot be read, Bash reports an error. Tildes are
expanded in filenames as described above under Tilde Expansion (*note
Tilde Expansion::).
Interactive shells are described in *note Interactive Shells::.
Invoked as an interactive login shell, or with '--login'
........................................................
When Bash is invoked as an interactive login shell, or as a
non-interactive shell with the '--login' option, it first reads and
executes commands from the file '/etc/profile', if that file exists.
After reading that file, it looks for '~/.bash_profile',
'~/.bash_login', and '~/.profile', in that order, and reads and executes
commands from the first one that exists and is readable. The
'--noprofile' option may be used when the shell is started to inhibit
this behavior.
When an interactive login shell exits, or a non-interactive login
shell executes the 'exit' builtin command, Bash reads and executes
commands from the file '~/.bash_logout', if it exists.
Invoked as an interactive non-login shell
.........................................
When an interactive shell that is not a login shell is started, Bash
reads and executes commands from '~/.bashrc', if that file exists. This
may be inhibited by using the '--norc' option. The '--rcfile FILE'
option will force Bash to read and execute commands from FILE instead of
'~/.bashrc'.
So, typically, your '~/.bash_profile' contains the line
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
after (or before) any login-specific initializations.
My Mac OS command line application is making Unix calls such as:
system("rm -rf /Users/stu/Developer/file);
perfectly successfully.
So why is the following not changing the current directory?
system("cd /Users/me/whatever");
system("pwd"); //cd has not changed
Because
system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed.
So each command is executed independently, each in a new instance of the shell.
So your first call spawns a new sh (with your current working directory), changes directories, and then exits. Then the second call spawns a new sh (again in your CWD).
See the man page for system().
The better solution is to not use system. It has some inherent flaws that can leave you open to security vulnerabilities. Instead of executing system() commands, you should use the equivalent POSIX C functions. Everything that you can do from the command-line, you can do with C functions (how do you think those utilities work?)
Instead of system("rm -rf ...") use this.
Instead of system("cd ...") use chdir().
Instead of system("pwd ...") use getcwd().
There are some differences, of course, but these are the fundamental equivalents of what you're trying to do.