GraphLab Installation Issue - path

I am trying to install GraphLab on windows 10, however towards the end of the installation I receive this error:
Unable to activate conda environment "gl-env":
Deactivating environment "C:\Users\mbaco\Anaconda2"...
Activating environment "C:\Users\mbaco\Anaconda2\envs\gl-env"...
The input line is too long.
"PATH_NO_SCRIPTS=C:\Users\mbaco\Anaconda2\envs\gl-env;C:\Users\marc\Anaconda2\envs\gl-env\Scripts;C:\Users\marc\Anaconda2\envs\gl-env\Library\bin;C:\Usersmarc\Anaconda2;;C:\ProgramData\Oracle\Java\javapath;C:\Program
Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS
Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
............ ETC" was unexpected at this time.
Any help in solving this would be much appreciated!

You need to reduce the length of your system path variable. Delete paths not in use to make the path variable has length shorter than 2047 characters.

Related

Warning: Could not find Lua 5.3 in PATH - When Trying to Install Gumbo library with Luarocks

When writing luarocks install gumbo
In the location/directory of my luarocks file in cmd, I am getting the following error
Warning: Could not find Lua 5.3 in PATH.
Modules may not install with the correct configurations. You may want to specify the path prefix to your build of Lua 5.3 using --lua-dir
Installing https://luarocks.org/gumbo-0.5-1.src.rock
Error: Failed finding Lua library. You may need to configure LUA_LIBDIR.
I've added lua53.exe to the same directory, and added the file both to my user variables and system variables in control panel.
Not sure if worth mentioning, but when running lua53.exe and trying to use luarocks install gumbo from there,
the lua53 cmd-like window responds with stdin:1: syntax error near 'install'
I was hoping to do some web scraping with lua, and later on building a World of Warcraft addon that utilizes gumbo to show certain helpful information within the WoW client, but I can't seem to even get the most basic stuff to work...
Setting up LuaRocks on Windows is annoying and I'm not familiar with it myself. If you added both the LuaRocks and Lua 5.3 Windows binaries (Executables and Includes) to your Path system variable:
luarocks path prints the commands for setting up the LUA_PATH and LUA_CPATH system variables.
The config.lua file tells you what your variables.LUA_LIBDIR value is. You can check it with luarocks config. For me that file would be in:
C:/Users/Ketho/AppData/Roaming/luarocks/config-5.3.lua
otherwise you can create an empty file there and put in this line to point it to wherever your Lua folder is:
variables.LUA_LIBDIR = "C:/lua-5.3.5_Win32_bin"
variables.LUA_INCDIR = "C:/lua-5.3.5_Win32_bin/include"
As for using gumbo to show information within WoW, the addon environment is sandboxed. Unless you meant you just want to get the data to hardcode into your addon.

Installing a driver in NSIS script

I'm trying to create an NSIS installer that installs an inf file. The inf file is extracted from the installer to the correct place, and then I use:
nsExec::ExecToLog '"$SYSDIR\PnPutil.exe" /a "$INSTDIR\driver\xser.inf"'
However, the command does not seem to get executed at all - the install log doesn't print anything - not success nor failure. I've checked thoroughly the command line and it points to the right PnPutil path. I've also checked that it's being run with administrator privileges and it also looks correct. Replacing PnPutil.exe with a different executable in the System32 directory also seem to work without any problem. What am I missing here?
If this only happens on 64bit systems you can try to disable FS redirection around the call to nsExec::ExecToLog by using the macros in x64.nsh:
!include x64.nsh
${DisableX64FSRedirection}
nsExec::ExecToLog '"$SYSDIR\PnPutil.exe" /a "$INSTDIR\driver\xser.inf"'
${EnableX64FSRedirection}

Resolving Address Space is already occupied error using Cygwin and Ruby

I keep getting the same type of error messages and I have really done all I can to get rid of them. The message is as follows, only the module can vary at times:
ruby 5740 child_info_fork::abort: address space needed by 'date_core.so' (0x600000) is already occupied
These messages occur at various times when trying to run Rails, such as “rails console”.
I am running the following environment:
Windows 7 Ultimate 64-bit
Cygwin Net using setup 2.774 (installed from Internet mirrors)
Ruby 1.9.3p392
Rails 3.2.11
I have taken the following steps attempting to fix this:
Deleted all BLODA and restarted, including Norton 360 and Malwarebytes. (BLODA is Big List of Dodgy Apps.)
Deleted and reinstalled Cygwin.
Executed “rvm implode” and rebuilt the RVM and Ruby on Rails environment.
Used CMD & ASH to run “peflagsall” & “rebaseall”. Ran “rubyrebase”. Restarted.
Used FIND to build a file of all *.so & *.dll files. Ran “rebase -T”. Restarted. This has also been done using the “-b 0x77000000” switch.
Used same file to create “to_peflags” script issuing peflags against each individual file. Restarted.
All repair attempts have been futile. At times, “rebase -si |grep ‘*’” would be clean. Any attempt to run “rails console” or similar commands results in Address Space Occupied messages. Subsequent “rebase -si” would then again show conflicts.
I have been trying to run “peflags” against the Ruby modules, but I only get “skipped because could not open” error messages there. File permissions and ACL both show correct permissions. The same error occurs whether or not Administrator is used.
This is pretty frustrating. I would like to fix my current environment, but I am considering moving to MSYS or SFU, but I don’t know if either of those are decent options. I am also considering going native UNIX, but I’ll leap off the cliff when I get to it.
For now, does anyone have a fix for this specific error for me? Thanks…
I have used procexp to monitor "rails console" execution. Bash is calling cmd.exe to run the rails.bat file. Cmd.exe runs in ASLR mode. Used Microsoft EMET 3.0 to turn off mandatory ASLR and bottom up ASLR for both bash and cmd. Cmd.exe still runs in ASLR mode. It must be compiled that way.
Updated registry to set HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages to 0, -1 then 1. 0 caused system problems. -1 had no effect. 1, which was supposed to be the default, helped somewhat as long as EMET changes were in place. But, it was unreliable as Address Space Occupied would eventually recur.
Decided to attempt to install a command processor that either didn’t require ASLR or allowed me to disable it using PE flags. I installed TCC/LE and attempted to get Cygwin Bash to use it to process .bat files. I tried using the path variable, the COMSPEC variable and changes to batfile and cmdfile in the registry all to no effect. Cygwin Bash must either have it hard coded or some nonobvious control.
My fix is to replace my environment. I know I will eventually migrate to some Unix, but for now I am converting to MinGW/MSYS and RubyStack. All I want to do is to get a stable RoR (Ruby on Rails) environment running for today. I don’t see that happening using Cygwin with Windows 7 Ultimate. I keep running into too many problems and this one is a very, very tough nut to crack. Thanks…

Windows x64 RabbitMQ install error with Erlang environment var (ERLANG_HOME)

I'm ask/answering this question because it hung me up & it's likely someone else will have the same problem.
Install of RabbitMQ x64 v2.8.6 on Windows Server 2008 x64.
After Erlang install using default install location to C:\Program Files\erl5.9.2, I'm attempting to start the server via running the rabbitmq-service.bat. Fail:
Please either set ERLANG_HOME to point to your Erlang installation
or place the RabbitMQ server distribution in the Erlang lib folder.
Problem is the .bat file does not have the correct subpath. with 5.9.2 (R15B02) version of erlang. My ERLANG_HOME directory is set correctly, but the script does not use it correctly for this version of Erlang, which, it appears to this Erlang noob to have a new subdirectory called "erts-5.9.2" which is causing the problems. Maybe someone intimate with these scripts can describe how to make this work correctly without the hack workaround I'm about to describe?
1- Set environment variable:
Variable name : ERLANG_HOME
Variable value: C:\Program Files (x86)\erl6.4
note: don't include bin on above step.
2- Add %ERLANG_HOME%\bin to the PATH environmental variable:
Variable name : PATH
Variable value: %ERLANG_HOME%\bin
This works well.
There are several RabbitMQ control .bat files on windows. Every one you use needs to get changed to reflect the Erlang path correctly. In this example, I'm editing the rabbitmq-server.bat because it's one of the easier ones... any of the .bat files you want to run will need this hack to get them to work, with the rabbitmq_service.bat file being the most involved to adjust.
editing that rabbitmq_server.bat file, you can see on about line 48 or so there's a check to see if the erl.exe is found, but the path isn't correct:
if not exist "!ERLANG_HOME!\bin\erl.exe" (
that path does not match the file structure for the 5.9.2 version of Erlang. I fixed this by simply removing this path check from about line 48 to 58, then, where the .bat actually makes a call to the erl.exe on about line 129 which reads:
"!ERLANG_HOME!\bin\erl.exe"
I simply hardcoded the path to my erl.exe:
"C:\Program Files\erl5.9.2\erts-5.9.2\bin\erl.exe"
With the pathing correct, the rabbitmq .bat files will run.
I had the similar issue, modifying ERLANG_HOME in .bat files did not work. Then I tried echo %ERLANG_HOME% in command prompt, that did not print the environment variable value(I could see that ERLANG_HOME environment variable has been created under advance system settings), that lead me to believe that I need to restart server for 64 bit installation of Erlang. After rebooting server, It worked like a charm. I hope this helps someone.
Just to share an up-to-date answer as of 2019: On Windows Server 2019, after setting up the environment variable, a restart is required to solve the problem.
I got into same kind of problem.
I solved it by doing three changes as given below.
Update Path variable "ERLANG_HOME" : "C:\Program Files\erl8.0" in Environment Variables.
Upadte "Path" variable "Path" : ";%ERLANG_HOME%\bin;"
Give urself FULL CONTROL permissions over "Program Files" in C drive.
It worked for me in this way.
This problem still occurs in Erlang 18.3 (erl7.3) and RabbitMQ 3.6.9 on Windows when upgrading from any older version of RabbitMQ to version 3.6.9. The solution as already stated here is to manually set ERLANG_HOME with 'setx -m ERLANG_HOME "C:\Program Files\erl7.3"' before starting the service.
What happens is that the RabbitMQ 3.6.9 installer removes the environment variable ERLANG_HOME from the system while removing the older version of RabbitMQ. Then, when it proceeds to the installation step, it does not put back the ERLANG_HOME variable. Then, the batch files that start up RabbitMQ cannot find Erlang. They try to find Erlang's home directory using "where.exe" but it always fails after an upgrade.
RabbitMQ's installer also does not kill all of the Erlang background processes, causing many of its files to be undeletable due to the Windows "file in use" problem. This leaves behind "files in use" in %APPDATA%\RabbitMQ and "C:\Program Files\RabbitMQ." These processes are "erl.exe," "erlsrv.exe," and "epmd.exe." The RabbitMQ installer should taskkill these processes after shutting down the RabbitMQ Windows service.
RabbitMQ is rather clunky on Windows.
Download Erlang or OTP - Only one Version of OTP should be installed
Download RabbitMQ installer
Install both exe file as Administrator
Set class path for Erlang. (Setting classpath is a bit troublesome, so follow these steps)
Set a new path with name ERLANG_HOME and value C:\Program Files\erl-23.1 (do not copy bin folder here)
Edit System "path" and add %ERLANG_HOME%\bin
Go to Start - Open rabbitmq command promt and run
rabbitmq-plugins enable rabbitmq_management
Navigate to localhost:15672
Use guest/guest to login
Interesting that this worked for you. There is record of a two bugs in Erl5.9.2 that cause an incomplete installation where %ERLANG_HOME%\bin is not installed.
Either of
* Installed 64bit erlang on 32bit machine
* "The program can't start because MSVCR100.dll is missing from your computer."
https://groups.google.com/d/topic/erlang-programming/wGtFLzapiQ0/discussion
Try 5.9.1 or any other version. They also mention making the future versions of the installer alert you if it fails.
I just had the same problem mentioned here. I installed otp_win64_R15B02 on a Windows 7 machine and everything worked perfectly, but I used the same installer on a Windows 2008 server and the bin directory was not created. I then uninstalled otp_win64_R15B02 and downloaded the otp_win64_R15B02_with_MSVCR100_installer_fix and the bin directory was created.
I suspect the reason it worked on my Windows 7 system is that I have Visual Studio installed and the required libraries were already available which allowed the otp_win64_R15B02 installer to work correctly.
Oh, and if you're installing Erlang to run RabbitMQ the RabbitMQ install will succeed with the broken installer but installing otp_win64_R15B02_with_MSVCR100_installer_fix after RabbitMQ will not work, just un-install and re-install RabbitMQ to resolve this.
Just give C:\Program Files\erl10.6\ not C:\Program Files\erl10.6\bin\erl.exe in the environment variable. If you open the server.bat file I came to know the issueenter image description here
I think this is encoding issue on windows.I see a correct value but I write echo %ERLANG_HOME% on console the value come with question mark. These steps fix it.
1.go environment variable window
2.edit ERLANG_HOME item
3.copy the value, open notepad and paste there
4.copy again on notepad and paste to edit window
5.apply and exit window
6.close command line tools and reopen
7.run rabbitmq bat file.
I solved it in a quick and dirty way,without naming path variables
I've opened the bat file and replaced every occurrence of
!ERLANG_HOME!\bin\erl.exe
with hard coded path for example might be diffrent path for you because of diffrent version
C:\Program Files\erl10.3\erts-10.3\bin\erl.exe
and replaced
%RABBITMQ_HOME%\escript\rabbitmq-plugins
with
C:\Program Files\RabbitMQ Server\rabbitmq_server-3.7.14\escript\rabbitmq-plugins
Even I was this problem. The issue was the environment variable ERLANG_HOME=c:\Program Files\erl9.0 which was never existed.
I cross checked the path. The correct path was c:\Program Files\erl9.3.
After correcting the
ERLANG_HOME=c:\Program Files\erl9.3
the problem solved. So, definitely it is a path issue.
In my case, it should be installed erlang using admin role running
If above solutions doesn't work for you then you can try following
Find another compatible version of erlang for your rabbit mq e.g. for rabbit 3.7.x erlang version 20.3.x to 22.0.x all are compatible .
Right click newly downloaded erlang version and from properties select the option to unblock the file .
Run the erlang with admin persssion .
Re run rabbit mq exe

The system cannot find the path specified when starting Ruby and Rails command prompt

I just started learning rails a week ago and everything worked until today. Now when I start the Ruby command prompt, it says:
The system cannot find the path specified.
# Under Rails Environment Configuration.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
---
The paths for ruby and rails show up correctly.
I'm using Windows Vista 32-bit. Any help would be greatly appreciated, thanks!
You've probably used "Ansicon" - a program to get the colors in windows prompt right. If you installed it permanently with -i parameter and consequently moved/deleted its directory, it would lead to this error. (I've just experienced it)
The solution is to renew the location of the ansicon data files or to remove the following registry entry:
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
You can find more on this issue at http://carol-nichols.com/2011/03/17/the-system-cannot-find-the-path-specified/
Good luck!
I had the same problem in Windows 7 and solved it by adding Git/bin directory to the system path variable (found the answer here). Hope this helps someone!
None of the answers above helped me. My issue was whenever i typed rail -v it gave me the same error. I had to install rails, i used the following command:
gem install rails --no-document
you can check out the following installation steps to get around the error:
http://docs.railsbridge.org/installfest/windows

Resources