Batch code reading problem equal dash apostrophe - windows

I got stuck with reading this script. I assume that SET RAWDATA is some sort of setting the parameters, but can someone tell me what is all about. Particulary I wonder about this syntax: '='%, ' ='%, =%.
SET RAWDATA=%RAWDATA:~0,-1%
SET KEYS=%KEYS:~0,-2%
SET RAWDATA=%RAWDATA: =%
SET RAWDATA=%RAWDATA:' ='%
SET RAWDATA=%RAWDATA: '='%
SET RAWDATA=NULL,now(),%RAWDATA%

Related

I am learning Batch - why am I having issue with setting an environment variable with other environment variables as its input? Mid String issue

I am sure this issue is something silly. But I am not sure what I am doing wrong. I want the variables, start and end to be used to set the mid string method I am using to set subStr. I have already read set /? with no success. Any help would be greatly appreciated.
echo off
rem // First I will set all my varialbles...
set pleaStr=this is just a test. Please help me figure this out. I appreciate your help
set start=21
set end=-23
set subStr=%pleaStr:~start,end%
rem // The mid string method works normally. See!!
set subStrEasy=%pleaStr:~21,-23%
rem // Return extracted URL:
echo %pleaStr%
echo %subStr%
echo %subStrEasy%
The code above, does not work if I substitute the Environment Variables(ENV) start and end for their digit counterparts, 21 and -23.
when I echo %subStr% I get pleaStr:~start,end
where as echo %subStrEasy% gives me Please help me figure this out.
Perhaps environment variable cannot be used in this manner?
And here is the solution using delayed expansion.
#echo off
setlocal enabledelayedexpansion
set "pleaStr=this is just a test. Please help me figure this out. I appreciate your help"
set "start=21"
set "end=-23"
set "subStr=!pleaStr:~%start%,%end%!"
echo %subStr%

Why are passed values in a batch %variable% not applied correctly?

[Original Title: Why are lowercase values in a batch %variable% being returned as uppercase?]
Condition
I have a batch file where the value is declared for a variable as such:
SET myVar="something.lowercase"
But later in the script when you reference that variable as such:
%myVar%
the value is coming in as SOMETHING.LOWERCASE which is causing the particular command to not work correctly. (see resolution: the issue was a spurious " in the command and the uppercase was the way the "failure" was being reported)
Concern
Why and under what situation does this happen? moot as the value is not being changed, but rather the way the failure is reported and the failure was due to a " being introduced in the passed value (see resolution)
Context
For context, in case it matters, it is being called in this way: (it turned out to matter as the introduced " was causing the check to fail and the confusion was coming from the "cannot find ..." being uppercase)
TASKLIST /FI "IMAGENAME eq %myVar%" 2>NUL | FIND /I /N "%myVar%">NUL
I suspect that this is somehow happening in the context of this command, but cannot be sure and don't know why. If that is by chance the case, how can I mitigate it? (see resolution)
Thank you in advance.
Resolution
Thanks to #Campo's suggestion, changing the value by dropping the " resolved the issue and the script functions correctly now. Thank you.
Your issue is because you're needlessly including doublequotes in your variable value.
Because you've included the doublequotes the TaskList filter is looking for:
"IMAGENAME eq "something.lowercase""
...and your Find command is trying to match:
""something.lowercase""
The fix is to use the correct syntax for setting a variable:
Set "myVar=something.lowercase"

Win10 Batch script: \Notepad++ was unexpected at this time

This batch file gives the error in the title:
if "%PROCESSOR_ARCHITECTURE%"=="x86" (
echo FOOBAR
) else (
set HOME_EDIT=%SystemDrive%\Program Files (x86)\Notepad++
)
This is on a Win10 Pro x64 system (so the test is false).
Strangely the "set HOME_EDIT..." line, if executed by itself, does NOT generate the error. And this batch file seemed to work OK a few weeks ago (oldest complaint in the book, I know, but maybe the recent Win10 Creator's Update chagned something?).
Here's the whole output:
U:\Users\Dave\data\PC setup\2017-03 PC Setup for Win10>test.bat
\Notepad++ was unexpected at this time.
U:\Users\Dave\data\PC setup\2017-03 PC Setup for Win10> set HOME_EDIT=C:\Program Files (x86)\Notepad++
U:\Users\Dave\data\PC setup\2017-03 PC Setup for Win10>
Putting quotes around the assignment certainly solves the problem, but it has nothing to do with spaces. The problem is the ) in the path is closing the ELSE block prematurely unless the path is quoted (or escaped).
Without quotes, the ELSE block becomes
) else (
set HOME_EDIT=%SystemDrive%\Program Files (x86
)
And then the \Notepad++ is indeed unexpected, causing a syntax error.
I see 3 ways to eliminate the syntax error:
1) Eliminate the parentheses and put the SET command on the same line as ELSE
else set HOME_EDIT=%SystemDrive%\Program Files (x86)\Notepad++
2) Put quotes around the assignment
) else (
set "HOME_EDIT=%SystemDrive%\Program Files (x86)\Notepad++"
)
3) Escape the closing parenthesis
) else (
set HOME_EDIT=%SystemDrive%\Program Files (x86^)\Notepad++
)
If I were to do the assignment, I would use the predefined environment variable for the folder.
) else (
set "HOME_EDIT=%ProgramFiles(x86)%\Notepad++"
)
Answering my own question:
#drescherjm was correct (in the comments) that the immediate problem was lack of quote marks ("foo") around the argument to SET. Somehow this matters when the SET is within a IF statement, even tho it doesn't otherwise.
But adding quotes just broke something else later in my batch script:
set NEW_PATH=%HOME_WINDOWS%
set NEW_PATH=%NEW_PATH%;%BinPath%
set NEW_PATH=%NEW_PATH%;%BinPath%\ffmpeg\bin
set NEW_PATH=%NEW_PATH%;%BinPath%\mplayer
set NEW_PATH=%NEW_PATH%;%BinPath%\gui
set NEW_PATH=%NEW_PATH%;%BinPath%\dll
set NEW_PATH=%NEW_PATH%;%HOME_CYGWIN%\bin
set NEW_PATH=%NEW_PATH%;%HOME_CYGWIN%\sbin
set NEW_PATH=%NEW_PATH%;%HOME_CYGWIN%\usr\bin
set NEW_PATH=%NEW_PATH%;%HOME_CYGWIN%\usr\sbin
set NEW_PATH=%NEW_PATH%;%HOME_7ZIP%
set NEW_PATH=%NEW_PATH%;%HOME_EDIT%
set NEW_PATH=%NEW_PATH%;%HOME_DIFF%
set Path=%NEW_PATH%
setx Path "%NEW_PATH%"
If HOME_EDIT has quote marks in it, this causes SETX to fail.
Here's the fix I came up with (note lines marked with "TRICK1"):
REM The following is a trick to get around spaces in the path (TRICK1)
set HOME_EDIT=%SystemDrive%\%ProgramFiles(x86)%\Notepad++
if "%PROCESSOR_ARCHITECTURE%"=="x86" (
set HOME_CYGWIN=%SystemDrive%\cygwin
set HOME_EDIT=%SystemDrive%\Program Files\Notepad++
) else (
set HOME_CYGWIN=%SystemDrive%\cygwin64
REM (TRICK1 rem this out) set HOME_EDIT=%SystemDrive%\%ProgramFiles(x86)%\Notepad++
)
The path with the spaces in it is SET as a default value prior to entering the IF statement. This way no quote marks are needed, and SETX doesn't break later.

CMD appears not to recognize variables

CMD does not appear to be recognizing any variable I store using SET. If I run this batch file:
#ECHO off
SET /P name = What is your name?
ECHO %name%
PAUSE
ECHO on
I get the following output:
What is your name? steven
ECHO is off.
Press any key to continue . . .
When I run line 2 and then line 3 from the command prompt, it just prints:
%name%
Do I have something configured incorrectly? Am I correct in thinking that line 2 should create a session variable that should be recognized in line 3?
I searched, but I could only find answers related to variable expansion within IF blocks. This is happening to me outside any IF/FOR/etc blocks.
This is Windows 7, by the way. I'm not sure how much cmd changes from one version of Windows to another.
There must not be any spaces around the equal sign in the set instruction. Change this
SET /P name = What is your name?
into this
SET /P name=What is your name?
and your problem will disappear.
since I can not add any comments yet I have to post a new answer. The information:
"There must not be any spaces around the equal sign in the set instruction."
is only partly correct. To be exact it should say: the equal sign must follow directly after the variable name (in sricks3's case without a space). Whatever comes after the equal sign will be used as input-prompt for the variable including any spaces, so the following code will work as well:
SET /P name= What is your name?

Check for null variable in Windows batch

I'm working on a Windows batch file that will bcp three text files into SQL Server. If something goes wrong in production, I want to be able to override the file names. So I'm thinking of doing something like this.
bcp.exe MyDB..MyTable1 in %1 -SMyServer -T -c -m0
bcp.exe MyDB..MyTable2 in %2 -SMyServer -T -c -m0
bcp.exe MyDB..MyTable3 in %3 -SMyServer -T -c -m0
I would like to be able to enter default names for all three files, to be used if the positional parameters are not supplied. The idea would be either to execute
myjob.bat
with no parameters, and have it use the defaults, or execute
myjob.bat "c:\myfile1" "c:\myfile2" "c:\myfile3"
and have it use those files. I haven't been able to figure out how to tell if %1, %2 and %3 exist and/or are null. I also don't know how to set those values conditionally. Is this possible? Any suggestions would be appreciated.
To test for the existence of a command line paramater, use empty brackets:
IF [%1]==[] echo Value Missing
or
IF [%1] EQU [] echo Value Missing
The SS64 page on IF will help you here. Under "Does %1 exist?".
You can't set a positional parameter, so what you should do is do something like
SET MYVAR=%1
You can then re-set MYVAR based on its contents.
The right thing would be to use a "if defined" statement, which is used to test for the existence of a variable. For example:
IF DEFINED somevariable echo Value exists
In this particular case, the negative form should be used:
IF NOT DEFINED somevariable echo Value missing
PS: the variable name should be used without "%" caracters.
Both answers given are correct, but I do mine a little different. You might want to consider a couple things...
Start the batch with:
SetLocal
and end it with
EndLocal
This will keep all your 'SETs" to be only valid during the current session, and will not leave vars left around named like "FileName1" or any other variables you set during the run, that could interfere with the next run of the batch file. So, you can do something like:
IF "%1"=="" SET FileName1=c:\file1.txt
The other trick is if you only provide 1, or 2 parameters, use the SHIFT command to move them, so the one you are looking for is ALWAYS at %1...
For example, process the first parameter, shift them, and then do it again. This way, you are not hard-coding %1, %2, %3, etc...
The Windows batch processor is much more powerful than people give it credit for.. I've done some crazy stuff with it, including calculating yesterday's date, even across month and year boundaries including Leap Year, and localization, etc.
If you really want to get creative, you can call functions in the batch processor... But that's really for a different discussion... :)
Oh, and don't name your batch files .bat either.. They are .cmd's now.. heh..
Hope this helps.
rem set defaults:
set filename1="c:\file1.txt"
set filename2="c:\file2.txt"
set filename3="c:\file3.txt"
rem set parameters:
IF NOT "a%1"=="a" (set filename1="%1")
IF NOT "a%2"=="a" (set filename2="%2")
IF NOT "a%3"=="a" (set filename1="%3")
echo %filename1%, %filename2%, %filename3%
Be careful with quotation characters though, you may or may not need them in your variables.
Late answer, but currently the accepted one is at least suboptimal.
Using quotes is ALWAYS better than using any other characters to enclose %1.
Because when %1 contains spaces or special characters like &, the IF [%1] == simply stops with a syntax error.
But for the case that %1 contains quotes, like in myBatch.bat "my file.txt", a simple IF "%1" == "" would fail.
But as you can't know if quotes are used or not, there is the syntax %~1, this removes enclosing quotes when necessary.
Therefore, the code should look like
set "file1=%~1"
IF "%~1"=="" set "file1=default file"
type "%file1%" --- always enclose your variables in quotes
If you have to handle stranger and nastier arguments like myBatch.bat "This & will "^&crash
Then take a look at SO:How to receive even the strangest command line parameters?

Resources