Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 months ago.
Improve this question
Note: as the OP is a new user, I'm editing the question with reproducible details so that it doesn't get closed. It's a good question, but was originally confusing.
The Windows username is: jhon^smith
ECHO %username%
output : jhonsmith
My expectation:
jhon^smith
If I use:
echo "%username%"
then the output is:
"jhon^smith"
How can I remove the double quotes but keep the caret, which is actually part of the username?
This should work:
for /f %a in ("%username%") do echo %a
output:
jhon^smith
(btw: It should be spelt john^smith but never mind.)
Explanation:
In the command echo %username%, cmd.exe replaces %username% with its actual content, so the command becomes echo jhon^smith. This is then parsed, the the ^ is processed as the escape character, so it replaces ^s with s.
In the command for /f %a in ("%username%") do echo %a, the quoted string is treated as a string without the quotes, and no parsing of ^ is performed. Type for /? for more details.
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed yesterday.
Improve this question
I am writing a batch script on windows to automate downloading files with using WinSCP. I have the following code snippet and it works perfectly; however, depending on the user the user name is different so I want user to be a variable that users can specify.
#echo off
set message=Starting something cool
echo %message%
:: This is comment ?
"C:\Program Files (x86)\WinSCP\WinSCP.com" ^
/log="C:\Users\this_user\Desktop\temp_log\WinSCP.log" ^
/ini=nul ^
/command ^
"open sftp://test:crl#192.168.113.133/ -hostkey=""ssh-ed25519 255 H23HQ7fVOAun2yaVJ6tZwOWyIQ5nkmhiWz+gfxSnwRQ""" ^
"get /var/log/kern.log C:\Users\this_user\Desktop\temp_log\sys\" ^
"exit"
set WINSCP_RESULT=%ERRORLEVEL%
if %WINSCP_RESULT% equ 0 (
echo Success
) else (
echo Error
)
exit /b %WINSCP_RESULT%
So I want "this_user" to be a variable
I tried the following:
THIS_USER="this_user"
C:\Users\this_user\Desktop\$THIS_USER
but no luck.
Please consider the following very simple batch script (the file is named test.cmd):
#echo off
set "var1=%~1"
echo %var1%
The script should be called with one command line parameter, should assign the string which is contained in that parameter to a variable, and should output the variable.
As expected, I get an error message when I call this script with a command line parameter which contains an ampersand (&):
C:\Batch>test "a&b"
a
'b' is not recognized as an internal or external command,
operable program or batch file.
The reason for this has been discussed in some other questions here and elsewhere, for example that one; the usual remedy is to use delayed expansion. So I changed the script accordingly:
#echo off
setLocal enableDelayedExpansion
set "var1=%~1"
echo !var1!
Now it works with the parameter from before:
C:\Batch>test "a&b"
a&b
But there is a new problem. When the command line parameter contains an exclamation mark (!), it will be dropped from the output:
C:\Batch>test a!b
ab
This behavior also has been discussed at several places, for example here; the crucial thing to note is that dropping the exclamation mark happens during the assignment, not during the echo.
Despite a lot of research, I did not find a question here which provided an elegant solution for both problems at once. That is, is there an elegant way to assign a command line parameter to a variable when that parameter contains an ampersand AND an exclamation mark?
It seems that I need the delayed expansion to treat the ampersand correctly, but this destroys the exclamation mark.
The only solution I currently see is to not use delayed expansion and to add code to explicitly quote all ampersands in the input string. This would be so ugly that I seriously think that I am missing something here.
As a side note, the reason for the problem actually seems to be that there (IMHO!) is no way to get the command line parameter in a delayed-expanded fashion. The syntax for the first parameter is %~1, there is no such thing as !~1.
Move the setLocal enableDelayedExpansion after the the set„ that's all.
#echo off
set "var1=%~1"
setLocal enableDelayedExpansion
echo !var1!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I would like to know how to remove parentheses and square brackets and what's inside of them in a list of files' names, using a .bat file
For example:
[Tag]File (1).mkv
to
File.mkv
The solution to your issue can be found in syntax-replacement. The first thing you want to do is have the batch file turn your file name into a variable. From there, you can use syntax-replacement with the set= to replace/remove parts of the variable.
The script bellow will remove [square brackets] and the contents inside them, and (parentheses) and the contents inside them.
Please keep in mind that this script bellow in an example to demonstrate syntax-replacement. It will not check/test (if) somethings in-front or behind. It expects you to have it formatted as [Tag]Name(#).ex - Change it to your needs.
#echo off
#setlocal
::Input your file location bellow.
call :edit "C:\Users\%username%\Desktop\[TAG]Hello(1).jpg"
goto :EOF
:edit
::Define file as variable
set file=%~1
set start=%~1
::Define file extension as variable
set ext=%file:*.=%
::Remove right square bracket and everything before it
set square=%file:*]=%
::Remove everything after left parentheses
set efile=%square%
set endbit=%efile:*(=%
call set result=%%efile:%endbit%=%%
::Remove left parentheses
set final=%result:(=%
::Add file extension and rename
ren %start% "%final%.%ext%"
exit
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
My Perl program creates the file
10001.ICNTL.20160602.20160603.OPR.GAAP.PROD.PFI.PRE.txt
Then in method I have a code:
if ( -e $report ) {
# we parse the filet here is some code, at the end
{
else
}
print "*** Skipping \\NYNAS\NYNDS\VOL\DATA\INVACCT\FUND_RECS_PFI\10001.ICNTL.20160603.PROD.GAAP.PFI\10001.ICNTL.20160602.20160603.OPR.GAAP.PROD.PFI.PRE.TXT
}
I cannot understand why the script doesn't see the file. I've checked it several times letter by letter. Can it be because of the Upper case TXT, but in reality it is lower case?
Is your file 10001.ICNTL.20160602.20160603.OPR.GAAP.PROD.PFI.PRE.txt in directory \\NYNAS\NYNDS\VOL\DATA\INVACCT\FUND_RECS_PFI?
At a guess you're not escaping the file path correctly. Even if you use single-quotes, there is no way of representing the two leading backslashes in Uniform Naming Convention (UNC) paths without escaping at least one of them
Check the output of print $report, "\n" to see what you've really written
My preference is to use four backslashes at the start of the path string, like this
my $report = '\\\\NYNAS\NYNDS\VOL\DATA\INVACCT\FUND_RECS_PFI\10001.ICNTL.20160603.PROD.GAAP.PFI\10001.ICNTL.20160602.20160603.OPR.GAAP.PROD.PFI.PRE.TXT';
print -e $report ? "Found\n" : "Not found\n";
And Perl allows you to use forward slashes in place of backslashes in a Windows path, so you could write this instead if you prefer, but paths like this aren't valid in other Windows software
my $report = '//NYNAS/NYNDS/VOL/DATA/INVACCT/FUND_RECS_PFI/10001.ICNTL.20160603.PROD.GAAP.PFI/10001.ICNTL.20160602.20160603.OPR.GAAP.PROD.PFI.PRE.TXT';
Or another alternative is to relocate your current working directory. You cannot cd to a UNC path on the Windows command line, but Perl allows you to chdir successfully
chdir '//NYNAS/NYNDS/VOL/DATA/INVACCT/FUND_RECS_PFI' or die $!;
Thereafter all relative file paths will be relative to this new working directory on your networked system
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 8 years ago.
Improve this question
I've been working on a bash script to run tests on a program and I can't seem to be able to find the syntax error. When I use -x, it tells me it is expecting a } but I can't find it.
Please see the code underneath.
#!/bin/bash
usagearg() {
echo "You're missing an argument on the command line!" >&2}
usagemiss() {
echo "A file requested in your filestem is missing or cannot be read!" >&2}
if [ ${#} -ne 2 ]; then
usagearg;
exit 1;
fi
x=1
endp=`wc -l ${1}`
end=$((endp+1))
while [ ${x} -ne ${end} ] ; do
# redacted code which isn't related to the issue at hand.
done
I feel like I've closed all the loops and ifs, and all the brackets, so I don't understand why I'm getting the syntax error.
The list of commands inside the braces for the compound command must be terminated by either a semicolon or a newline; the closing brace itself is not sufficient.
Either use
usagearg() {
echo "You're missing an argument on the command line!" >&2; }
or
usagearg() {
echo "You're missing an argument on the command line!" >&2
}
As written, your code treats the right brace as simply another character, and part of the output redirection since there is no intervening whitespace.
As to why this is necessary, you have to go back to how bash defines certain characters. There is the set of metacharacters, which can separate words when unquoted. There is also the set of control operators, which are vaguely defined as performing a "control function". The right brace } is in neither category. (Why? I'm not sure, but I think it's related to the use of braces in parameter expansion (${foo}) which preclude it having otherwise special handling.)