WSL hide /mnt/c/Users/ - windows

It is possible to view shorter path in my terminal (VS Code & Hyper) with WSL (Ubuntu). On top of the Ubuntu, I have installed zsh. Currently, I am using a git bash and path looks Lukas#Y50-70 ~/Coding but with the Ubuntu, I have something like this lukas#Y50-70 /mnt/c/Users/Lukas/Coding. When I have a project in another 2 folders or so and I have a long branch name it is annoying to have a full row unnecessary info (for me).
Here is a comparison of Ubuntu and git bash:
Thanks

I was able to solve this using Named Directories - by adding this line to your ~/.zshrc file
hash -d c=/mnt/c
you will see '~c/' in your prompt rather than '/mnt/c/' which I think is a lot nicer.
This has a similar effect to setting an alias for the directory but the name is reflected in how your path is displayed.
As an added bonus you can then switch to that directory at any time by typing ~c

Check if the zsh installation guide under WSL can help (from neurogenesis):
Install zsh with sudo apt-get install zsh
bash.exe is the entrypoint to the WSL / linux subsystem. You'll have to modify the windows shortcut to specify bash -c --login or modify ~/.bashrc with exec /bin/zsh to properly load a different shell.
/etc/passwd isn't consulted because it's not a full login process. Be sure to set your SHELL env var as well. See #846 for details.
Fix your umask before you start installing things, otherwise tools like zsh will complain.
Specifically, "group" and "other" permissions will have the same privileges that owner do. This causes zsh's compaudit and compinit to fail (both are related to command completion).
See #352 for details. umask 022 can be added to your ~/.bashrc.
NOTE: This should be done before trying to install zsh plugin managers like antigen (otherwise the directory/file permissions issues from git clones).
You should also do this before installing RVM or rbenv.
I ended up inserting a few lines to the top of my ~/.bashrc, something like the following:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
## Fix missing umask value
umask 022
## Launch Zsh
if [ -t 1 ]; then
cd $HOME
export SHELL=/bin/zsh
exec -cl $SHELL
fi
Issue 846 (mentioned in point 2) includes the comment:
A normal -c zsh symlink opened up in the wrong directory to me, but I managed using this (note the tilde):
C:\Windows\System32\bash.exe ~ -c /bin/zsh
See also "How to Use Zsh (or Another Shell) in Windows 10".

I know this isn't exactly the fix you were hoping for. I was looking to solve the same issue. The prompt was just too long and it was causing some of my commands to wrap to the next line. After seeing the comments on VonC's answer, I'm deciding to keep my next-best solution.
What I did in my ~/.bashrc file is this:
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\n\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u#\h:\w\n\$ '
fi
I added a \n right before the \$
So when I'm at my Windows home folder, it looks like this
ryan#DESKTOP-RSKAA4F:/mnt/c/Users/ryank
$
And I start typing my commands after the $. It takes up more vertical space, but at least I don't have to maximize my terminal window just to avoid text wrap.

It appears to me that just running 'cd' after starting the terminal session, re-bases the prompt to the normal '/home/(user)'
there should be no need for installing zsh or anything else. It works for me anyway.
also when starting the session at the root folder from windows, seems to do the trick.
I keep my sessions under
C:\vms
sample:
cd -d C:\vms\minikube\ubu_jenkinsX\rootfs
C:\vms\minikube\ubu_jenkinsX\rootfs>wsl -d ubu_jenkinsX
Yours may be under your userprofile in local data. Search for the rootfs folder

The reason your WSL prompt shows such a long path is because you're not actually in your home directory. You see, WSL has its own virtual filesystem separate from Windows, and Windows paths (like your C:\Users\Lukas\...) are stored under /mnt/c/Users/Lukas/.... Your WSL home directory would be /home/Lukas (since your WSL username is capitalized), but of course, that's not where your project is.
The fish shell has a prompt_pwd function that shortens a path to something like this:
0 ---- /m/c/U/L/Documents cd Something
0 ---- /m/c/U/L/D/Something prompt_pwd
/m/c/U/L/D/Something
Is that something you're interested in? You could port the function to Bash, or just switch to Fish, or just display the current directory name instead of path.

Related

How to login to bash with current user, and the user's .bashrc file, in jupyterlab?

I have a configuration file setup in .bashrc which I would like to apply to all terminals opened automatically in my jupyterlab.
Currently jupyterlab terminals start like this, without any of the configuration in my .bashrc file.
If I simply type bash and hit enter it does exactly what I want. Like below.
I would like for it to automatically open like this.
How can this be achieved?
Here is a very similar question.
But none of the solutions work, I mean it does open bash, not shell, so I'm not sure if that solution is what I'm looking for. But I've changed my tornado settings, I've added the environment variable SHELL=/bin/bash but none of it has any affect. (I've obviously restarted jupyterhub each time to see the effect.
Here is my jupyterhub start file 'jupyterhub.service', located in '/etc/systemd/'.
[Unit]
Description=Jupyterhub
After=syslog.target network.target
[Service]
User=root
Type=simple
Environment="PATH=/anaconda3/bin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
Environment="SPARK_HOME=/spark-2.3.2-bin-hadoop2.7/"
Environment="SHELL=/bin/bash"
ExecStart=/anaconda3/bin/jupyterhub -f /etc/jupyter/jupyterhub_config.py
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
Based on this github issue, bashrc needs to be sourced from profile.
I've confirmed this works by adding the following to /home/jovyan/.profile:
bash
source /home/jovyan/.bashrc
You could try creating a file
$HOME/.bash_login
and source .bashrc from there
source $HOME/.bashrc
and see if it does what you wanted.
Let me do some wild guess for what happened:
1. Config issue
As one of the comment said, change jupyter_notebook_config.py to include
c.NotebookApp.terminado_settings = {'shell_command': ['/bin/bash', '--login', '-i']}
The shell_command should be an array of three strings. See https://github.com/jupyterlab/jupyterlab/issues/4042
2. Your id or your shell
Check these right after you launch the terminal
$ whoami
$ echo $SHELL
to see you have the right user and right shell. If your user is not right, it is expecting the .bashrc in a different user's home directory. If your shell is not right, e.g., /bin/sh instead of /bin/bash (which in fact are often hard-link of each other), it will not read .bashrc
If so, try to see if your $SHELL env variable as seen by Jupyter is correct. Jupyter should use that if you didn't specify shell_command as above
3. Jupyter may be giving you a non-interactive shell
If your bash really doesn't read your .bashrc, it may be invoked as non-interactive shell (I don't know how). To check you can try run this:
$ ls
$ !!
The first ls command can be any command. The second !! is to use bash's history expansion to recall the last executed command. If will not substitute if it is not an interactive shell.
I don't expect that and I don't know how to fix if this happens.
I have the very same problem when configuring JupyterLab (similar to JupyterHub) as a Systemd-Service.
First Solution
(Please first try the second solution.)
We can address the problem by change the default configuration in jupyter_notebook_config.py (as one of the comment and answer said, but the conclusion/solution is just the reverse.)
The related comment:
The file jupyter_notebook_config.py is located at $HOME/.jupyter/. If it does not exist, it can be generated by running:
jupyter lab --generate-config
After this file is located, we modify the content as follows:
# This is for Jupyter Notebook
# c.NotebookApp.terminado_settings = {'shell_command': ['/bin/bash']}
# This is for JupyterLab/JupyterHub
c.ServerApp.terminado_settings = {'shell_command': ['/bin/bash']}
Notably, the options '--login', '-i' mentioned in above comment and answer prevent the terminal loading .bashrc.
Without these options, the shell looks like (which is expected):
(base) [ml#soc3 /]$ python --version
Python 3.9.5
While with these options, the shell looks like (not initilized with .bashrc):
bash-4.2$ python --version
Python 2.7.5
Second Solution
create or edit the ~/.bash_profile file to automaitically load ~/.bashrc:
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
After reading more about login and interactive shell, I found that the default behavior of Jupyter's terminal is login and interactive, and it will source the ~/.bash_profile if the file exists (usually, it will load the ~/.bashrc file). My problem is that I created a new user for running JupyterLab, while the default ~/.bash_profile is not created for this user, and hence ~/.bashrc will not be sourced. Furthermore, I have previously run JupyerLab with root user, which has the mentioned configuration files, thus the JupyerLab terminal works well.
I think it is more sounded. Though the first solution works, why it works is not clear to me.

ROS installation: no such file or directory

According to ros wiki, to set up environment,
I typed
echo "source /opt/ros/kinetic/setup.bash" >> ~/.bashrc
source ~/.bashrc
The error is
/opt/ros/kinetic/setup.bash:.:8: no such file or directory: /home/pikashun/setup.sh
In ~/.bashrc file, there is the source /opt/ros/kinetic/setup.bash line.
I use Ubuntu on WSL.
How can I improve?
Thank you!
I had the exact same issue. The problem is not due to setup.bash either ~/.bashrc but the shell that you are using. It turned out that you may be using a different shell than bash (i.e., zsh). When you are executing the setup.bash of ROS, zsh interprets the following command (whici is in /opt/ros/kinetic/setup.bash) differently:
_CATKIN_SETUP_DIR=$(builtin cd "`dirname "${BASH_SOURCE[0]}"`" > /dev/null && pwd)
It is setting the _CATKIN_SETUP_DIR to your user directory. That is why you are getting error, cause you using the wrong path:
/home/user/setup.bash instead of /opt/ros/kinetic/setup.bash
To check whether this is the issue of your problem, you can check the shell that you are using by execute the following in the terminal:
echo $0; echo $SHELL
It may return something like:
zsh
/bin/zsh
To switch from zsh to bash, use:
exec bash
Once done this, you can use source without any problem.
And to switch back to your previous shell (assuming that is zsh), just use:
exec zsh
The file /opt/ros/kinetic/setup.bash does nothing but loading /opt/ros/kinetic/setup.sh from the same directory. I might be that you are not running bash (check which terminal you run), or that WSL has some different behavoiour than expected.
However, your can just alter your append command like so:
echo "source /opt/ros/kinetic/setup.sh" >> ~/.bashrc
or in your case, since the entry exists already in your ~/.bashrc, edit the line source /opt/ros/kinetic/setup.bash to source /opt/ros/kinetic/setup.sh
The packages or files were not actually downloaded from the "http://wiki.ros.org/melodic/Installation/Ubuntu". To overcome this error first open terminal
check your directory pwd. If your directory is like /home/'Your PC Name' it won't actually work.
Change the directory : Type cd /
Continue the installation process from start which mentioned in "http://wiki.ros.org/melodic/Installation/Ubuntu"
melodic can change to kinetic or other version if you wish

How can I debug $PATH?

There is a directory in my $PATH that I want removed.
But I cannot figure out how it got there.
I've looked at all the places I can think of where $PATH gets set: .profile, .bashrc, .bash_profile, et cetra
but I cannot find who is putting this particular directory into $PATH.
Clearly, I do not know all the things that change $PATH when my system starts.
Is there a way to debug the startup sequence?
Ideally I just want to set a trap on anything that touches $PATH.
Or may there is a log file (or ordered set of log files) I can scan.
How can I find how each directory gets set in $PATH among all the things that run when my system starts?
There are two ways to do this:
Try bash --login -x in a terminal window. This will print every line of the setup scripts as they are executed (kudos go to kojiro).
Alternatively, you could add set -x near the top of /etc/profile or $HOME/.profile. The danger here is that if you make a mistake, your system may become unusable (if you can't start a new shell anymore) plus you need to be root. If you want to try this, I suggest to create two terminal windows, keep them open at all cost, make the changes and then start new terminal windows to see the effects.
Use grep -r PATTERN / (replace PATTERN with the path that you look for). That should search your whole hard disk for this pattern and can take a long time. Maybe start with your home directory. If you want to search just the . files, use this trick: grep -r PATTERN .??*
If you are using BASH, the way the login loading works is this order:
/etc/profile is first read in.
$HOME/.bash_profile is read in.
If $HOME/.bash_profile doesn't exist, then $HOME/.bash_login is read in.
If $HOME/.bash_login doesn't exist, then $HOME/.profile is read in.
NOTE: That $HOME/.bashrc is not read in by default. However, many people do source in their .bashrc file at login.
When a shell is invoked, and it's not a login shell, then the $HOME/.bashrc file is loaded.
By default, the Mac's PATH is /bin:/usr/bin:/usr/sbin:/sbin. This is set via /etc/profile which executes /usr/libexec/path_helper. This takes the initial paths from /etc/paths.d/... and from /etc/paths. The /etc/paths.d only adds in the /opt/X11/bin directory if X11 is installed. Otherwise, /etc/paths is used and it contains the default paths.
Mine is set to:
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
I use /usr/local/bin for third party tools. or newer versions of already installed tools. For example, /usr/bin/svn is version 1.7.17 while /usr/local/bin/svn is set to version 1.8.10. Me invoking svn will invoke the version of Subversion I installed, and not the native version.
In this case, the 1.8 version of Subversion is actually installed in /opt/subversion/bin/svn, but I create a symbolic link to it in /usr/local/svn. I do this for any tool that I install: The tool gets installed in /opt and I link the binaries and scripts to /usr/local/bin, so they're in my $PATH.
Place these 2 lines at top of your ~/.bash_profile (create it if it doesn't exist):
set -o functrace
trap '[[ "$BASH_COMMAND" == *" PATH="* ]] && echo "$BASH_COMMAND"' DEBUG
Then exit the current shell and start a new shell.
It will print every time PATH variable is set in your environment.

~/.profile, ~/.bashrc, and ~/.bash_profile not running on new terminal start up

I am trying to create a permanent alias for my terminal. I put the alias in my ~/.profile, ~/.bashrc, and ~/.bash_profile files, previously empty. When I start a new terminal, bash does not recognize the alias, but if I source any of them, it does. Why are these not getting run when I open a terminal? I am on OSX.
Newer MacOS versions use zsh as the default shell for both Terminal and iTerm2. Run echo $SHELL to confirm if this is the case for you.
Zsh looks for a .zshrc file upon shell startup, so to continue using zsh while sourcing the contents of your bash profile, you can run the following:
echo "source ~/.bash_profile" >> ~/.zshrc
Open a new terminal window for the changes to take effect.
Two things need to happen here when using iTerm to get the loading of dotfiles to work.
First you should add the following to your .bash_profile
[[ -s ~/.bashrc ]] && source ~/.bashrc
Secondly you will need to ensure that in iTerm preferences your terminal is set to launch a login shell.
Hope this helps!
Using the default mac terminal, what worked for me was to add a command to run on start up to source my .bash_profile.
Preferences > Profile > Startup > Add command 'source ~/.bash_profile'
Mac terminal preferences window screenshot
Might be considered to be a bit hacky, but it does the trick.
Adding source ~/.profile to my .bash_profile worked for me.
As of High Sierra, both Terminal and iTerm want to load ~/.profile first. So I suggest you put one line in your .profile to make your Mac work like other Unixes:
source ~/.bash_profile
By editing this one file, you won't have to search through the menus of multiple apps to override Apple's bizarre behavior in each.
As of Catalina the default shell is now zsh. You can change it back to bash with chsh -s /bin/bash and that should load your .profile or .bash_profile
Why are your shell's initialization files not loading?
As with most things, It Depends ™
I recently experienced the same phenomenon and went through the following exercise to resolve it:
I use iTerm. iTerm runs a login shell by default. Verify in iTerm Preferences > General > Command > (*) Login Shell
Therefore, I know that ~/.bash_profile will always be called.
Knowing that, I put the following in my ~/.bash_profile file:
for file in ~/.{bashrc,bash_exports,bash_aliases,bash_functions}; do
[ -r "$file" ] && source "$file"
done
unset file
Notice that I use separate files for .bashrc, .bash_exports, etc. It keeps things separate and simple.
Note also that /etc/profile is loaded first, but since I have never used that system wide init file, I knew that that was not my problem. For details check out $ man bash
So, I started with my ~/.bash_profile file.
I found that when I installed Canopy Express that it's installer replaced the contents of my ~/.bash_profile file with the following content:
# Added by Canopy installer on 2017-04-19
# VIRTUAL_ENV_DISABLE_PROMPT can be set to '' to make the bash prompt show that Canopy is active, otherwise 1
alias activate_canopy="source '/Users/lex/dev/python/User/bin/activate'"
# VIRTUAL_ENV_DISABLE_PROMPT=1 source '/Users/lex/dev/python/User/bin/activate'
p.s. Canopy is an excellent, free python IDE, that I highly recommend.
Fortunately, I backup my ~/.bash* files so restoring that was easy and quickly fixed my issue.
My advice would be to understand the order of calls to your initialization files and start with the first one and work your way through them until you find the problem.
Oh, and you may want to verify which shell you are using (I use bash):
~ $ echo $SHELL
/usr/local/bin/bash
I am guessing you may use another shell, such as bash, tcsh, sh, zsh etc.
Put source .bash_profile into your appropriate 'bashrc' file will make the auto loading recovered, i.e.
.login for tcsh, .bash_profile for bash, .zshrc for zsh
My issue was solved by unchecking Preferences > General > tmux >
Use "tmux" profile rather than profile of the connecting session
Most likely, you need to create the files yourself as they appear not to exist by default. You should give them execute permission to make them run.
~ % sudo chmod 700 ~/.bash_profile
Also, you should check the ownership of the files. They should belong to current user rather than root. Otherwise, you will get permission denied error.
~ % ls -a -l
~ % sudo chown <user_name> ~/.bash_profile
Finally, please note that bash looks in your home directory for .bash_profile, .bash_login, and .profile in order. Bash will stop looking if the first is found.
This means if you have both .bash_profile and .profile files, the .profile will not run.
For more information
Hope this would help you.
Little late to the party but it seems that the file .zprofile is the equivalent to that of .bash_profile when loading zsh. I used this instead to execute a few commands on startup. Of course this only valid for a specific iTerm setup with zsh.
https://zsh.sourceforge.io/Intro/intro_3.html

How do I get the .profile file to work on Solaris machine?

This has been frustrating me for two days and it seems like it should be a very simple thing. I was just created an account on a Solaris machine. Sun OS 5.10 I believe.
The default is Bourne shell which I don't want. I did a cat /etc/shells which results in:
/bin/sh
/sbin/sh
/bin/ksh
/usr/bin/ksh
Looks like Korn shell is all I can use.
I created a .profile file and wrote:
export SHELL=/usr/bin/ksh
Then I did a env and it looks like /bin/sh is still listed as my shell. I logged off, logged back on and now I get:
-sh: SHELL=/usr/bin/ksh: is not an identifier
I've tried adding #!/usr/bin/ksh at the beginning of the .profile. That didn't work. I've tried adding a semicolon at the end of the export. That didn't work. I've tried: SHELL=/bin/ksh and that didn't work either.
My end goal is to get this environment to a point where I can operate productively. I'm used to BASH where I have tab-completions, up-arrow for history, etc and this Bourne shell doesn't have any of that and it frustrates me to no end.
I know this must be simple but all my Googling comes to no avail. Can someone help me?
/etc/shells is not a standard Solaris file, you probably shouldn't rely on its contents.
On the other hand, bash is part of the default Solaris 10 installation. It should already be present as /bin/bash (/usr/bin/bash actually but /bin is a symlink to /usr/bin anyway).
If bash is not there, you might want to ask to the administrator to install the SUNWbash package from the Solaris_10/Product directory in the installation media.
Then, to update your shell, the regular way is to have the shell defined for your account updated. If it is local, that's the last field in your /etc/passwd entry.
Alternatively, you might use that hack at the end of your .profile:
[ ! "$BASH_VERSION" -a -x /bin/bash ] && SHELL=/bin/bash exec /bin/bash
In descending order of preference
ask the sysadmin to install bash and update /etc/shells and update your login shell
see if the chsh program is installed that will allow you to change your own login shell
ask the sysadmin to change your login shell to /usr/bin/ksh
modify your ~/.profile:
if type [[ >/dev/null; then
: # this is ksh
else
# not ksh
export SHELL; SHELL=/usr/bin/ksh
exec $SHELL
fi

Resources