pipenv shell starts /bin/sh instead of bash

[remram44]

• Be sure to check the existing issues (both open and closed!), and make sure you are running the latest version of Pipenv

Issue description

I just updated to 2018.7.1 and pipenv shell starts /bin/sh instead of /bin/bash (so my prompt is gone, I'm running dash, etc).

Expected result

pipenv shell should start my shell.

Actual result

remram@axon:~$ pipenv shell
Launching subshell in virtual environment…
$  . /tmp/v/.local/share/virtualenvs/v-GWEjRKuf/bin/activate
$ echo $RANDOM

$

Steps to replicate

remram@axon:~$ pipenv --three
remram@axon:~$ pipenv shell

I tried running this in a brand new HOME with env -i HOME=/tmp/pe bash to make sure I don't have weird env/bashrc/... but same result.

---

$ pipenv --support

Pipenv version: '2018.7.1'

Pipenv location: '/home/remram/Documents/programming/_venvs/ipython/lib/python3.6/site-packages/pipenv'

Python location: '/home/remram/Documents/programming/_venvs/ipython/bin/python3.6'

Other Python installations in PATH:

• 2.7: /usr/bin/python2.7

• 2.7: /usr/bin/python2.7

• 3.6: /usr/bin/python3.6m

• 3.6: /usr/bin/python3.6

• 2.7.15: /usr/bin/python

• 2.7.15: /usr/bin/python2

• 3.6.6: /usr/bin/python3

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.6.3',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.15.0-34-generic',
 'platform_system': 'Linux',
 'platform_version': '#37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018',
 'python_full_version': '3.6.3',
 'python_version': '3.6',
 'sys_platform': 'linux'}

System environment variables:

• LESSOPEN
• SHLVL
• HOME
• _
• PATH
• LANG
• LS_COLORS
• LESSCLOSE
• GCC_COLORS
• LC_ALL
• PWD
• VIRTUAL_ENV_DISABLE_PROMPT
• PYTHONDONTWRITEBYTECODE
• PIP_PYTHON_PATH

Pipenv–specific environment variables:

Debug–specific environment variables:

• PATH: /home/remram/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
• LANG: C.UTF-8
• PWD: /tmp/v

---

Contents of Pipfile ('/tmp/v/Pipfile'):

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]

[dev-packages]

[requires]
python_version = "3.6"

[remram44]

Note: your docs mention a pipenv shell -c which doesn't seem to exist. The issue template also mentions --verbose options that are not recognized either.

[uranusjr]

-c is now the default, and the previous feature is now accessible by --fancy. A PR on documentation would be welcomed.

Would you mind showing a result of the following command?

ps -o pid -o ppid -o args

This lists the process tree on your system, which is used to detect what your current shell is (so Pipenv can launch a matching one).

[remram44]

That sounds super-weird. Why not use my shell as per /etc/passwd? Or at least the $SHELL variable?

Here's the requested info:

remram@axon:~$ ps -o pid -o ppid -o args
  PID  PPID COMMAND
 9659   621 /bin/bash
 9777  9659 ps -o pid -o ppid -o args

remram@axon:~$ pstree -ps $$
systemd(1)───kdeinit5(2733)───konsole(621)───bash(9659)───pstree(9865)

[uranusjr]

Because your login shell (/etc/passwd or $SHELL) does not necessarily match your current shell. Fun fact: Pipenv actually used to do exactly what you suggested, and we got a few, let’s say quite angry, users insisting it is wrong :)

Back to your problem though, the ps output seems intrigueing, since bash is correctly listed, and (more importantly) sh is nowhere to be seen. Pipenv shouldn’t have picked sh up if it is not present. Are you sure pipenv shell is running sh? You can check the process tree inside pipenv shell to make sure.

[remram44]

I'm sure! Here's ps output:

remram@axon:~$ pipenv shell
Launching subshell in virtual environment…
$  . /home/remram/.local/share/virtualenvs/datamart-0guHTfin/bin/activate
$ ps -o pid -o ppid -o args
  PID  PPID COMMAND
10437 10432 /bin/sh -i
10438 10437 ps -o pid -o ppid -o args
$ pstree -ps $$
systemd(1)---kdeinit5(2733)---konsole(621)---sudo(20895)---bash(20959)---pipenv(10431)---pipenv(10432)---sh(10437)---pstree(10455)

[uranusjr]

Hmm, I wonder where that sudo came from, It wasn’t in the other tree.

[remram44]

Ah, I ran sudo -g docker -Es in that terminal at some point. But the bug happens regardless.

[techalchemy]

random guess, you have a thing in your $bashrc that gets run only when running not as a login shell, that runs /bin/sh -i by default

[techalchemy]

BTW Im interested in why you have two copies of pipenv there... on my system it looks like this (swapped to bash, then used sudo -g docker -Es just to be on the same page):

(test)   ³ test-hxkKlP5o  /t/test  pstree -ps %self
systemd(1)───tmux: server(2674)───fish(22829)───fish(22962)───bash(23568)───sudo(29356)───fish(29357)───pipenv(29628)───fish(29684)───pstree(30068)

[remram44]

I only have the default:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Nothing that execs /bin/sh

The first pipenv processes in pstree appears to be the shell script that's in my path, which calls the distutils-generated pipenv binary, in its actual location in a virtualenv (.../virtualenvs/pipenv/bin/pipenv "$@")

[techalchemy]

This is incredibly weird. I wish I could reproduce it...

[remram44]

I do not normally pip install stuff globally on my system. Do you?

Therefore, I have scripts in my PATH pointing to the virtualenv they are installed in.

This script reads:

#!/bin/sh
exec /home/remram/.virtualenvs/pipenv/bin/pipenv "$@"

nothing weird. Except I forgot the exec in this particular one, which is why it showed up in the pstree.

Is something like that supposed to break pipenv shell?

[uranusjr]

Is something like that supposed to break pipenv shell?

Conceptually, probably not, but I can’t think of a technically feasible way to avoid it. pipenv shell “detects” the nearest shell process, and launch it as the subshell. It really has no way to tell whether it really is run as the interactive shell.

[remram44]

The fact that you decided to ignore $SHELL, /etc/passwd, and /etc/shells is what makes it technically unfeasible. I'll make my own wrapper for this that behaves sanely, if that is the only way to go.

[techalchemy]

I mean, literally dozens of users filed issues complaining that we used $SHELL and ignored what they were actively running pipenv with, so arguably I would say that it’s more strange that you are choosing to put a different shell process between yourself and pipenv.

Please read the documentation for how to specify a shell override, I’m sure it’s PIPENV_SHELL but the list is here: https://pipenv.readthedocs.io/en/latest/advanced/#configuration-with-environment-variables

And please don’t act like we are insane because your specific usage doesn’t do exactly what you expect. We are a small team and of all the things that could go ‘wrong’, or be ‘technically unfeasible’ this isn’t really one of them. It’s a behavior that had to be chosen, and when the prior behavior was the default it was both a bad user experience and supremely unpopular. Sorry you don’t think this is a technically feasible approach. You can override it with the environment variable I mentioned.

[remram44]

I wouldn't call a script calling pipenv a "shell process between yourself and pipenv". It's just a regular process.

[remram44]

I'm moving to poetry which is less clunky and a lot easier to use (no more setup.py). Thanks.

[frob]

So the solution here is to use PIPENV_SHELL. I am running into the same issue with MacOS. I launch pipenv shell with a Makefile command and that somehow must be the same as wrapping it in a script.

Not to rehash, but @remram44 couldn't you just change your script to:

#!/bin/bash
exec /home/remram/.virtualenvs/pipenv/bin/pipenv "$@"

[frob]

For anyone playing at home, I was able to solve my problem by using bash -c to launch the shell.

## Open a development shell.
shell:
	bash -c "cd $(SRCDIR) && \
	pipenv shell && \
	cd $(PWD)"

[remram44]

I switched to Poetry and no longer have any problem!

[perlun]

@uranusjr

-c is now the default, and the previous feature is now accessible by --fancy. A PR on documentation would be welcomed.

A bit late, but here we go: #4659