Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 637
  • Last Modified:

How do I run a bat file from script?

I currently have a .bat file written and is sitting in my c:\windows\scripts directory the file is called xcopy.bat

this is that script
@echo off
xcopy b:\*.* t:\SXE_BACK_UP\

The script works great but ONLY if I'm in CMD and CD'd to the B: directory.
I want to know how I can set up the script to copy the items from my B drive to the T drive so I can then set up a scheduled job to run this nightly.

Thanks
0
CGettler
Asked:
CGettler
  • 7
  • 7
  • 5
  • +3
4 Solutions
 
Bill PrewCommented:
There is nothing else you need to do to the script. You can just schedule it to run in the job scheduler, and specify the full path to the BAT file.

Naturally it only work properly if B and T exist and are accessible.

~bp
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
That's because XOPY is a built in command.  The PATH says to check the current directory first, then search all other directories in the path statement - so when you run XCOPY out of that folder, it uses the .exe - rename the batch file to myxcopy.cmd (or .bat - I prefer .cmd) or something that doesn't already have a command by the same name.
0
 
jbrown22Commented:
If it still doesn't work, then throw a CD B: command into your script just before the XCOPY command.
0
NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

 
Lee W, MVPTechnology and Business Process AdvisorCommented:
That won't work either - it won't execute a CD command if it can't first execute the script - further it would be just a simple B: - CD B: wouldn't do anything more than display the current directory on B:.

0
 
Bill PrewCommented:
leew, good catch on the BAT file name, somehow my eyes went right over that.  Although as long as windows\scripts wasn't in the PATH, then my answer would still work.  But it's bad practice to name BAT files with the same name as internal or windows supplied EXE program names, sooner or later will cause a problem.

There is no need to be in the B: drive as the current directory though since it is specified in the XCOPY command line.

~bp
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Good catch - I ALWAYS create a C:\Windows\Scripts folder (and for that matter, a c:\Windows\Utils folder) and add them to my system's path for easy access.  At which point the order of the path makes a difference.  That said, It could still have a problem, couldn't it, because the script is then essentially calling itself because both the script and command are named the same.
0
 
Bill PrewCommented:
Yes, if scripts were in the PATH, and ahead of SYSTEM32 (or whre ever xcopy.exe resides), then it would loop, agreed.

I think we all agree, the script should be renamed.  At that point my original reply should be all it takes to run the script, would you agree leew?

~bp
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Yeah, the script is fine assuming everything exists.  (I tend to go overkill and start putting in checks to error our and otherwise notify me of failures... but strictly speaking, if the folders/drives/files exist, that's all good.
0
 
CGettlerAuthor Commented:
Thanks for the info guys..

 But strange as it seems, the script does not run properly.

 I did as suggested, renamed the script to myxcopy.cmd, it is stored in my c:\windows\scripts directory.
I then set up a schedule to run that script at 12:30am.
I then go and right click on the job, and select run, and it shows as running but nothing is moving over. no files are showing up in my t:\SXE_BACK_UP\ directory.
But if I go in to cmd, then do a b: and hit enter, then do a c:\windows\scripts\myxcopy.cmd it starts to put files in the proper place.. Hmmmmmm any more adivse, should I d the b: xcopy trick in my script
0
 
Bill PrewCommented:
Was the command that you scheduled:

c:\windows\scripts\myxcopy.cmd

if so, add this on to the comand line, run it again, and check the LOG file for errors.

c:\windows\scripts\myxcopy.cmd >>c:\windows\scripts\myxcopy.log &2>1

~bp
0
 
CGettlerAuthor Commented:
bp

When I go in and do the scheduler, i do not see anywhere I can add this unless I should select show advanced and in the Run: field I paste in c:\windows\scripts\myxcopy.cmd >>c:\windows\scripts\myxcopy.log &2>1

Is that right?
0
 
Bill PrewCommented:
What version of Windows are you on, that sounds a little different than XP, or Win7, but the Task Scheduler has changed several times.  I believe that would be the right place though based on the way you are describing it.

~bp
0
 
BillDLCommented:
Try using the /L switch to "display files that WOULD Be copied" (ie. List the files) and observe as you double-click the batch file placed in any folder.

@echo off
xcopy "B:\*.*" "T:\SXE_BACK_UP" /C /D /E /H /I /L /R /Y
pause

You would probably also want the /D switch to overwrite older files in the destination.

xcopy /?
http://www.ekho.com/Training_Videos/XCOPY_NOTES.pdf
http://ss64.com/nt/xcopy.html
http://pcsupport.about.com/od/commandlinereference/p/xcopy-command.htm
0
 
Steve KnightIT ConsultancyCommented:
All sounds logical to me.... but B: and T: are they mapped drives by any chance?

If so they won't exist for the scheduled task unless you map them.

Try this:

@echo off
(
echo.
echo %time% start
echo B drive:
dir b:\
echo T drive:
dir t:\
echo SXE Backu_UP
dir T:\SXE_BACK_UP
echo %time% Complete
echo.
) >> c:\windows\scripts\log.txt
0
 
Steve KnightIT ConsultancyCommented:
(That was to try scheduled btw).

Steve
0
 
CGettlerAuthor Commented:
Bill Prew- I'm on Windows 2003 R2 64 bit.

BillDL I'll give the switches a try to see if I can see the files being listed. I do see the files in the cmd prompt when I run it that way.

Dragon - One drive is fibered in from our SAN, and the other drive (Drive B:) is mounted as a share from our AIX system through Samba. As I indicated above, it only appears to be working when I cd to the B: then run the c:/windows/scripts/myxcopy.cmd command. if I set up the schedule to run the myxcopy.com file it says running but does nothing to my directory.

I'll try some of the above suggestions and get back to you guys ASAP.

Thanks

0
 
Steve KnightIT ConsultancyCommented:
Then the B: drive will most likely not exist for your batch file.  Suggest you add a net use or better pushd command then to access it:

@echo off
net use b: \\aixserver\share
xcopy b: etc.
net use b: /delete

or this will create a new drive, generally Z: mapped to the share you give, remove it afterwards and keep a log for you:

@Echo off
(
echo %date% %time% Started
pushd \\aixserver\share
xcopy . t:\SXE_BACK_UP\
echo %date% %time% Finished
) > c:\windows\scripts\myxcopylog.txt 2>&1

The account that the scheduled task is set to run as of course will need to be able to authenticate with your AIX box and have suitable permissions.  If you need to specify a username / password at the moment instead of using domain credentials then we'll have to pop those in a net use command ...

0
 
Steve KnightIT ConsultancyCommented:
Oops, dropped the popd in my copy/paste.... less haste and all that:

@Echo off
(
echo %date% %time% Started
pushd \\aixserver\share
xcopy . t:\SXE_BACK_UP\
echo %date% %time% Finished
popd
) > c:\windows\scripts\myxcopylog.txt 2>&1
0
 
CGettlerAuthor Commented:
BillDL copied your script and tried to run it through scheduler and got nada. then tried to double click on the .cmd file that is located in c:\windows\Scripts and I get the cmd screen but nothing shows on it. I'll let it run for a bit just to make sure, but for some reason I think the only way this xcopy thing is going to run is if the myxcopy.cmd file is stored on the B: drive, or if I do it manually as the windows task schedular isn't having much luck running it as I had hoped.

:(
0
 
CGettlerAuthor Commented:
DAMN OK I think we're getting close.. I put in the

@Echo off
(
echo %date% %time% Started
pushd \\aixserver\share
xcopy . t:\SXE_BACK_UP\
echo %date% %time% Finished
popd
) > c:\windows\scripts\myxcopylog.txt 2>&1

in the script and now I get a log file.. the log file says...

Thu 09/15/2011  6:52:41.02 Started
Overwrite T:\SXE_BACK_UP\nxtbk.4 (Yes/No/All)?

But I do not see this prompted on the screen. So I thought I would add in the /D switch behind xcopy . t:\SXE_BACK_UP\ and then tried again and got the same results.

the file nxtbk.4 is one of my files, one of 20, so I know it's atleast grabbing the file from the AIX system and now trying to overwrite the existing file on the windows T: drive.

Thanks any idea how I can always push out a YES for all files?!


0
 
Steve KnightIT ConsultancyCommented:
Add /Y

Would suggest:

/D - copy only if newer
/Y - always overwrite
/C - continue if errors occur
/V - verify

You MAY also want to add
/H - copy hidden/system files if needed
/R - overwrite read only files if needed


Steve
0
 
Steve KnightIT ConsultancyCommented:
If the files have the same names but change each day then use /Y but not /d.
If some files stay the same then adding /d will stop it copying those when already there.

Steve
0
 
CGettlerAuthor Commented:
Thanks for all that helped out. It was a combo of solutions that helped me get to the proper settings.
Thanks Dragon for the additional script and prompt info this AM on the switches. I dropped the /D and went with the /Y and all is fine now. It had problaby always been prompting me that, but was unable to tell due to no log fine until your script helped that.

Thanks

Chip
0
 
Steve KnightIT ConsultancyCommented:
No problem.  As you say, couple of things, and glad you have it working now.

1. called it xcopy, could be infinite loop.
2. May have been prompting for overwrite
3. Quite possibly B: drive not available at all as source

Steve
0
 
CGettlerAuthor Commented:
Thanks Dragon It is working like a champ now. :)
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 7
  • 7
  • 5
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now