New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`pipenv shell` starts /bin/sh instead of bash #2910

Closed
remram44 opened this Issue Oct 2, 2018 · 17 comments

Comments

Projects
None yet
3 participants
@remram44
Copy link
Contributor

remram44 commented Oct 2, 2018

  • 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

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Oct 2, 2018

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

This comment has been minimized.

Copy link
Member

uranusjr commented Oct 3, 2018

-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

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Oct 3, 2018

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

This comment has been minimized.

Copy link
Member

uranusjr commented Oct 3, 2018

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

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Oct 3, 2018

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

This comment has been minimized.

Copy link
Member

uranusjr commented Oct 3, 2018

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

@remram44

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Oct 3, 2018

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

@techalchemy

This comment has been minimized.

Copy link
Member

techalchemy commented Nov 26, 2018

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

This comment has been minimized.

Copy link
Member

techalchemy commented Nov 26, 2018

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

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Nov 26, 2018

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 comment has been minimized.

Copy link
Member

techalchemy commented Nov 27, 2018

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

@remram44

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Nov 29, 2018

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

This comment has been minimized.

Copy link
Member

uranusjr commented Nov 30, 2018

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

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Dec 3, 2018

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

This comment has been minimized.

Copy link
Member

techalchemy commented Dec 3, 2018

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

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Dec 3, 2018

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

@remram44

This comment has been minimized.

Copy link
Contributor Author

remram44 commented Dec 29, 2018

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

@remram44 remram44 closed this Dec 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment