Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

1 Answer 1

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.

share|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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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