Skip to content
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

terminal should be login shell, not interactive shell #3094

Closed
bklaas opened this issue Oct 13, 2017 · 15 comments

Comments

@bklaas
Copy link

@bklaas bklaas commented Oct 13, 2017

The summary of this issue is that I think when initially launching a terminal it should start a login shell, not a shell in interactive mode.

I have a jupyterlab instance running via jupyterhub on a shared (ubuntu) linux server. Default shell for all users is bash.

When I launch a terminal in jupyterlab, it sources my .bashrc file, which in turn sets my PS1 prompt with some dynamic git information via the __git_ps1 bash function that the git package provides and is made available in login shells via /etc/bash_completion.d/git-prompt. The scripts in bash_completion.d/ are only sourced if you are in a login shell. As a result, every time I hit return in the terminal it throws a "__git_ps1: command not found" error.

We also have some environmental variables, e.g. PERL5LIB, that are set inside /etc/profile.d/ scripts. Again, these are not sourced in jupyterhub terminal because it's not a login shell.

We've worked around this by setting PERL5LIB in /etc/environment (not a great solution from a devops perspective, but works in interactive shells) and hacking my .bashrc to source /etc/bash_completion.d/git-prompt.

Nevertheless, it seems reasonable to think that a terminal in jupyterhub should begin life as a login shell.

@blink1073

This comment has been minimized.

Copy link
Member

@blink1073 blink1073 commented Oct 13, 2017

@takluyver, thoughts on this?

The default shell command is handled here.

It is configurable by setting config for c.NotebookApp.terminado_settings = { "shell_command": "foo" }

https://github.com/jupyter/notebook/blob/master/notebook/notebookapp.py#L770
http://jupyter-notebook.readthedocs.io/en/stable/config_overview.html#configure-common

@blink1073

This comment has been minimized.

Copy link
Member

@blink1073 blink1073 commented Oct 13, 2017

cc @minrk

@takluyver

This comment has been minimized.

Copy link

@takluyver takluyver commented Oct 13, 2017

I'd expect it to do the same as launching a terminal emulator inside my desktop, which runs .bashrc but not .bash_profile (i.e. it is an interactive shell, not a login shell).

I guess there's an argument that Jupyterhub should start it's singleuser server through a login shell: that is the step where you become a logged in user, analogous to logging in to your graphical desktop.

Running a login shell for a graphical login has been a point of controversy with the move to Wayland: initially it didn't run through a login shell, and there was talk of a more declarative way to set environment variables on login. But it wasn't happening quickly enough, so they relented and made it run a login shell again.

@minrk

This comment has been minimized.

Copy link
Contributor

@minrk minrk commented Oct 14, 2017

Arg, it's always annoyed me that login and interactive shells are different.

@takluyver is right that to get probably the most expected behavior is to launch the notebook server via a login shell. One way to do that is to make a script that itself tells bash to invoke a login shell, and then launch jupyterhub-singleuser:

#!/usr/bin/env bash -l

# any additional initialization can go here, too
export MYVAR=foo
source /etc/jupyter/extra-bash.d/...

# launch jupyter (exec and $@ are important!)
exec jupyterhub-singleuser $@

and then change c.Spawner.cmd = [ '/path/to/my/script.sh' ] in jupyterhub_config.py

@bubthegreat

This comment has been minimized.

Copy link

@bubthegreat bubthegreat commented Feb 22, 2018

I can see use cases for both, but it doesn't look like this is a configurable option via the jupyterhub interface. I'd personally like this to be something I can configure in the settings -> Terminal settings -> default shell

@bklaas

This comment has been minimized.

Copy link
Author

@bklaas bklaas commented May 29, 2018

A polite bump to ask this gets included in a 1.0 release.

Respectful of the previous comment, however I'm not sure there is a real use case for a new terminal inside jupyterlab not being a login shell. To be clear, I don't mean requiring the user to manually login to every new terminal shell, I mean sourcing the startup files that are sourced in a login shell context.

@Monduiz

This comment has been minimized.

Copy link

@Monduiz Monduiz commented Feb 25, 2019

I have to add my voice to this as an important thing to add. We are using jupyterhub with Jupiter Lab to coordinate work on virtual machines and it simplified our workflows by a lot. However, if we need to add something to our conda environments, we have to ssh into the VMs using a separate terminal because the Jupiter Lab terminal is not functional as it's not sourcing from login configurations.

@jasongrout

This comment has been minimized.

Copy link
Contributor

@jasongrout jasongrout commented Feb 25, 2019

From the conversation above, it sounds like this is an issue in the notebook server, not JupyterLab. Do you have the same issue in the terminal launched by the classic notebook?

@bklaas

This comment has been minimized.

Copy link
Author

@bklaas bklaas commented Feb 25, 2019

Huh, you learn something every day, I wasn't even aware the terminal was delivered via the Notebook server :)

I can confirm that the same issue is seen with the terminal launched by the classic notebook.

Can you give a pointer as to how best to push this issue towards the right project? Still very interested in this issue getting some attention.

@Monduiz

This comment has been minimized.

Copy link

@Monduiz Monduiz commented Feb 25, 2019

Right, I should have thought of that too. We push this to jupyterhub or jupyter.

@jasongrout

This comment has been minimized.

Copy link
Contributor

@jasongrout jasongrout commented Feb 25, 2019

@blink1073's comment above points out the code location for the default terminal command in the https://github.com/jupyter/notebook/ repo. I think that repo is probably the appropriate place for discussing this change.

@jasongrout

This comment has been minimized.

Copy link
Contributor

@jasongrout jasongrout commented Feb 25, 2019

(Or since it's a setting you can set, perhaps whoever launches the notebook should be responsible for something like this, i.e., jupyterhub?)

@jamesdbrock

This comment has been minimized.

Copy link

@jamesdbrock jamesdbrock commented Apr 4, 2019

It looks like the shell was forced to be a login shell in this commit from Oct 18, 2018

jupyter/notebook@f859abd

This was done by appending the -l switch to the shell_command, so now it seems that it's impossible to make the login shell interactive by setting the shell_command like:

c.NotebookApp.terminado_settings={'shell_command':['bash', '-i']}

because the -l switch will come after and override the -i switch.

@jasongrout

This comment has been minimized.

Copy link
Contributor

@jasongrout jasongrout commented Apr 4, 2019

Interesting. Again, it sounds more appropriate to bring this up in the https://github.com/jupyter/notebook/ repo, where that code is.

@bklaas

This comment has been minimized.

Copy link
Author

@bklaas bklaas commented Apr 4, 2019

I'm going to mark this issue as closed because it's not a jupyterlab issue

As a closing point to anyone reading this issue though, the checkin to notebook made Oct 18, 2018 referenced above still hasn't been pushed out in an actual release.

The fix is merged into master, slated to be included with the 5.8 release of jupyter/notebook

@bklaas bklaas closed this Apr 4, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Aug 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
9 participants
You can’t perform that action at this time.