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.
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.
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.
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)
I've just downloaded RC2. I was running 1.9 without issues in the past. Running on Windows 7.
Here's what is happening when I install. All attempts to start the service fail with the 87 error message.
C:\Neo4j\Neo4JTest\neo4j-community-2.0.0-RC1\bin>Neo4jInstaller.bat install
"WARNING: this installer is deprecated and may not be the optimal way to install Neo4j on your system."
"Please see the Neo4j Manual for up to date information on installing Neo4j."
Press any key to continue
[SC] CreateService SUCCESS
[SC] StartService FAILED 87:
The parameter is incorrect.
Regarding the warning message: The installer doesn't seem to have an option for installing as a service, and I haven't seen any other instructions in the manual for installing as a service.
http://docs.neo4j.org/chunked/2.0.0-RC1/server-installation.html#windows-install
Neo4j 2.0.0-RC1
neo4j-community-2.0.0-RC1-windows
Windows 7
neo4j>bin\Neo4jInstaller.bat install
[SC] CreateService SUCCESS
[SC] StartService FAILED 87:
The parameter is incorrect.
This problem is the result of a combination of bugs in the new Neo4j installation bat files that result in a corrupt binPath= parameter in the sc create service command in the Neo4jInstaller.bat file itself.
Specifically, the sc create command requires the binPath= parameter in this instance to be quoted, as there are embedded spaces within the Neo4j %binPath% variable. However, the sc create command created within Neo4jInstaller.bat contains unescaped quotes and an erroneous space embedded in the %javaPath% variable within the %binPath% variable definition.
To fix this, two files need to be edited:
bin\functions.bat
bin\Neo4jInstaller.bat
The invalid space embedded in the %javaPath% variable is caused by a space after the "=" sign in the set javaPath="%JAVA_HOME%" command in functions.bat.
The unescaped quotes in %binPath% require three changes in Neo4jInstaller.bat:
The quotes in the %javaPath% variable must be removed before is is embedded in the %binPath% variable.
The entire %javaPath%\bin\java.exe path must be enclosed in
quotes.
The %binPath% variable value must be enclosed in quotes, and the
quotes embedded within the %binPath% variable must be escaped.
Additionally, the call to functions.bat within Neo4jInstaller.bat must be modified, because functions.bat resides in the \bin subdirectory, and Neo4jInstaller.bat must be run from the root neo4j directory.
functions.bat
=============
:findJavaHome
if not "%JAVA_HOME%" == "" (
if exist "%JAVA_HOME%\bin\javac.exe" (
rem set javaPath= "%JAVA_HOME%\jre"
set javaPath="%JAVA_HOME%\jre"
goto:eof
)
rem set javaPath= "%JAVA_HOME%"
set javaPath="%JAVA_HOME%"
goto:eof
)
Neo4jInstaller.bat
==================
rem call functions.bat :findJavaHome
rem set javaPath=%javaPath:"="""%
rem set binPath="%javaPath%\bin\java.exe %loggingProperties% -DworkingDir="%~dps0.." -DconfigFile=%configFile% %classpath% %mainclass% -Dorg.neo4j.cluster.logdirectory="%~dps0..\data\log" -jar %~dps0%wrapperJarFilename% %serviceName%"
call %~dps0functions.bat :findJavaHome
set javaPath=%javaPath:"=%
set binPath="%javaPath%\bin\java.exe" %loggingProperties% -DworkingDir="%~dps0.." -DconfigFile=%configFile% %classpath% %mainclass% -Dorg.neo4j.cluster.logdirectory="%~dps0..\data\log" -jar %~dps0%wrapperJarFilename% %serviceName%
set binPath="%binPath:"=\"%"
There is a "Closed" Neo4j ticket on GitHub at https://github.com/neo4j/neo4j/pull/1535 that only partially fixes these issues for RC2. However, in the meantime, you will have to fix this yourself.
So here's what I discovered.
There's a registry key here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services_whatever_you_named_the_service
The Image Path has quotes like so:
"C:\Program Files\Java\jdk1.7.0_21\jre"\bin\java.exe ....
I removed the quotes
C:\Program Files\Java\jdk1.7.0_21\jre\bin\java.exe ....
It now works.
Looking at the bat file it's finding javaPath from my JAVA_HOME env variable and setting %javaPath% with quotes around it in functions.bat.
Then there's a part that's adding three extra quotes in place of any existing quotes in the javaPath on line 55 of Neo4jInstaller.bat
set javaPath=%javaPath:"="""%
Found this on the GitHub, not sure if it is going to fix this issue considering someone elses comment regarding the issue:
https://github.com/neo4j/neo4j/pull/1535
As this is the first results which pops up in google when searching for: "[SC] StartService FAILED 87: The parameter is incorrect."
Check the path again. In most cases the error is in the quoted path.
I run into this problem when creating a windows service with .NET Core 2.0.
Path example:
sc create YourServiceName binPath= "C:\Users\john\source\published\YourServiceName\YourServiceName.exe"
My mistake was a space:
sc create YourServiceName binPath= " C:\Users\john\source\published\YourServiceName\YourServiceName.exe"
I am currently relearning Ocaml and am in the need of a good editor. There is a new editor from OcamlForge: OCamlEditor http://ocamleditor.forge.ocamlcore.org/. Prerequisite for installation is Lablgtk2.
Installing Lablgtk2 on windows is not straight forward and there is good instruction here: http://wwwfun.kurims.kyoto-u.ac.jp/soft/lsl/install-win32.txt
I have completed the first two steps and in the third step, as warned, it is failing on the native code version. This is where I am left stranded. How do I check to see if the assembler is on my path? What am I missing here?
Please help me move forward from this point.
You have an MSVC installation, right? By default MSVC doesn't add command-line tools (cl - compiler, ml - assembler, link - linker) to the PATH (and needed directories to INCLUDE and LIB). But it provides a shell script to do this - MSVS9\Commnot7\Tools\vsvars32.bat. Copy it somewhere to the PATH so that you can easily call it any time needed. Then, before running ocaml compiler call vsvars32.bat to setup the environment. You can make this environment permanent by looking at changes to %INCLUDE%, %LIB% and %PATH% variables made by this script and adding them manually to environment variables of current user (usual windows gui insanity - My Computer -> Additional -> Environment variables).