Delete file if > than n bytes

[kriemer]

What the script is doing is creating a "rolling log" (which we all know "gathers no moss").

The purpose of the log is to record determine how many processes have failed in another part of the MS script. I am not very interested in success in the far past; but recent and repeated entries of failures indicates something has changed and scripts may have to be modified to handle that change.

Deleting the oldest records also keeps the log to a manageable size.

That the idea at least.

Thanks for your thoughts.

k

[gdyvig]

Another simple way is to include the date in the name of your logfile. Then manually or with another script purge the old logfiles.

Gale

[JRL]

Also.... remember there is a relatively new system variable to help control the information written to your log files.

_WRITE_LOG_FILE Set to 0 to temporarily disable logging. Set to 1 to enable.

Possible example usage:

Code: Select all

//Script

//Stop logging
Let>_WRITE_LOG_FILE=0

Let>kk=0
Repeat>kk
  Add>kk,1
  ///A bunch of stuff that doesn't need to be logged
  ///Times 1000
Until>kk=1000

//Continue logging
Let>_WRITE_LOG_FILE=1

//More script

[kriemer]

Just discovered that the TAIL command does not work in a 64bit environment. The output file is created but it is empty.

Sigh of disappointment.

k

[JRL]

Does "more +n" work in 64bit Windows?

[kriemer]

Actually I was about to edit my last message.

Tail does work when running directly in the cmd window, i.e.,
cmd.exe /c tail -5000 "C:\Users\1Log">"C:\temp.Log". But when run from within MS it just creates an empty temp.log file.

Any ideas as to why this might be.

I am now using the looping script previously mentioned. I will dig into the dos more command and see what that does.

k

[Bob Hansen]

Just found this ( http://stackoverflow.com/questions/3733 ... e-specific ), it might help:

Explorer (which is itself a 64bit process on Vista64) launches 64bit command prompts by default. If you want a 32bit CMD.EXE, you much explicitly reference C:\Windows\SysWoW64\CMD.EXE.

The reason this worked fine on my system is that I use Far Manager for most of my command-line usage, which is 32bit (therefore it launches 32bit Command Prompts).

This sounds like your system has both a 32 and 64 bit cmd. Try adding the full path to the 32 bit cmd in your tail command. I don't have 64 bit, so cannot test this. I would be inclined to make copies of each of the cmd.exs files and rename them cmd_32.exe and cmd_64.exe and use those names in my scripts to make sure I called the correct one.

Is it possible to have your system use them in a priority order? Or at least choose which of the two should be the default?

Here is another link that seems to be more focused to the possible cause and solution: http://www.winvistatips.com/syswow64-re ... 35349.html

[kriemer]

Interesting and simple solution.

It appears that even if tail.exe is located in a folder that is in a path, its location must be specified in the script in order to work. This means that at least for Win 7 64 the code must read:

Run>cmd.exe /c C:\some location\tail.exe -n "C:\Users\File1.Log">"C:\Users\File TEMP.Log"

And there it is (I hope).

Thanks for the continued help.

k