I have a user logon script that copies a file over to a subfolder of the current user's profile path:

Script (only showing the line that isn't working):

copy /Y c:\records\javasettings_Windows_x86.xml "%USERPROFILE%\Application Data\OpenOffice.org\3\user\config">>c:\records\OOo3%USERNAME%.txt 2>&1

To diagnose why it wasn't working, I did a >somelogfile.log parameter on the group policy script and found that what the above command is translating to is this:

C:\WINDOWS>copy /Y c:\records\javasettings_Windows_x86.xml "C:\Documents and Settings\test2\Application Data\OpenOffice.org\3\user\config" 1>>c:\records\OOo3test2.txt 2>&1

So the question is, how do I get rid of (exorcise) the " 1" in that line?

Update 1:

So the reason the script wasn't working was that the creator didn't have any permissions on the directory. I fixed the permissions, and now the file works but! I still have the " 1" showing on all the logs and would like to know why.

link|improve this question

77% accept rate
feedback

1 Answer

up vote 1 down vote accepted

The shell is doing what you're asking it to. A redirection, like your >> with no handle number specified is assumed to be a redirection to handle 1, which in the case of output is standard output. When the shell parses a batch file and finds "naked" redirections it adds the handle number when echoing the command. It's just an implementation quirk of the shell.

link|improve this answer
Aha! That would explain why it turned out to have no ill effect on my script. And here I thought it was evil. Thanks for clearing that up for me. – Detritus Maximus Jan 12 '11 at 17:42
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.