I would like to be able to open a terminal that automatically changes working directory to the directory where I have the file browser. At the moment I open a terminal and I have to work out where I have the browser and manually cd there.
Is that possible at all?
@Eduardo_Gonzalez which version of JupyterLab are you using? I think that the behaviour that you described is the default since JupyterLab 3.4 (implemented in Open terminal in cwd from launcher by rccern · Pull Request #12250 · jupyterlab/jupyterlab · GitHub).
Glad you supplied the links to the PR tracking this. Indeed, I thought that was the case that it was the behavior now. Yet in JupyterLab 3.4.8 served via MyBinder, it doesn’t work at present. You can try opening a terminal in the ‘binder’ directory in launches from here to see that with JupyterLab 3.4.8 currently. The notebook opened there does inherit the working directory from the launcher.
The terminal does inherit the working directory from the launcher in sessions served via MyBinder launched from the launch badge here, which results in JupyterLab version 4.0.0a23. (Direct launch url for that version here.)
This is because this binder (and probably all default Binder instances?) is running on the old
notebook server rather than the new
jupyter-server server (>=1.16 is required for this feature). You can check which server is active by running
jupyter server list and
jupyter notebook list.
Yes, images built with repo2docker still use the old server.
The notebook server was kept when the switch to JupyterLab was made to ensure most extensions would continue to work. Enough time has passed that we could probably switch now, though there’s a separate discussion on switching to Notebook 7, in which case jupyter-server would be automatically started:
It does work if you open a terminal from the Launcher. It does not work however if you open the terminal from the File → New → Terminal but that is fine for me.
Would you mind opening an issue on JupyterLab GitHub? I think that this is because the
cwd is passed in that code path and think we should fix it for consistency of UX.