It looks like bash understands $SHELL but this shell is not a login shell which means people who have customized their $PROMPT_COMMAND in their Dotfiles end up with weird errors.
A couple of solutions I can think of.
--login --interactive$SHELL, you can run exec and source the virtualenv.pipenv shell many many times.it should not, actually! it's a subshell, only your login shell (the one invoking pipenv) should be invoked as a login shell.
Check out the pew docs for more information. For the record, are you using --compat?
I've tried both --compat and not as well.
So what you're saying is that the subshell should inherit the configuration of the parent shell? I would agree, except when I run pipenv shell my ~/.profile is not sourced
The pew docs will help you get your shell setup properly 鈥斅燽asically, your PATHs and PS1s and friends should only be setup during a login shell, not for every invocation of bash.
Just read through some of the pew docs (that was helpful), so I'm looking right here in the troubleshoot section.
They recommend that you move your PATH declarations into ~/.profile and execute as a login shell.
Also, this table was really helpful me figure out why ~/.profile was not getting sourced
| Mode | /etc/profile | ~/.bash_profile | ~/.bash_login | ~/.profile | ~/.bashrc | ${ENV} |
|---|---|---|---|---|---|---|
| Login shell | X | X | X | X | - | - |
| Interactive Shell | - | - | - | - | X | - |
| SH compatible login | X | - | - | X | - | - |
| SH compatible | - | - | - | - | - | X |
| POSIX庐 compatiblity | - | - | - | - | - | X |
Great table!
After reading the pew docs and combing deep caverns of shell scripting lore I discovered that functions can be exported _(who knew that was a thing!)_.
So let's say I have function that fork bombs your shell and I want to hot potato it into a child shell processes.
$ function forking { forking | forking & }
$ pipenv shell
$ foobar
bash: foobar: command not found
Bash prevents child processes from cases of unprotected forking somtimes.... You need to explicitly flag functions using export -f foobar or declare -fx foobar.
$ declare -F
declare -fx powerline_precmd
Even if the functions are bound to environment variables that are themselves exported, the new sub shell is passed a new copy of the functions and not a reference.
A good example is ${PROMPT_COMMAND} which is usually bound to a function that populates the variable. That function will get called every time $PS1 is displayed so make sure to export it.
function powerline_precmd() {
export PS1="$(powerline-shell 2> /dev/null)"
}
declare -fx powerline_precmd
export PROMPT_COMMAND="powerline_precmd"
@jjangsangy were there any actionable items we were still looking for here or were you able to find what you needed in the pew docs? If so, I'm proposing we close this issue out.
I addressed the issue by going through and exporting all functions needed by the subshell to render my prompt. This feels a bit like a hack, but I don't mind.
I am somewhat hesitant closing this issue without some explicit documentation regarding this behavior as users will likely come across this regularly. For both powerline-shell and iTerm2 have functions which I needed to export resulting in something like this in my ~/.profile
declare -fx iterm2_begin_osc
declare -fx iterm2_end_osc
declare -fx iterm2_preexec_install
declare -fx iterm2_preexec_invoke_cmd
declare -fx iterm2_preexec_invoke_exec
declare -fx iterm2_print_state_data
declare -fx iterm2_print_user_vars
declare -fx iterm2_print_version_number
declare -fx iterm2_prompt_mark
declare -fx iterm2_prompt_prefix
declare -fx iterm2_prompt_suffix
declare -fx powerline_precmd
declare -fx precmd
declare -fx preexec
There are also edge cases, nvm, the node package manager heavily relies on functions to link node environments. If in case some developer dual wielding package managers ever appears god have mercy.
Most helpful comment
Just read through some of the pew docs (that was helpful), so I'm looking right here in the troubleshoot section.
They recommend that you move your
PATHdeclarations into~/.profileand execute as a login shell.Also, this table was really helpful me figure out why
~/.profilewas not getting sourced/etc/profile~/.bash_profile~/.bash_login~/.profile~/.bashrc${ENV}