Jump to content
Sign in to follow this  
Chiphead

...is not recognized as an internal or external command

Recommended Posts

Chiphead

I have been using AutoIT "lightly" for several years now and I finally have a problem I couldn't find the answer for using search.

So here goes my first post.

Environment and issues:

I am trying to execute Robocopy as the "first step" in a script I am developing

I am testing as I go and executing the script on the machine that will eventually run the script regularly.

The "host" machine is a W2K3 Enterprise R2 x64 machine with all SPs and Hotfixes.

AutoIT v3.3.0.0 (no Beta installed)

I am using a compiled EXE since this will be the format when I am finished.

The machine that I am writing and compiling the file on is a Win7 x64 box with all the latest updates.

The "environment" and process is as follows:

On the server that will execute this script, I am "robocopying" files from a NAS using UNC to a mirrored folder on a local drive of the server. (Z:\Mirror). I use the resulting log file to determine what files are "new". The log file is later parsed and turned into a list of file to compress.

My problem is in executing robocopy. Unless I put robocopy in the script directory I cannot get it to run.

I am trying to make the script "portable" and not need to include robocopy with it. Therefore, ideally, I would like the script to execute using robocopy in its "default" location, C:\Windows\System32, which is "the same" on every Server/workstation in our environment. Or, if that is not possible, then have the script check for the existence of Robocopy, copy it into the script folder, execute and then delete it when it is finished. Since Robocopy is located in a folder in the %PATH% on the server I can run it manually from a command prompt or a CMD file without issue. AutoIT however is not finding it in the path for some reason.

No matter which of the following scenarios I use they will fail with the same error message.

'"C:\windows\system32\robocopy.exe"' is not recognized as an internal or external command, operable program or batch file.

Scenario 1) Execute robocopy in place in the C:\Windows\System32 directory

I have used Run() RunWait() with and without specifying the complete path to the executable. FAIL

I have tried to set the working directory to both 'C:\Windows\System32' and directly to the script directory. FAIL

I have tried to create a CMD file which points directly to the C:\Windows\System32\robocopy.exe, and execute it at a Run() RunWait() command. FAIL

If I manually run the CMD file that I create it executes PERFECTLY.

Scenario 2) Execute robocopy from the script directory by copying it into the script directory first.

If I manually copy robocopy to the script directory it will execute it from Run() or RunWait() and from a CMD file.

If I use FileExist() and tell it to look for it in the C:\Windows\System32 directory, and copy it to the script directory it doesn't find it and it doesn't copy it. I've been using a msgbox() to tell me if it finds it or not.

I have tested Scenario 2 on another machine (WIN 2K3 R2 x86, latest SP and HF) and it too says it is "Not Found" BUT, it DOES copy the file into the script directory. ???

I am contemplating using StdOutRead and StdErrRead... to see what I can see but

1) I have never done this before and am not comfortable enough to wade out into that just yet

2) It looks like an environmental path issue to me and not a robocopy execution issue so I don't think (know) if there will be anything to capture and,

3) I have been scouring the forums for the last 3 days trying to figure this out and I think it's time I ask for some help.

All of the things that I found in the forums weren't quite my problem. The posts that I saw seemed to be related to working directory issues (which I don't THINK I have) or spaces in the paths (which I do not have). I have also tried putting quotes around robocopy string just in case but to no avail.

I will post my code if you want to see it but I was hoping for a suggestion on "the best method" first or, maybe someone can tell from my environment that there is a "known issue" that I an not aware of that is preventing me from being successful.

(Besides, with all of the testing I have done the code is a mess) :D

Ideally I would like to not have to move the file and just execute robocopy in-place in the system32 directory so if anyone knows how I "should" be able to make that work or what I am doing wrong, please let me know.

Thanks In Advance

Share this post


Link to post
Share on other sites
junkew

what is

runwait("c:\windows\system32\xcopy.exe")
run("c:\windows\system32\xcopy.exe")

doing?

If FileExists("c:\windows\system32\robocopy.exe") Then
    MsgBox(4096, "File", "Exists")
Else
    MsgBox(4096, "File", "Does NOT exists")
EndIf
Edited by junkew

Share this post


Link to post
Share on other sites
Chiphead

what is

runwait("c:\windows\system32\xcopy.exe")
run("c:\windows\system32\xcopy.exe")

doing?

If FileExists("c:\windows\system32\robocopy.exe") Then
    MsgBox(4096, "File", "Exists")
Else
    MsgBox(4096, "File", "Does NOT exists")
EndIf

The "If FileExists...." command returns a "Does NOT exist" Message Box when looking for robocopy.exe BUT if I tell it to look for xcopy.exe it DOES find that.

I also had it find a renamed version of robocopy.exe (xcopy2.exe) and it again DOES NOT find it.

I am not sure of the best way to capture the results from the Run() RunWait() versions of the xcopy but if I FileWrite the command to a CMD file and execute it through the script xcopy is found, will "run", and gives the expected output of "Invalid number of parameters" @LF "0 File(s) copied".

Now I am more confused.... :D

Just for giggles I tried to copy the renamed robocopy.exe (xcopy2.exe) and I get the same error as with robocopy.exe (not really surprised)

Obviously there is something surrounding the robocopy EXE. Any ideas?

Share this post


Link to post
Share on other sites
Chiphead

"Problem" solved! :D

The short answer: Playing with 32bit in a 64bit world.

I discovered the problem when recalling a result from earlier testing where I was using '@SystemDir' to specify the path to robocopy.

As stated in my first post I have been compiling the exe when testing, this is because of not having AutoIT installed on the "host" machine and not wanting to have to include AutoIT3[_x64].exe along with a script while testing. Also, since this machine is really the only machine in our business that is running x64 O/S I compiled the exe as 32bit in keeping with the desired portability.

Herein lies the problem. When executing a 32bit app on a 64bit O/S C:\windows\system32 is redirected? symlinked? to C:\windows\SysWOW64 :huggles: soooo..... even with the path "hardcoded" in the script it was being re-pointed to C:\Windows\SysWOW64 and, of course, there WAS NO robocopy.exe file to be found there.

Put a 32bit robocopy.exe into the SysWOW64 folder and VOILA!! script works, go figure. :

Also, I copied the robocopy.exe files from my Win7x64 machine to their respective folders and recompiled the exe in x64 to verify and it seems to be working as it should.

Will update the post if I find any other problems with this.

@AutoITDevs

Suggestion: Modify the help file to explain that system variables(macros) (specifically @SystemDir) may also point to their 32bit counterparts (in this case C:\Windows\SysWOW64) if you are executing a 32bit app on a 64bit O/S.

Regards,

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.