I'm following the instructions from various Wikis on how to compile Node so I can eventually get it running as a service on Windows.
My steps so far:
https://github.com/joyent/node/wiki/Installation
(which lead to...)
http://blog.tatham.oddie.com.au/2011/03/16/node-js-on-windows/
(successfully compiled via cygwin, but lead to...)
https://github.com/joyent/node/wiki/Building-node.js-on-mingw
(which apparently is better than the so far successful cygwin compile)
So - I've managed to compile Node.exe using Cygwin but not the preferred Mingw. I concur this isn't an ideal situation, building on Windows isn't the ideal. Nevertheless.
The error I see in Mingw, once I've followed all of the steps above, occurs when I try to ./configure --without-ssl. The error message is:
Danjah#PC /c/cygwin/home/Danjah/node-v0.4.7/node
$ ./configure –without-ssl
/usr/bin/env: python: No such file or directory
I understand from step 3's URL, that I must take steps to provide the environment variables for both Python and Git - using help from the provided URL I managed to input the Python path var, but I don't think I have the Git path var right. Either way, in no install directories for Python, Cygwin or Mingw32 do I see the path specified in the error msg: "/usr/bin/env".
Googling didn't really bring much to the table in terms of env variables or Mingw32, best I got was: PATH=C:\MinGW\bin;C:\MinGW\msys\1.0\bin where my install directory is at C:\MingW\.
The path I added to Windows environment vars for Python was: PythonPath=C:\Python27;C:\Python27\DLLs;C:\Python27\Lib;C:\Python27\Lib\lib-tk where Python 2.7 is installed in C:\Python27\.
I hate it when a file path stops you from doing things, as I suspect is the problem here. So please set me straight here - is it a file path problem I have or something else? And if its something else, please try and help me to get Node up and running... keen as to get experimenting.
I should probably also mention that I do also have a previously installed version of Git on my Windows XP SP3 machine, but had not previously had Cygwin, Mingw32 or Python installed, and I do not have IIS running as a service - my usual testing environment is a WAMP stack.
Windows uses the PATH environment variable to locate programs that are invoked without a fully qualified file path, i.e. 'python' rather than 'C:\Python27\python'.
So you need to add python's home directory to the Windows PATH variable, as well as MinGW, git and anything else your script requires.
Also by setting the PATH variable explicitly in your shell session or script, you are overwriting its original contents (in the local context) which limits which programs your shell can find to only those available within the PATH which is usually a bad idea.
See http://www.java.com/en/download/help/path.xml for details on modifying your PATH so you can always run your Python scripts from the command line.
Related
The error I was originally getting was that wsl was not able to find JAVA_HOME. After I ran the command
export JAVA_HOME="/mnt/c/Program Files/JAVA/jdk-15.0.2"
And now the error it gives me is:
ERROR: JAVA_HOME is set to an invalid directory: /mnt/c/Program Files/Java/jdk-15.0.2
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
When I run
${JAVA_HOME}
to check the variable I get the response
bash: /mnt/c/Program: No such file or directory
Which I believe is due to the space in the file name. Online it said that the space shouldn't be an issue as it is enclosed in quotes so I don't know what to do here.
Any help would be appreciated!
It looks like you are trying to use the Windows version of Java from within WSL. That should be possible, but you are currently exporting a Linux-style path, which the Windows version won't handle (as you can see).
If you have both the Windows and Linux version of Java installed, then see this answer for some related information. The question there is about npm, but the core issue is the same -- The Windows version is getting picked up in the path before the Linux version.
If you just have the Windows version, then at least modify the JAVA_HOME to be 'C:\Program Files\JAVA\jdk-15.0.2' (watch out for potential quoting issues with backslashes in the Linux-shell string, though). I'm not sure that's going to take care of all of your issues -- I've never tried running the Windows Java version through WSL myself. But it's at least the first step you're going to need to take to get past the current error.
The second error when you just execute ${JAVA_HOME} is to be expected, as you are trying to execute this directory (with a space) as a command. The shell is interpreting the portion before the space as a command, and the portion after the space as the argument. If you were to set it to a directory without a space, you'd still get an error message when trying to execute it (as you are now), just that it would be something like bash: /mnt/c: Is a directory.
If you just want to check it, use echo ${JAVA_HOME}.
I have setup multiple python environment using Anaconda.
Usually, to run a script "manually", I would open a command line and then type:
activate my-env
python path/to/my/script.py
Fine.
Now I am trying to run a script automatically using a scheduler and I was wondering what the difference was between
Writing a batch which activates the environment and the executes the script (like in the snippet above)
Calling directly the python executable from the environment (within the envs/my-enjv/ directory) like below:
/path/to/envs/my-env/python.exe path/to/my/script.py
Both seem to work fine. Is there any difference?
I don't claim to be an expert but here's my 2 cents.
For small scripts, no, there isn't a difference.
You should notice a difference when calling external modules / packages. conda activate alters the system path to change how the command shell searches for the appropriate capabilities.
If you supply a full path to an interpreter and the full path to an isolated script, then the shell doesn't need to do a lookup as this has priority over the path. This means you could be in a situation where the interpreter can see the script but cannot see dependencies.
If you follow the conda activate process, and the environment is correctly packaged, then the shell will be able to trace any additional resources.
EDIT: The idea behind this is portability. If an admin has been careful in setting up a system, then scripts should have the appropriate visibility - i.e. see everything in it's environment plus everything in the main system installation.
It's possible to full-path every call to an interpreter and a script or package location, but then what happens when you need to move it to another machine? You would need to spend a lot of time setting everything up exactly as it was before. On the other hand, you can follow the package process and the system path will trace everything for you.
Simply checkout the PATH variable in your environment. After conda activation it has been extended by
\Anaconda3;
\Anaconda3\Library\mingw-w64\bin;
\Anaconda3\Library\usr\bin;
\Anaconda3\Library\bin;
\Anaconda3\Scripts;
\Anaconda3\bin;
This doesn't make much of a difference, if you are just using the standard library in your code. However, if you rely on external packages like pandas, it's a prerequisite so that the modules can be found.
I have an application development server that is automatically updated every night with a massive shell script that we run with crontab. The script specifies #!/bin/sh at the top of the file and I am not able to change that. The basic purpose of the script is to go through the machine and download the latest code in each of the directories that we list in the script. After all of the repositories are updated, we execute a number of scripts to update the relevant databases using the appropriate virtual environment (Django manage.py commands) by calling that virtualenv's python directly.
The issue that I am having is that we have all the necessary Sphinx plugins installed in one of the virtual environments to allow us to build the documentation from the code at the end of the script, but I cannot seem to figure out how to allow the make command to run inside of the virtualenv so that it has access to the proper packages and libraries. I need a way to run the make command inside of the virtual environment and if necessary deactivate that environment afterwards so that the remainder of the script can run.
My current script looks like the below and gives errors on the latter 3 lines, because sh does not have workon or deactivate, and because make can't find the sphinx-build.
cd ${_proj_root}/dev/docs
workon dev
make clean && make html
deactivate
I was able to find the answer to this question here. The error message that is shown when you attempt to build the sphinx documentation from the root is as follows, and leads to the answer that was provided there:
Makefile:12: *** The 'sphinx-build' command was not found. Make sure
you have Sphinx installed, then set the SPHINXBUILD environment
variable to point to the full path of the 'sphinx-build' executable.
Alternatively you can add the directory with the executable to your
PATH. If you don't have Sphinx installed, grab it from
http://sphinx-doc.org/. Stop.
The full command for anyone looking to build sphinx documentation through a cron when all tools are installed in various virtual environments are listed below. You can find the location of your python and sphinx-build commands by using which while the environment is activated.
make html SPHINXBUILD='<virtualenv-path-to>/python <virtualenv-path-to>/sphinx-build'
I just installed python 2.7 on a windows machine to start SimpleHTTPServer in order to test my d3.js code.
Normally on my linux laptop I would start a terminal window in the folder where my files are (index.html, data.json, etc). However, if I do the same on windows it doesn't work.
The only way to make this works is when I run python -m SimpleHTTPServer 8000in the python installation folder (in my case C:\Python27).
I read here that I need to set the python environment variable. The screen shows what I have done. As you can see I set the variable both locally (for the current user) and system-wide. However, when I try to run a pythoncommand out of the installation folder nothing changes.
The python variable is incorrect - rather you should add the python executable path to the PATH environment variable e.g.
PATH=C:\Python27\;C:\Python27\Scripts;
You should then be able to call python from anywhere.
Indeed any path you include in the PATH will then allow you to call executables in that path without specifying the full path or extension.
i.e.
C:\Python27\python.exe becomes python
C:\WINDOWS\system32\cmd.exe becomes cmd
For more detail see: https://en.wikipedia.org/wiki/PATH_(variable) or my answer to this question: Error in Process.Start() -- The system cannot find the file specified
Yt works early.when I try to use gcc commend it show me. I already uninstalled and re-installed gcc 4.8.
this is error:
as.exe - entry point not found
the procedure entry point __printf__ could not be located in the dynamic link library c:\mingw\bin..\lib\gcc\mingw32\4.8.1\..\..\..\..\mingw32\bin\as.exe"
this is code:
#include <stdio.h>
int main(){
}
I know it's too late to answer, but maybe it can help someone else.
I have just faced this problem, it is solved that change the directory name (in MinGW directory) from mingw32 to mingw32old. Because these two directory has as.exe in their bin directory, so they conflicts, and occures error. However, now it is working,
hope benefits to your problems.
(I'd rather post this as a comment, but I don't have enough reputation yet.)
The error seems to be related to the start of as, not to your code. You can check by running as --help (it should display a long list of options). Assuming this command also fails, continue with reading.
The whole error looks a bit weird, but I guess your issue is caused by multiple conflicting DLLs in your PATH. You should be able to test this hypothesis by going into c:\mingw\bin, clearing PATH completely (set PATH= in the Windows shell; export PATH= in Bash) and trying to execute as --help again. If that helped, you need to identify what program in your PATH is causing this and either remove it from PATH completely, or remember to set a custom, short, non-conflicting PATH everytime you want to use your mingw installation.
Sometimes as.exe can also be sourced from c:\MinGW\msys\1.0\bin\ which might conflict with c:\MinGW\bin\. I suggest to experiment as #DavidMacek did - remove c:\MinGW\bin from PATH and reboot the shell and then type as --help to see if things are fine. If things are fine. Goto your environmental variable and "move up" c:\MinGW\msys\1.0\bin\ above c:\MinGW\bin\ to let msys take precedence.
I just added a path to the as.exe to the system environment variables and it worked.
In my case it was path to the Code blocks gcc compiler on Windows 10:
C:\Program Files (x86)\CodeBlocks\MinGW\bin