Trailing blanks in batch file
Ragnar Midtskogen
I have a batch file where I am trying to insert the short name of the
weekday in a file path.
I create the day variable as follows:
REM Get day of week
for /f %%a in ('date /t') do set DAY=%%a
The following line shoul copy the Registry backup file to the weekday folder
on the E drive:
XCOPY %BackUpDir%\Registry_Settings\%ServerName%-Registry-Backup.bkf
E:\SQLServerBackupsQA\%DAY%\ /Y
But, this string comes out with two blanks between the three letter day and
the following backslash. The XCOPY requires the backslash.
Any ideas on how to get rid of the blanks?
I am not to good about batch files, so any help would be appreciated.
Ragnar
foxidrive
<ragn...@newsgroups.com> wrote:
>I have a batch file where I am trying to insert the short name of the
>weekday in a file path.
>
>I create the day variable as follows:
>REM Get day of week
>for /f %%a in ('date /t') do set DAY=%%a
Look for blank spaces at the end of the line above, in your batch file.
If there are none then post again.
Al Dunbar [MS-MVP]
"foxidrive" <got...@woohoo.invalid> wrote in message
news:id6rq29cpqb5nl4ho...@4ax.com...
> On Tue, 16 Jan 2007 21:18:47 -0500, "Ragnar Midtskogen"
> <ragn...@newsgroups.com> wrote:
>
> >I have a batch file where I am trying to insert the short name of the
> >weekday in a file path.
> >
> >I create the day variable as follows:
> >REM Get day of week
> >for /f %%a in ('date /t') do set DAY=%%a
>
> Look for blank spaces at the end of the line above, in your batch file.
> If there are none then post again.
Easiest way to avoid this kind of a problem is to parenthesize the command,
i.e.:
(for /f %%a in ('date /t') do set DAY=%%a)
If that is not the cause, then blanks can be stripped from the DAY variable
with:
(set day=%day: =%)
At least I think that works on w2k in addition to 2k3 and xp
/Al
Ragnar Midtskogen
Of course they are there, I was asking how to get rid of them.
In another post, Al Dunbar said to put the line "for /f %%a in ('date /t')
do set DAY=%%a" in parentheses and that fixed the problem
Ragnar
Ragnar Midtskogen
(for /f %%a in ('date /t') do set DAY=%%a) gets rid of the blanks,
Batch file programming seems a bit strange, at least for the uninitiated
(:-)).
Ragnar
Phil Robyn
You could also do
... set "DAY=%%a"
to get rid of the trailing blank(s), which are perhaps being placed at the
end of each line of the batch file by the particular text editor that you
are using.
--
Phil Robyn
Todd Vargo
"Ragnar Midtskogen" <ragn...@newsgroups.com> wrote in message
news:O7buzzlO...@TK2MSFTNGP04.phx.gbl...
That is part of the learning curve.
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
foxidrive
<ragn...@newsgroups.com> wrote:
>Thank you Foxidrive,
>
>Of course they are there, I was asking how to get rid of them.
Place your cursor at the end of the line (with the end key) and press
backspace, then save.
Alexander Suhovey
news:uSyO3GoO...@TK2MSFTNGP02.phx.gbl...
> Ragnar Midtskogen wrote:
>> Thank you Al,
>> (for /f %%a in ('date /t') do set DAY=%%a) gets rid of the blanks,
>
>
> ... set "DAY=%%a"
Yet another one:
set DAY=%%a&
This is probably ugliest one but hey, it's a single character :-)
--
Alexander Suhovey
Al Dunbar [MS-MVP]
"Alexander Suhovey" <asuh...@gmail.com> wrote in message
news:26D08E3E-0C2D-4E38...@microsoft.com...
Hey, it's so ugly it will probably remain a single character for the rest of
its life!
This would be marginally better:
set DAY=%%a&rem :: DO NOT add whitespace between the "%%a" and the
"&"
but both are bad because the main function of "&" is to separate two
commands on a line, not terminate one, something it does incidentally.
Of these two:
(set DAY=%%a)
and:
set "DAY=%%a"
my personal favourite is the one with parenthesis. IMHO, they stand out a
little more, and consider this one: (set DAY="%%a"). Doing that with the
double-quoted method requires a bit more care.
/Al
Al Dunbar [MS-MVP]
"foxidrive" <got...@woohoo.invalid> wrote in message
> On Wed, 17 Jan 2007 12:25:40 -0500, "Ragnar Midtskogen"
> <ragn...@newsgroups.com> wrote:
>
> >Thank you Foxidrive,
> >
> >Of course they are there, I was asking how to get rid of them.
>
> Place your cursor at the end of the line (with the end key) and press
> backspace, then save.
then load the file back into your editor to display it and visually check to
see if there are blank characters. Wait a minute, it looks exactly the same
as before I fixed it!".
/Al
Alexander Suhovey
news:ekYwgEGP...@TK2MSFTNGP02.phx.gbl...
> Hey, it's so ugly it will probably remain a single character for the rest
> of
> its life!
Haha, that was a good one! Love it!
>set DAY=%%a&rem :: DO NOT add whitespace between the "%%a" and the "&"
Same applies to parentheses and quotes, isnt it? :-) The problem here is not
somebody putting extra trailing spaces by accident, it's some text editors
that can automatically do that for whatever reason they have. Also, you
probably know that some forum engines have this problem too: when you post a
code snipplet using [code][/code] tags, every line inside gets an extra
trailing space which can very well result in broken batch code if you
copy-paste it to your text editor.
> but both are bad because the main function of "&" is to separate two
> commands on a line, not terminate one, something it does incidentally.
Sure, but I don't see how it's that bad other than it looks ugly. There are
other things in batch scripting that weren't meant to be used in the way
they are used by scripters today.
Like "set /p" command which purpose is to provide interactive user input
facility but somebody figured it also can be used to append the output text
to the same line.
Or ping as a way to add pauses to the script.
@echo off
set /p foo="Working ..."<nul
for /l %%i in (1,1,40) do (
ping -n 1 127.0.0.1>nul 2>&1
set /p foo="."<nul
)
echo Done.
--
Alexander Suhovey
Al Dunbar [MS-MVP]
"Alexander Suhovey" <asuh...@gmail.com> wrote in message
news:C7BBE70E-41D5-4D4E...@microsoft.com...
> "Al Dunbar [MS-MVP]" <alan-no-...@hotmail.com> wrote in message
> news:ekYwgEGP...@TK2MSFTNGP02.phx.gbl...
> > Hey, it's so ugly it will probably remain a single character for the
rest
> > of
> > its life!
>
> Haha, that was a good one! Love it!
I can't seem to buy a good straight line these days, so when one comes along
for free, I go for it!
> >set DAY=%%a&rem :: DO NOT add whitespace between the "%%a" and the "&"
>
> Same applies to parentheses and quotes, isnt it? :-)
Yes and no. Yes, the prevention of a trailing blank isn't the primary reason
for them, but no: the parentheses and quotes at least surround the command
they are there to protect, whereas the ampersand simply follows it, a fact
that I contend makes its meaning at least somewhat less obvious. Also, the
quotes are normally understood to differentiate what is in a string from
what is not in a string, and the parenthesis' function is to group one or
more commands, thereby similarly differentiating what is in the command(s)
from what is not. If what is not happens to be a space, well that is still
simply these things doing their normal function, when this poor
(non-existent) space is given short shrift.
We could argue endlessly, or we could do a test with a hundred batch
programmers and ask them to modify this script to make it more readable, but
still yielding the same result:
set DAY=%%1&(set TIME=%%2)
I bet that the "&" would either be replaced with an endline character or
preceded and followed with a blank MORE often than would the final ")" be
preceded by a blank.
In my mind, then, it is not really which method is most aligned with the
original intent of the feature as I initially suggested, but which will
result in a more intuitive understanding of what it is doing in this
context.
> The problem here is not
> somebody putting extra trailing spaces by accident, it's some text editors
> that can automatically do that for whatever reason they have.
That may indeed be the cause of the majority of cases, however, I see the
problem as there *being* a trailing space whose presence creates a problem.
And that problem is further exascerbated by the difficulty of knowing the
blank is there when it is followed by more whitespace in the form of an
endline character.
If someone exclusively used an editor that displayed blanks as grey dots,
then it might be less important for them to do this (unless, of course, this
is one of the editors that indiscriminately pads lines with blanks), but one
can never be sure that one's script will never be edited by someone else
with a different editor.
> Also, you
> probably know that some forum engines have this problem too: when you post
a
> code snipplet using [code][/code] tags, every line inside gets an extra
> trailing space which can very well result in broken batch code if you
> copy-paste it to your text editor.
Which is one reason for the many posts over the years recommending the
explicit use of parentheses, or, sometimes, double-quotes.
> > but both are bad because the main function of "&" is to separate two
> > commands on a line, not terminate one, something it does incidentally.
>
> Sure, but I don't see how it's that bad other than it looks ugly. There
are
> other things in batch scripting that weren't meant to be used in the way
> they are used by scripters today.
I agree, like 80%! Ugliness alone may not be a bad thing; ugliness that
interferes with one's ability to detect subtle nuances about what is really
going on in a script, now *that* is a bad thing.
> Like "set /p" command which purpose is to provide interactive user input
> facility but somebody figured it also can be used to append the output
text
> to the same line.
>
> Or ping as a way to add pauses to the script.
>
> @echo off
> set /p foo="Working ..."<nul
> for /l %%i in (1,1,40) do (
> ping -n 1 127.0.0.1>nul 2>&1
> set /p foo="."<nul
> )
> echo Done.
Sure, I use those techniques, and more... That is because the side effects
in question are sometimes almost important as the obvious intent of such a
feature, and the side effect is not really available otherwise without
writing an executable to do it. But, ideally, one should never use code for
its side effects unless the meaning is documented, or at least in general
use in the batch scripting community.
/Al
Alexander Suhovey
[snip]
> We could argue endlessly
Yes we could though I wouldn't call it arguing, rather an interesting
conversation. I could say that to me
(set DAY=%%1)
(set TIME=%%2)
doesn't look much better than
set DAY=%%1&
set TIME=%%2&
and intent of "&" isn't less apparent here as that of parentheses. But the
thing is, I actually agree with you. By calling it ugly in my initial post I
was trying to say that it's just another way to address the issue though
least preferable one.
--
Alexander Suhovey
Timo Salmi
> "Al Dunbar [MS-MVP]" <alan-no-...@hotmail.com> wrote:
> [snip]
>> We could argue endlessly
>
> Yes we could though I wouldn't call it arguing, rather an interesting
> conversation. I could say that to me
> (set DAY=%%1)
Back to the question posed in the subject. The solutions so far work for
a single word, but insidiously not directly beyond that. Here is a small
demo
@echo off & setlocal enableextensions
set S= This is a test
echo %S%.
(for /f "tokens=*" %%a in ('echo %S%') do set T=%%a)
echo %T%.
endlocal & goto :EOF
The output
C:\_D\BAS>cmdfaq
This is a test .
This is a test .
Well, e.g. sed can be used to get rid of the remaining trailing blank.
However, should one drop the "tokens=*" then one gets:
This.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful script files and tricks ftp://garbo.uwasa.fi/pc/link/tscmd.zip
Timo Salmi
> Well, e.g. sed can be used to get rid of the remaining trailing blank.
Taken from
182662 Jan 13 2007 ftp://garbo.uwasa.fi/pc/link/tscmd.zip
tscmd.zip Useful NT/2000/XP script tricks and tips, T.Salmi
@echo off & setlocal enableextensions
set S= This is a test
echo %S%.
echo %S%|sed -e "s/^ *//" -e "s/ *$//" -e "s/^/@set
S=&/">%temp%\tmp$$$.cmd
for %%c in (call del) do %%c %temp%\tmp$$$.cmd
echo %S%.
endlocal & goto :EOF
The output will correctly drop both the leading AND the trailing blanks.
D:\TEST>cmdfaq
This is a test .
This is a test.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's FAQ materials at http://www.uwasa.fi/~ts/http/tsfaq.html
Todd Vargo
Al Dunbar [MS-MVP] wrote:
> Alexander Suhovey wrote:
> > The problem here is not
> > somebody putting extra trailing spaces by accident, it's some text
editors
> > that can automatically do that for whatever reason they have.
>
> That may indeed be the cause of the majority of cases, however, I see the
> problem as there *being* a trailing space whose presence creates a
problem.
> And that problem is further exascerbated by the difficulty of knowing the
> blank is there when it is followed by more whitespace in the form of an
> endline character.
>
> If someone exclusively used an editor that displayed blanks as grey dots,
> then it might be less important for them to do this (unless, of course,
this
> is one of the editors that indiscriminately pads lines with blanks), but
one
> can never be sure that one's script will never be edited by someone else
> with a different editor.
If an Editor is indeed appending the trailing space, it would be worthwhile
to know which editor does this so as to warn others to watch out for this
behavior.
Al Dunbar [MS-MVP]
> "Al Dunbar [MS-MVP]" <alan-no-...@hotmail.com> wrote in message
> news:uub1GPOP...@TK2MSFTNGP04.phx.gbl...
> [snip]
> > We could argue endlessly
>
> Yes we could though I wouldn't call it arguing, rather an interesting
> conversation.
I disagree. A conversation, interesting or otherwise, can be classified as
an argument if there is a disagreement of opinion, and/or if one or either
side is attempting to get the other side to change their opinion on a
matter. Unfortunately, the word "argue" seems to have taken on the more
negative aspect where there also is enmity involved. The lawyers who argue
cases against each other are often the best of friends.
> I could say that to me
>
> (set DAY=%%1)
> (set TIME=%%2)
>
> doesn't look much better than
>
> set DAY=%%1&
> set TIME=%%2&
And you would be quite right to say that that is your opinion. To
extrapolate your opinion to the level of absolute truth, now that would be
wrong. You don't seem to do that, but there are some that do.
Now, I'm not necessarily saying that I like the looks of my code when I see
set commands in parentheses - but I certainly do appreciate how they tend to
reduce simple syntactical errors.
> and intent of "&" isn't less apparent here as that of parentheses.
I see what you mean, as using the command separator to terminate one command
without a second following is obviously a use different from its more common
use. Of course, the uninitiated would probably wonder why you would be
appending an ampersand to a variable containing date or time information,
whereas he'd be less likely (imho) to assume that in the examples with
parentheses the intent was to append a ")", as he would see the matching
"(".
as an aside, I just did some testing and found that null statements seem to
generate error messages, for example:
()
&echo/testing
Odd, then, that this doesn't:
echo/testing&
> But the
> thing is, I actually agree with you. By calling it ugly in my initial post
I
> was trying to say that it's just another way to address the issue though
> least preferable one.
And, of course, I generally agree with you as well. Interesting that agree ~
argee ~ argue...
/Al
Al Dunbar [MS-MVP]
"Timo Salmi" <t...@uwasa.fi> wrote in message
news:%23nRil6O...@TK2MSFTNGP06.phx.gbl...
> Alexander Suhovey <> wrote:
> > "Al Dunbar [MS-MVP]" <alan-no-...@hotmail.com> wrote:
> > [snip]
> >> We could argue endlessly
> >
> > Yes we could though I wouldn't call it arguing, rather an interesting
> > conversation. I could say that to me
> > (set DAY=%%1)
>
> Back to the question posed in the subject. The solutions so far work for
> a single word, but insidiously not directly beyond that.
I disagree.
> Here is a small
> demo
>
> @echo off & setlocal enableextensions
> set S= This is a test
> echo %S%.
> (for /f "tokens=*" %%a in ('echo %S%') do set T=%%a)
> echo %T%.
> endlocal & goto :EOF
>
> The output
> C:\_D\BAS>cmdfaq
> This is a test .
> This is a test .
It is not that the final ")" in the for statement failed in its task, but
that the variable itself, "%%a", contained a trailing blank. I would
consider it an error on the part of the command processor for the ")" to
have the ability to edit the content of a variable, as that is not noted
anywhere in the documentation as its purpose.
Contrariwise, I maintain that the ")" succeeded in its task of preventing
the inadvertent appending of additional blank characters beyond the
characters contained in the variable. The ")" doesn't strip trailing blanks,
but is simply used to explicitly show what characters are included in the
command. Consider this sequence, for example:
(set blanky= trim this )
echo/.%blanky%.
What would you expect the output to appear as ".trim this.", ". trim this
.", or ". trim this ."?
> Well, e.g. sed can be used to get rid of the remaining trailing blank.
But the potential issue of trailing blanks appearing in a variable is a
slightly different issue than whether or not we knowingly put them there.
/Al
leew
would do it differently. Instead of setting the DAY variable through a
for command, why not just reference the %date% variable.
%date:~0,3% (assuming US-EN format).
So,
SET DAY=%date:~0,3%
(which basically says, start at the 0 character of %date% and take the
first 3 only).
-Lee
billious
"leew" <useCont...@LWComputing.dot.com> wrote in message
news:hsMKh.2975$w01....@newsfe12.lga...
Because the format of %date% is variable according to locale (sequence of
elements) and user-configuration (length, values and presence of elements)
For instance, on my machine %date:~0,3% returns "17/"
leew [MVP]
Fair enough - though that is why I noted "(assuming US-EN format)"