I am trying to add to the PATH via the Environment Variable settings windows for python.exe.
I have read the instructions using SetX from the March 3, 2012 discussion about this issue and am worried I will make a mess of my machine, so want to stick with the GUI process.
The directory path is C:\Users\Paul\AppData\Local\Programs\Python\Python37\python.exe.
That is a copy from the addition I made in the System Variables section of the Environment Variables window.
I have labelled the Variable Name as "Python", no quotation marks.
I have checked the path, and it looks good to me, and have rebooted the computer. But I still get the
'python.exe' is not recognized as an internal or external command, operable program or batch file.' error in every directory expect if I am specifically in the Python37 directory.
Any idea what I am doing wrong?
The path environment variable contains one or more paths, separated by semicolons. When you try to execute a command in cmd.exe it checks each path listed in the path variable in order of first to last until it finds the executable or runs out of paths to check.
You can experiment without making permanent changes to your system first. Run cmd.exe and type
set path=%path%;C:\Users\Paul\AppData\Local\Programs\Python\Python37
Running python.exe should now work in any directory in this cmd.exe window.
Unlike other environment variables, path is special and is a merged value from the system and user variables. Since you installed python just for yourself you might as well just use a user variable.
In the system properties where you edit environment variables, if there is no path user variable, create one and set it to C:\Users\Paul\AppData\Local\Programs\Python\Python37 or if it already exists, append ;C:\Users\Paul\AppData\Local\Programs\Python\Python37.
In newer versions of Windows 10 the UI is different and you don't have to add the semicolon because it lets you edit them as separate entries.
Related
I am currently working on a script that uses an executable to perform certain tasks. In order for the script to find the executable file it needs to know the directory on the Windows where the executable resides. So I decided to store the path to the executable into an Environmental Variable and read out it from the script.
So I have 2 options on how to store the info into the environmetnal variables:
Either create my own Environmental Variable $MY_ENV_VAR and assign the path to the executable to it.
Or add the path to the executable directly to the existing $PATH variable of the Windows OS and let the script search through the paths listed in the $PATH to find the executable.
I would like to get to know what are the pros and cons of both approaches and what is the best pratice.
I guess runtime-wise and script-implementation-wise the 1st solution is a faster and simpler one.
However, the script ought to be used by the different users and I would like to go for a more user intuitive / user friendly solution.
When I start my development rails server I get this following message first. To my knowledge WSL2 is a virtual environment.
I would have expected it to now reference a Java directory that resides on my Windows host. Is this likely something I carried over in the project from when I was using WSL1? How would I safely correct this?
/home/daveomcd/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/railties-6.0.3.2/lib/rails/app_loader.rb:53:
warning: Insecure world writable dir /mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath
in PATH, mode 040777
I experienced the same problem when trying to fix the slowness of WSL2. The recommended solution was to move the files from the mounted NTFS drive to the root ext4 filesystem (using \\$wsl\<distroname>), so I did that.
I set up /etc/wsl.conf as below:
# Enable extra metadata options by default
[automount]
enabled = true
root = /mnt/
options = "metadata,umask=0033"
mountFsTab = false
[interop]
enabled = true
appendWindowsPath = true
And ran rails bundle to update dependencies.
Also make sure that your file permissions and owner settings are updated. Hope it helps.
Sorry, I'd love to make this more of a comment to see if I'm on the right track before committing to an answer. However, since there's too much info here for that, I'll make an attempt at getting you an answer here.
While it is a virtual environment, by default WSL provides several "Windows Interop" features that allow it to:
automatically mount Windows drives in /mnt/{c,d,...}
append the Windows path to the Linux path
run Windows executables inside Linux
share Windows environment variables with Linux (although this is not something that happens by default)
I can't be sure (long, long time since I've used Rails), but it looks like something in the app_loader.rb is checking permissions on Java directories in the path. It may be using some logic like "check each path entry and look for a java or java.exe there. If found, check permissions." Or something like that. That means that (2) and (3) above may be confusing it.
You can see this in action with which java.exe, which will likely return a Windows path. Or run notepad.exe, which will launch the Windows Notepad executable from within Linux/WSL (magic! 😉).
These are both very useful features, so I hate to disable them completely, but it's the easiest way to figure out if that's the problem. Create a /etc/wsl.conf with the following contents:
[interop]
enabled=false
appendWindowsPath=false
Exit your WSL instance and then:
(from PowerShell, CMD, or Windows Start) Run wsl --list --verbose to see the name of your distribution (most likely Ubuntu)
Likewise, run wsl --terminate <distro> to terminate that distribution.
Restart your WSL instance
Try running /mnt/c/Windows/system32/notepad.exe (assuming a normal C:\Windows installation) (should fail, since interop is disabled)
Try which notepad.exe (should fail, since the Windows path should no longer be appended to the Linux path)
Try to start your Rails dev server again - Might work (might not, I could easily be wrong about the root-cause here)
If it does work, then you can try to correct the situation with several less invasive methods than disabling those features entirely:
If you plan on only using WSL for your development, then you could remove the Windows JDK.
Or at least remove the Windows JDK from the PATH in Windows.
Or, if you want to keep it installed and in the Windows path, you could have a shell startup file (e.g. .bashrc) that removes it from the path only in WSL. I'll point you to this question which contains multiple techniques for doing so.
Or you could keep the appendWindowsPath=false in your /etc/wsl.conf but then add back in the paths you want manually in your startup config.
I often set java in system environment variable, which will make it accessible in windows cmd, but people won't always have admin access on their computer. When I set the Path environment variable under a specific account. I was not able to use java in windows cmd even if I log in as that account?
Why is it so? And how can I set append any thing to Path permanently without using admin access?
C:\Users\xxx>cygwin
'cygwin' is not recognized as an internal or external command,
operable program or batch file.
My bad, I put cygwin folder under my C:\cygwin, which will make it admin access. After I change the user control to full, it is able to load the cygwin.
So namely,
1. Put admin access program (like C:\Program Files) under your system variable
2. Put local access program (lizhi C:\users\xxx) under your user account variable.
Then it will work as expected.
Thanks
I have a little problem.
I source a script which changes my RedHat environment (PATH, LD_LIBRARY_PATH, etc.i).
When I launch my install with scons, it charges the default Environment from my machine, but not the current that I loaded...
I tried several attempts, but it was not conclusive. Most of the answer on the net are relative to a change on one variable which have to be set in the SConstruct.
How can I tell scons to charge the current Environment, but not the default ?
Thanks in advance !
The SCons way would be to set these environment variables in your SConstruct/SConscripts so that every user would end up with a reproducible build environment.
Take a read of the FAQ for this: http://scons.org/faq.html#Why_doesn.27t_SCons_find_my_compiler.2BAC8-linker.2BAC8-etc..3F_I_can_execute_it_just_fine_from_the_command_line.
SCons does not automatically propagate the external environment used to execute 'scons' to the commands used to build target files. This is so that builds will be guaranteed repeatable regardless of the environment variables set at the time scons is invoked. This also means that if the compiler or other commands that you want to use to build your target files are not in standard system locations, SCons will not find them unless you explicitly set the PATH to include those locations.
Already found the solution after some more search : env = Environment(ENV = os.environ)
My build failed when I had a hyphen in a variable name but succeeded when I changed it to an underscore.
The error was this but I could see in the online Workspace browser that it was valid and as mentioned above it succeeded with an underscore!
15:55:25 + MY-DISTRO=/home/jenkins/workspace/build-prod/my-distro
15:55:25 /tmp/hudson6751264218812911564.sh: line 3: MY-DISTRO=/home/jenkins/workspace/build-prod/my-distro: No such file or directory
What are valid characters for Jenkins variables names and where is this documented?
Judging by the .sh extension of the temporary script in the log you pasted, I assume you used the Execute shell build step in Jenkins - so in this case "valid" variable names mean variables in a linux shell script (the exact shell type might vary based on local configuration) - see for example this thread about allowed names on linux.
In case you have a windows slave, and use the Execute Windows batch command build step, you would of course have to check rules for windows variable names.
Also note that variables used in other places as these and similar build steps could potentially follow completely different rules (though sometimes they overlap). For example: if a plugin uses the Token Macro Plugin for evaluating expressions, you would have to refer to environmental variables with ${ENV,var="VARIABLENAME"}.
Jenkins is java based. Most probably it accepts java variable convention. I suggest avoid using $ in variable names since unix based operating systems treat it differently.
What Atilla said, but avoid dots (.) as well.