I am trying to create a Jenkins build on a windows box, and am running into a situation where I am completely unsure of what to do.
I have the following shell script which I need to convert to a windows batch script for when the build runs. I have I believe gotten the set correct for the variables, just not sure what to do with the rest of it:
#set POWERUSER=DTCURTISS
#set POWERPASS=password
set POWERUSER=auto
set POWERPASS=password
set TAG=$BUILD_NUMBER
set PATH=.env/bin:$PATH
set SAUCEUSER=DarthOpto
set ACCESSKEY=accesskey
set IGNOREPAGEHEADERLOCATION=True
set MAINMENUCLICKTILES=False
set LOGDIR=logs
source ../.env/bin/activate
cd trunk/automation/selenium/src
#pip install -r pip-requires.txt
rm -rf logs
nosetests --nocapture --with-xunitmp -a valallmod --processes=$THREADS --process- timeout=5000
You are not going to get far if you don't know batch-file. Besides, simply "translating" bash to batch is not going to magically make it work on Windows.
Variables are referenced as %VARNAME%, not $VARNAME. Fix that first.
Windows uses \ as path separator, not /. Change all your paths to use \
When you want to append to PATH variable in Windows, you've got to make sure you don't destroy the existing PATH. You do this through set PATH=%PATH%;C:\whatever\yourpath\
Something similar to source would be batch's call followed by another batch file name. However you can't just pass it ../.env/bin/activate as that is not a batch file. You would need to convert that file to batch as well. And don't forget to convert the path separator to \. This is also where my second point comes into play. The file you pasted is rather simple. I've got no idea what's inside that other file or whether it can be "translated".
The # is not a valid comment in batch, you need to use REM or better yet ::
rm and it's flags is not a Windows command. An equivalent would be rmdir /s /q
Finally, nosetests is neither bash nor batch. It's an external program. You've got to make sure it is available in Windows. As a pre-emptive step before your next question, read this: 'nosetests' not recognized on Windows after being installed and added to PATH
Related
I want to run octave-gui (Octave 5.1 installed with installer and "C:\Octave\mingw64\bin" is in path variable) scripts run by Windows Task Scheduler. I have to run octave-gui since I want to use the qt toolkit for plotting that octave (without gui) does not support. Therefore I normally use simple bat files like "octave-gui --no-gui c:\path\myfile.m".
But the problem is that I cannot run this bat file by clicking in the Windows Explorer or running from command line. Even the most simple bat file with the content "octave-gui --no-gui" gives me the following error:
But the funny part is that I can make it work somehow:
open command line
run "octave" or "octave-gui" and close/quit it
then I can the bat file from the command line
But this could not be the solution, could it? This only works in the (interactive) command line. How does it work in the Task Scheduler?
So, do you have a solution to run either batch files using octave-gui or octave with qt toolkit.
Here is the workaround with "where" as asked by Gerhard:
The command octave is technically incorrect.
It works only from your Command Prompt window because its extension .bat is listed within the values assigned to an unmodified environment variable %PATHEXT%. It also assumes that there are no other files named octave.com or octave.exe, anywhere within the any of the directories listed under your environment variable %PATH%. Additionally it also assumes that there is not an executable file named octave with any extension listed under %PATHEXT% in the current directory when invoked.
You should, for safety, use octave.bat instead.
octave.bat
Octave.bat will parse any input arguments, set up the required environment, and then run either start octave-gui.exe --gui %* or octave-cli.exe %* if it detected --no-gui as one of the input arguments.
Additionally when running a batch file from another, (in this case start_my_octave_script.bat), you should Call it if you're wanting control to return to it afterwards, which will almost certainly be the case.
call octave.bat <command line options>
If you're satisfied that your %PATHEXT% environment variable is unmodified or at least holds the default values, you can omit the .batextension, but please bear in mind the previous advice.
call octave <command line options>
I made a workaround thanks to the hints made by Compo. It seems to me that a solution must be done in the "octave.bat" and so I did. I made a copy and named it "octave-gui-nogui-withqt.bat" and removed all the gui checking stuff and only run "octave-gui.exe --no-gui" (scroll down):
:; # if running from bash, recall using cmd.exe
:; cmd.exe //c "$0" "$#"; exit $?
#echo off
Rem Find Octave's install directory through cmd.exe variables.
Rem This batch file should reside in Octaves installation bin dir!
Rem
Rem This trick finds the location where the batch file resides.
Rem Note: the result ends with a backslash.
set OCT_HOME=%~dp0\.\..\
Rem Convert to 8.3 format so we don't have to worry about spaces.
for %%I in ("%OCT_HOME%") do set OCT_HOME=%%~sI
Rem Set up PATH. Make sure the octave bin dir comes first.
set PATH=%OCT_HOME%qt5\bin;%OCT_HOME%bin;%PATH%
Rem Set up any environment vars we may need.
set TERM=cygwin
set GNUTERM=wxt
set GS=gs.exe
Rem QT_PLUGIN_PATH must be set to avoid segfault (bug #53419).
IF EXIST "%OCT_HOME%\qt5\bin\" (
set QT_PLUGIN_PATH=%OCT_HOME%\qt5\plugins
) ELSE (
set QT_PLUGIN_PATH=%OCT_HOME%\plugins
)
Rem set home if not already set
if "%HOME%"=="" set HOME=%USERPROFILE%
if "%HOME%"=="" set HOME=%HOMEDRIVE%%HOMEPATH%
Rem set HOME to 8.3 format
for %%I in ("%HOME%") do set HOME=%%~sI
Rem Start Octave (this detaches and immediately returns).
Rem make this call in order to have qt on the cli
octave-gui.exe --no-gui %*
Is this the most elegant one? I guess that upstream Octave should allow a new option like "--no-gui-but-use-qt" or similar. What do you think?
It still confuses me that "octave-cli.exe" and "octave-gui.exe" have more differences besides the visible gui.
I set my path to JAVA bin. The system doesn't recognize it for some reason and cant seem to find the administrator for sometime.
What I do as a work around I go to command prompt and type the following commands:
set PATH=%PATH%;c:\amir\jdk1.7.0_45\bin
cd c:\myutilities\auth
java - jar auth.jar
I was wondering if there is another work around where I don't have to type all that again....? (perhaps create a command that I run that does all of the above)
Thanks!
Your PATH may contain spaces. First, properly quote it. And, you might have another jdk earlier in the PATH (so set it first). Something like
set "PATH=c:\amir\jdk1.7.0_45\bin;%PATH%"
Then, you don't need want a space between - and jar. So, use something like
cd c:\myutilities\auth
java -jar auth.jar
Finally, you should be able to copy and paste into your command prompt (or just save the above as a bat script).
#echo off
setlocal
set "PATH=c:\amir\jdk1.7.0_45\bin;%PATH%"
java -jar c:\myutilities\auth\auth.jar
endlocal
I've set an system environment variable called find which points to a batch script. I did this so that in Win command prompt i could type %find% and it would execute my script. It works the only problem is it only works once, my script takes a parameter or requires user input (have tried both), and then it is as if the %find% is temporarily overwritten, and the %find% of course no longer works, until i reopen the command window. Basically it works once and that's it!
How can i make it work every time? i want to execute my script using the environment variable over and over again at will without reloading the command window.
Thanks.
I created a batch script with the following code:
#ECHO off
echo hello
and added a environmental variable called TEST that points to the script. I have no problem executing the script using the environmental variable multiple times.
Can you please provide some information or code of what your script does?
Remember that find is a MS-supplied utility.
Try using a different name. And show us your batch - even possibly describe what happens when it "no longer works." Games of 20-questions are tedious.
The problem is that the Batch script uses a variable with the same name, so after it run for the first time the variable value is overwritten and no longer works. To prevent this to happen, insert a setlocal command at beginning of the Batch file; this way, when the script ends all variables are reset to the values they had before the script run. This method also delete all new variables defined in the Batch script, so it keep the environment clean.
If your intention is to override the behavior of the existing find.exe utility, you could add the location of the script to the global path variable before your System32 folder (where find.exe is located). For example, let's say your script is C:\Scripts\find.bat. If your path variable is currently set to this:
%SystemRoot%\system32;%SystemRoot%
...then you would change it to this:
C:\Scripts;%SystemRoot%\system32;%SystemRoot%
Beware though... doing this could break other scripts that use the find command (if they don't use the absolute path to find.exe).
If you are just wanting an easy way to run your alternate find command, you could just give it a different name as the others have suggested, then add it to the end of the path or place it in the System32 folder. That would save you from having to type the percent signs at least.
I am writing an batch file in Windows to run post-installation scripts, and one of the things that needs to be done is to add a directory to the system path.
The script is working, and it does something like this:
setx Path "%PATH%;c:\path\to\add" -m
This is setting the path correctly, but this script could potentially be run multiple times if the user reinstalls the program.
I would like to search the string for c:\path\to\add so I don't keep adding the same path over and over to the system path. This is pretty trivial in Linux with sed, but I don't know what the command is in Windows. I've found findstr, but this seems to only work on files.
Is this possible in Windows without installing additional software?
EDIT:
I'm using Inno Setup to create the install executable.
At the risk of some downvotes till an expert provides a sound way of doing this,
the below removes the specific path from the environment variable if it exists, so that it can be added again:
set str=%path%
:: str is the same with path
set str=%str:;C:\Path\To\Add=%
:: ";c:\path\to\add" is now removed from str
setx Path "%str%;c:\path\to\add" -m
:: proceed with setting the path
This carries the risk of removing the string if it is in fact actually a part of a path, for instance c:\path\to\add\somefolder. Also if the path actually ends with a \, or it is the first entry and it in fact does not start with ;, etc..
Various forms can be called consecutively to circumvent some of these,
set str=%str:;C:\Path\To\Add\;=;%
set str=%str:;C:\Path\To\Add;=;%
set str=%str:;C:\Path\To\Add\=%
set str=%str:C:\Path\To\Add\;=%
set str=%str:;C:\Path\To\Add=%
But, AAMOF I'n not sure this is a sane way of doing this..
This is my code snippet to find the "cvsnt" path in the PATH variable.
if not "x%PATH:cvsnt=%" == "x%PATH%" goto proceed
set PATH=w:\build-repository\cvsnt\2.5.03-2382;%PATH%
echo Path added
:proceed
The part to look at is
not "x%PATH:cvsnt=%" == "x%PATH%"
First I replace all occurrences of "cvsnt" with an empty string. The result is compared to PATH without replacement of "cvsnt". If they are not equal because of "cvsnt" was replaced then it exists in PATH and the code can proceed.
The starting x before %PATH% is only a placeholder to protect against certain "improper" starting characters. see Batch file: Find if substring is in string (not in a file)
The setx utility has a drawback, it can not handle variables longer than 1024 characters.
I have been wrote a script to handle cases longer than the limit and without a need to install anything. Answered the question here: Set environment variables with NSIS in Window 7
Instead of adding the path each time - you could check if the executable you are looking for can be found within the path using a command like this:
for %f in (cmd.exe) do if [%~$PATH:f]==[] setx Path "%PATH%;c:\path\to\add" -m
Make sure to check for /? to read more about the magic of %~$PATH:f.
This is a bit of a hackish workaround, but follows the logic you expect:
Search the PATH
Conditionally add to the PATH
It never removes anything from the PATH, so there's no fear of screwing up Windows by removing something accidently. Also, it checks the PATH variable directly, so you don't have to worry about another file with the same name that lives somewhere on the PATH.
echo %PATH% > myTmpPath.tmp
find /C /I "c:\path\to\add" myTmpPath.tmp
if %ERRORLEVEL% neq 0 setx PATH "%PATH%;c:\path\to\add"
del myTmpPath.tmp
I hate using temporary files, but it's quick and dirty, and probably safer than removing something from the PATH.
The third line is the only tricky one. Basically, this line tests the outcome of the FIND command above. Rob van der Woude states:
FIND returns an errorlevel of 1 or higher if the search string wasn't found.
He also explains:
Some executables return negative numbers for errorlevels! However, this can be
fixed by using the following code to check for non-zero return codes:
IF %ERRORLEVEL% NEQ 0 ...
How do I run a BAT script without changing directories?
I am in ./a and the script cd's into ./a/bc. If I need to terminate my script for whatever reason I am now in bc instead of a. How do I run the script and not have my folder change?
Also, I don't like how it asks me if I'd like to terminate my script. Can I disable that and let it terminate?
The setlocal command is useful for this. Any directory changes after setlocal are just local to the batch script. BTW this also applies to any environment variables (set commands).
For example, after running this batch script:
cd /d c:\temp
setlocal
cd /d c:\windows
the directory will be c:\temp since the second cd in the script is just local to the script.
If you don't need to propagate environment variable changes into the current environment and cannot touch the batch file (to use the pushd/popd variant which I usually use), you can still spawn a new instance of cmd:
cmd /c myBatch.cmd arg1 arg2 ...
Also has the nice property of leaving your original batch file running even if the called batch throws up errors. I do that in my batch unit testing framework, for example, to ensure that a failing batch file won't stop the tests from executing.
You can run your script with start yourscript.bat. This makes it run in a new command window, and therefore does not affect the working directory of the command prompt that started the script.
Another possibility is to not use cd and use absolute paths instead.
The first question is: why do you need to change the directory? Can you simply work with paths relative to the one of your batch file? (e.g. using %~dp0\a\bc to reference the directory)
But if you really, really need to do that, you can do the following:
REM change the current directory
pushd ..\a\bc
.. do your stuff here
REM restore the old "current directory"
popd