Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Dating logs

Nov
31
0
I lack even basic knowledge of dos and batch files, but have groped my way to writing a command line script(?) for running chkdsk and appending the output to a log file. That is:
C:\WINDOWS\system32\cmd.exe /C chkdsk Z: /f /X >> "d:\chkdsklogs\Zchkdsk.log" .

This will run in the windows scheduled tasks and appends to a log on my D drive. And it has proved to be useful in detecting and locating problems with hard drives.

However, I have yet to work out how I can amend the command or script, if that is the correct term for it, so that when the task runs it will also add to the log the date and time when the log is appended. Can I do it by amending the command line above, or would I need to run a separate scheduled task to add the date?

I was hoping that I might find a way of achieving that result, preferably so that I end up with a single scheduled task, using Take Command, but I am afraid that the language in the help file assumes a degree of knowledge that I do not have and can see no available way to acquire. Can it be done via Take Command, and if so how?
 
Here are some short keywords/samples:

%_isodate returns the date on format YYYY-MM-DD (useful for sorting) see http://jpsoft.com/help/index.htm?_isodate.htm
%_datetime return both date and time - YYYYMMDDHHMMSS see http://jpsoft.com/help/index.htm?_datetime.htm
If you want the filenames to contain the date, you could use this command:​
C:\WINDOWS\system32\cmd.exe /C chkdsk Z: /f /X >> "d:\chkdsklogs\Zchkdsk-%_isodate.log" or
C:\WINDOWS\system32\cmd.exe /C chkdsk Z: /f /X > "d:\chkdsklogs\Zchkdsk-%_datetime.log" (append not relevant in this case)
If you would like to add the date in the logfile (before/after):

echo CHKDSK Z: started at: %_datetime >> "d:\chkdsklogs\Zchkdsk.log"
C:\WINDOWS\system32\cmd.exe /C chkdsk Z: /f /X >> "d:\chkdsklogs\Zchkdsk.log"
echo CHKDSK Z: finished at: %_datetime >> "d:\chkdsklogs\Zchkdsk.log"
Good luck!​
-stein​
 
Thank you so much for that. I am looking forward to investigating your suggestions. In the mean time, is it the case that by adding '-%_datetime' to the end of the script immediately before '.log' the date and time will be added to the file name if but only if Take Command is installed, and notwithstanding that Take Command would not be running at the time when the scheduled task runs, so that installing Take Command has extended the range of commands available in dos?
 
Everything in my answer is based on Take Command, I seldom use CMD.EXE.

If you create a batchfile, typically c:\batch\chkdsk-z.btm containing the command(s), then you must enter the following into scheduled task:

Program name: d:\path\tcc.exe
Parameter: /c c:\batch\chkdsk.z.btm

CMD.EXE has a %DATE% variable formatted as DD.MM.YYYY (with my regional settings), but comparing CMD.EXE to TCC.EXE is like Lada vs - Tesla ??

Please note that you can use TCCLE version 13 for free, but I would really recommend Take Command version 14.
 
Thanks for your further comment about the batch file approach. I read that as meaning that the batch file would be run by running tcc.exe with a 'parameter' to instruct tcc.exe to execute the instructions in the batch file, but where do I enter the parameter? There is no box therefore in the properties dialogue for a scheduled task in xp pro.

Secondly, I wonder whether you could answer my question:
Is it the case that by adding '-%_datetime' to the end of the script immediately before '.log' the date and time will be added to the file name if but only if Take Command is installed, and notwithstanding that Take Command would not be running at the time when the scheduled task runs, so that installing Take Command has extended the range of commands available in dos? In other words, if I merely enter the following command in the 'run' box of my scheduled task, in order for the command to work correctly, do I need to have Take Command installed, and if so do I need to have it running?
C:\WINDOWS\system32\cmd.exe /C chkdsk Z: /f /X > "d:\chkdsklogs\Zchkdsk-%_datetime.log"
 
Sorry, I made a mistake in my first reply:

a) C:\WINDOWS\system32\cmd.exe /C


should (of course) be written:

b) D:\path\tcc.exe /C

Where d:\path is the installation folder of Take Command. Please note that when TCC.EXE
is installed it can be considered a replacement of CMD.EXE, not an addon.
Since your command include redirection I would recommend to put the command in a batch file as described earlier.

>so that installing Take Command has extended the range of commands available in dos?
Please note that:
- Windows XP console mode is NOT DOS, but similar to DOS, and CMD.EXE is similar to COMMAND.COM
- The predessor of Take Command was 4DOS - now freeware/open source included in FreeDOS - http://www.freedos.org/software/?prog=4dos
- TCC.EXE can be started directly from Windows or launched from CMD.EXE
- You can also launch TCC.EXE from CMD.EXE
- Take Command Wiki page: http://en.wikipedia.org/wiki/Take_Command_(command_line_interpreter)

The command ver /r will show you which shell you are using.

In Windows 7 there are separate fields for for command and parameters, as shown attached.

It is useful to know the basics of Windows command line and batch files before/while you dig into Take Command.
For example, the Windows task scheduler can be controlled from the command line as described here

There are many free tutorials on the net - for example: http://commandwindows.com/batch.htm

My advice: Go ahead and try some basic things first....

Good luck.

-stein
 
Thanks again. That clarifies a lot.

You say:

"The command ver /r will show you which shell you are using.

In Windows 7 there are separate fields for for command and parameters, as shown attached."

What do you mean by shell?

What do I do in XP, given that there is not a separate filed for parameters in the Scheduled tasks gui in XP?

I could find nothing "attached". What were you referring to?
 
Thanks for your further comment about the batch file approach. I read that as meaning that the batch file would be run by running tcc.exe with a 'parameter' to instruct tcc.exe to execute the instructions in the batch file, but where do I enter the parameter? There is no box therefore in the properties dialogue for a scheduled task in xp pro.
No, neither TCC nor TCC/LE would require a parameter other than what you can specify when you schedule it. In WinXP you enter the whole command line in the "advanced" tab of scheduling, e.g.

Code:
c:\jpsoft\v14\tcc.exe /@c:\jpsoft\v14\tcmd.ini /c c:\schedules\scheduled.btm

This assumes that
Code:
c:\jpsoft\v14
is the directory where TCC or TCC/LE is installed, and it uses the default location and name for its option file, and further, that
Code:
c:\schedules\scheduled.btm
is the name of the batch file you want TCC to execute when its scheduled to run.

Secondly, I wonder whether you could answer my question:
Is it the case that by adding '-%_datetime' to the end of the script immediately before '.log' the date and time will be added to the file name if but only if Take Command is installed, and notwithstanding that Take Command would not be running at the time when the scheduled task runs, so that installing Take Command has extended the range of commands available in dos? In other words, if I merely enter the following command in the 'run' box of my scheduled task, in order for the command to work correctly, do I need to have Take Command installed, and if so do I need to have it running?
C:\WINDOWS\system32\cmd.exe /C chkdsk Z: /f /X > "d:\chkdsklogs\Zchkdsk-%_datetime.log"

First, remember that the Take Command package consists of two main elements:

1/ TCMD, which allows multiple "console" programs to run in different "tabs" of the TCMD window. The tabs are similar to the tabs in Internet Explorer and in Mozilla Firefox. The most common "console" program used under Windows is CMD.EXE. By itself TCMD does not do anything, it just provides a more convenient access to multiple "console" programs executing concurrently. You would normally have only a single TCMD window open on your desktop, and that one window could run multiple independent instances of many different "console" programs.

2/ TCC, which is a "console" program, and is a superset of CMD.EXE, with literally more than a hundred times the features of CMD.EXE.

3/ TCC/LE is a "limited edition" of TCC.EXE, with still many more features that CMD.EXE. though much less than TCC.EXE. It is another "console" program.

Neither TCC nor TCC/LE enhance what CMD.EXE can do. They are alternates that you use instead of CMD.EXE.

If you want each scheduled run to generate a separate log file with the date and time part of running part of the logfile's name, you must specify the name in the batch file executed by the scheduled running of TCC, because the TCC internal variables are not available to the scheduler itself.
Below is a possible content of scheduled.btm:

Code:
%_comspec /C chkdsk.exe Z: /f /X > "d:\chkdsklogs\Zchkdsk-%_datetime.log"
for generating individual log files (this assumes that chkdsk.exe is on your path, which is the default).
--
HTH, Steve
 
Execute the current command processor, with the /C option (which causes it to terminate when the command [or program] it executes terminates). This option behaves identically in CMD and TCC (by how TCC was designed).
 
Thank you again. Things are getting clearer.

What does "%_comspec /C" do?
Probably nothing! Typically there is no _COMSPEC variable. I think Steve meant
Code:
%COMSPEC /C ...
The variable COMSPEC refers TCC itself. Here, it's
Code:
v:\> echo %comspec
G:\TC14\TCC.EXE
Steve's example starts a new TCC asking it to run CHKDSK. The "/C" option causes the new TCC to exit when it's done executing the command.
 
Sorry, I indeed meant %comspec (without the underscore). The purpose of starting a second instance of the command processor is to force redirection; some programs do not permit their output to be redirected. CHKDSK.EXE as implemented in WinXP SP3 (32b) can be fully redirected, so the second command processor instance is not required. The simplified command to create a new log file for each time the scheduler runs the task:

content of scheduled.btm:

Code:
chkdsk.exe Z: /f /X > "d:\chkdsklogs\Zchkdsk-%_datetime.log"
 
Thanks for all your advice. It will get me started, and I am looking forward to being able to do all this.

I think you are saying that "%COMSPEC" means "D:\path\tcc.exe" where d:\path is the installation folder of Take Command. Is that right?

What does "/@c:\jpsoft\v14\tcmd.ini" mean?

I am afraid I did not follow what you meant by
Here, it's
Code:
v:\> echo %comspec
G:\TC14\TCC.EXE
 
Thanks for all your advice. It will get me started, and I am looking forward to being able to do all this.

I think you are saying that "%COMSPEC" means "D:\path\tcc.exe" where d:\path is the installation folder of Take Command. Is that right?

What does "/@c:\jpsoft\v14\tcmd.ini" mean?

I am afraid I did not follow what you meant by
Here, it's
Code:
v:\> echo %comspec
G:\TC14\TCC.EXE
Each version of TCC sets the environment variable COMSPEC to itself (drive:\path\tcc.exe).

"/@path\inifile" is a mechanism for starting TCC with an INI file other than the default one.
 
Thanks Vefatica.

Are you saying that tcmd.ini iinstead of the default .ini file is required to initiate the processing of a batch file?

To run a batch file, Stein suggests at #4:
Program name: d:\path\tcc.exe
Parameter: /c c:\batch\chkdsk.z.btm
But at #8, for the same purpose Steve suggests:
c:\jpsoft\v14\tcc.exe /@c:\jpsoft\v14\tcmd.ini /c c:\schedules\scheduled.btm

Does it follow that Stein would use the default .ini, but that Steve would use a different one - tcmd.ini - and, if so, why is that?
 
Thanks Vefatica.

Are you saying that tcmd.ini iinstead of the default .ini file is required to initiate the processing of a batch file?

To run a batch file, Stein suggests at #4:
Program name: d:\path\tcc.exe
Parameter: /c c:\batch\chkdsk.z.btm
But at #8, for the same purpose Steve suggests:
c:\jpsoft\v14\tcc.exe /@c:\jpsoft\v14\tcmd.ini /c c:\schedules\scheduled.btm

Does it follow that Stein would use the default .ini, but that Steve would use a different one - tcmd.ini - and, if so, why is that?
Yes. The default one is also named TCMD.INI. Steve has others, in different locations. He seems to have a greater need for alternate INI files than most users. One is enough for me. Since we're talking about scheduled tasks ... if the task were run with other-than-normal credentials, the default INI file, which can be in a user's profile tree, might not be found. Steve can probably explain better than I can.
 
Thanks Vefatica.

Are you saying that tcmd.ini iinstead of the default .ini file is required to initiate the processing of a batch file?
No, the default one is usually OK for all uses, esp. interactive work. However, you may find it useful for special (usually non-interactive) applications, such as scheduled tasks, to provide a different operating environment.

To run a batch file, Stein suggests at #4:
Program name: d:\path\tcc.exe
Parameter: /c c:\batch\chkdsk.z.btm
But at #8, for the same purpose Steve suggests:
c:\jpsoft\v14\tcc.exe /@c:\jpsoft\v14\tcmd.ini /c c:\schedules\scheduled.btm

Does it follow that Stein would use the default .ini, but that Steve would use a different one - tcmd.ini - and, if so, why is that?

1/ I (Steve) used a specific sample path, c:\jpsoft\v14, to indicate the location of TCMD's installation, Stein a generic one - d: to indicate drive, and path to indicate path. They both mean that you need to specify the fully qualified name of the program (TCC) that the scheduler must execute.

2/ The format Stein used is for the Windows 7 scheduler application, which splits the command line to start the program into Program Name and Parameter (analogous to the way Explorer displays shortcut properties). Mine is for WinXP, in which the scheduler requires the same format as the run dialog, a full command line. Furthermore, I included in the command line /@c:\jpsoft\v14\tcmd.ini, the way in which the .INI file can be specified in case your scheduled task needs one other than the default (most likely it can use the default one, so this element of the command line is not needed).
--
HTH, Steve
 
Back
Top