I have been tinkering with WSL2 and found out that when trying to use some software, such as gcloud I bump into an annoying inconvenience.
$ gcloud
/mnt/c/google-cloud-sdk/bin/gcloud: 113: exec: python: not found
This happens because the PATH variable in WSL is set by default to include some windows directories. If we examine it, we can find /mnt/c/google-cloud-sdk/bin/gcloud amongst the set directories:
$ echo $PATH | grep /mnt/c/google-cloud-sdk/bin/
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files (x86)/Microsoft SDKs/Azure/CLI2/wbin:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/google-cloud-sdk/bin/:/mnt/c/Program Files (x86)/Microsoft SQL Server/150/DTS/Binn/:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/Docker/Docker/resources/bin:/mnt/c/ProgramData/DockerDesktop/version-bin:/mnt/c/Users/iyid/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/iyid/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin
I can understand why there are some windows directories such as /mnt/c/Program Files/Docker/Docker/resources/bin, or /mnt/c/Users/iyid/AppData/Local/Programs/Microsoft VS Code/bin because I use them, but when gcloud is unusable "out-of-the-box", why include it?
So an ugly fix is to just export a new PATH variable that excludes the gcloud directory, and add this to .bashrc within the user & root home directories. Note that when replacing the path variable, I need to manually set double-quotes " around directories with spaces in it, such as "/mnt/c/Users/iyid/AppData/Local/Programs/Microsoft VS Code/bin", which makes the fix even uglier. What If I install some other software and need to include its binaries in the PATH variable? Should I just pile-up path update instructions in my .bashrc? What If I want to use zsh later-on, and I have to switch all the instructions to .zshrc? etc... All of these questions make this solution purely a "workaround" that involves a lot of maintenance overhead.
Is there a more elegant way to fix this issue?
Related
I’m not root for the linux server,
so I choose to install softwares in my $HOME/local/bin, I already added the $HOME/local/bin directory to the PATH environment variable, wrote in my .bashrc.
Some softwares install this way like:
tar xvzf ncurses-5.9.tar.gz
cd ncurses-5.9
./configure --prefix=$HOME/local
make
make install
cd ..
So it will directly install in my $HOME/local/bin.
But for some softwares, after download like sbt-1.2.1.zip (based on java), and decompression, shows just a file fold sbt, it contains three foldsbin conf lib, and in its bin, contains one executable file named sbt and java9-rt-export.jar sbt-launch-lib.bash sbt-launch.jar sbt.bat.
Here I wonder:
I should just soft link this executable sbt file path under my $HOME/local/bin, then source my .bashrc?
Or, after decompression, add one line in my .bashrc export PATH="downloadpath/sbt/bin:$PATH"?
Since just one executable downloadpath/sbt/bin, so I'm not sure it is right to add whole bin fold path, if software's bin fold contains executable files (one or many), I think this situation is more convenient for just add it's bin in .bashrc, but even so, I'm not sure its right?
I'm not familiar with installation software, now I usually know way
but not why. Here I shows two ways (more ways not be showed here) to
install, executable file always be written in bin or src? But some
softwares no bin just src but no executable files in it...
Slurm also can use modules to install software, conda also other way, but I want to
confirm these traditional ways I mentioned (that two) still can be
used on slurm or conda?
However, any suggestion even one aspect's reminding will be grateful!
For precompiled software, or, in general, software that does not offer configure scripts or (C)make files, it is ofter better to leave them in their target directory and adapt the *PATH (PATH to binaries, but also LD_LIBRARY_PATH, LIBRARY_PATH to libraries and CPATH to include files and MANPATH to the man page) environment variables.
The reason is that the software might be configured to read files with hardcoded paths, relative to the position of the executable, such as libraries, etc.
In your case, you might also need to setup the CLASSPATH env variable to the directory with the jar files.
To ease software installation, you can use tools such as easybuild that can help, and even create user modules just like the system module installed by the system administrators.
There is something wrong in my opinion with your setup. If you don`t have root account on your server, is not better to test what you have to test, in a more safe environment - for example a vm/container on your developement machine ?
However, in your situation maybe it can be better to start sbt by using a separate bash script than modifying your .bashrc
I run a lot of node projects and often have binaries located in:
.\node_modules\.bin
...relative to the projects folder. I'd like to be able to have PATH always include these directories, if they exist. I don't want to include other directories, just the one relative to the current directory. I'm familiar with
Add-PathVariable from PSCX and other Powershell basics, but how do I include a folder relative to the current dir in PATH?
Edit: as mentioned in the question, already, I expect the path to stay updated as the directory changes. This is not simply asking about how to use pwd.
You can use a relative path in Env:PATH and the binaries found will update dynamically:
Eg:
$env:PATH += ';.\node_modules\.bin'
Or with the PowerShell Community Extensions (PSCX):
Add-PathVariable '.\node_modules\.bin'
Unlike using $(pwd) the . is not immediately resolved to an absolute path, so PATH is always relative to the current working directory.
Testing this:
$ which uuid
C:\Users\username\Documents\myapp\node_modules\.bin\uuid.cmd
Then changing directory, uuid now refers to a program in a different dir:
$ cd ..\blog\
$ which uuid
C:\Users\username\Documents\blog\node_modules\.bin\uuid.cmd
It's also possible to persistently change PATH in the user or system environment:
[Environment]::SetEnvironmentVariable(($env:PATH + ';.'), 'User')
or
[Environment]::SetEnvironmentVariable(($env:PATH + ';.'), 'Machine')
Security note: when entering a command Windows will automatically search all directories in $env:PATH for files with one of the extensions listed in $env:PATHEXT and execute the first match it finds. Depending on where exactly in the search path you placed . that may even supersede system executables.
You may want to take a look at how to use package installed locally in node_modules for alternative approaches.
Created a simple debian/ubuntu package with some library files (*.so).
Works fine except, it installs them as default in the root path "/".
Since I've recreated my Makefile to output to $DESTDIR/ instead of "the usual" directory that I provide in the Makefile, when compiling from source, how do I now set the path of where the files should be installed now? I know there are several choices when using dh_make to create the package, "s" being the default one. Still, can't seem to find anything on where to tell dpkg to put the installed files.
Secondly, a Deb Library package containing only ".so" files should still be a "Single binary" since I gather that using the Library is for development purposes? Since this is a library, I just wanna make sure that's not the cause of the files being installed in the wrong location. What I mean is .so files and header files installation?
What I've used:
dh_make -e my#email.com -f ../myfile-1.0.tar.gz
dpkg-buildpackage -rfakeroot
and some configurations set i debian/control, $DESTDIR in Makefile.
Seems that it was fairly simple, yet very confusing. This works, not sure if there is a better solution.
In my makefile I have a few variables
InstallTo = /usr/lib
install:
mkdir -p $(DESTDIR)$(InstallTo)
cp $FILE_TO_COPY $(DESTDIR)$(InstallTo)
This way it will create the directory tree inside the *.deb file. I had some trouble using /usr/local/lib instead of /usr/lib/ and rmdir complained when trying to delete it and it had no files (just directories). Not sure why, but changed it to /usr/lib instead.
Since someone voted this up, I'm guessing someone were also looking for the answer and this is my solution. Perhaps someone can provide a better one if there is one.
Just a note, $DESTDIR variable is the variable that dh_make suggest the user to use in our Makefile. It's the path to where dpkg will build the program and where it will install it so it can be included in the .deb file.
I have msysgit installed in my PC. I want to change the path of / using environment variables. Currently it is pointing to c:\program files\git. How can I change this?
Note: I am able to change path of ~ directory using HOME environment variable. I am looking for similar solution for this.
The software package that installs git bash is similar to Cygwin (I think it may be based on Cygwin, but I'm not sure of that). It's designed to emulate a UNIX-like environment under Windows.
As far as I know, the location of the / directory (referred to as the root directory) is fixed when you install the software. If you want / to refer to a different location in the Windows filesystem, you'll need to reinstall the software and, if possible, specify a different location. It can't be changed by setting an environment variable.
What exactly are you trying to do? There may be some way to accomplish your goal other than changing the location of /.
I have perl installed on a cluster drive at /clusterhome/myperl, and the same /clusterhome directory mounted on a workstation computer at /home/chris/cluster
Running perl obviously works fine from the cluster, but when I run /home/chris/cluster/myperl/bin/perl from my workstation, it can't find any modules. The #INC is still set to
/clusterhome/myperl/lib/site_perl/5.16.3/x86_64-linux
/clusterhome/myperl/lib/site_perl/5.16.3
/clusterhome/myperl/lib/5.16.3/x86_64-linux
/clusterhome/myperl/lib/5.16.3
This happens even with the following environment variable values prepended on the workstation:
PATH /home/chris/cluster/myperl/bin
PERL5LIB /home/chris/cluster/myperl/lib
LD_LIBRARY_PATH /home/chris/cluster/myperl/lib
MANPATH /home/chris/cluster/myperl/man
Is there a way I can get this perl to work on both the cluster and the workstation? I reinstall it often (nightly), so if extra make flags are required, it's totally fine.
The exact installation location (where to look at for module inclusion) is compiled into the binaries of perl. There are other uses for the installation directory name (for example, when compiling new modules, a bunch of compilation options are provided from these compiled-in strings).
So, you have the following options:
you make sure that the files are available on every computer in the directory where they were designed to be (symlinks: ln -s, bind mounting: mount -o bind, or mounting there upfront),
you compile a new perl for every new location.
You may also disregard this compiled-in directory, and specify the directories to be used every time you want to use perl via some command-line or environment variable. For #INC, you can use command-line option -Idirectory.