How big is your log file?

[vefatica]

I have used a history log (history.log) for as long as I can remember. It's useful to be able go back (for me, way back) and see how I did something. I suppose the following remarks will also apply to a command log.

A few weeks ago I noticed a delay between pressing <Enter> and seeing command output. I reckon it was between 1/3 and 1/2 second ... but it was troublesome. I'm confident that the delay had been growing for years (and I finally noticed it). My history log had grown to about 3.6 MB and that was the culprit. When I press <Enter>, TCC and Windows must open the file, map its contents, find the end of it, write to it, save it to disk, and close it. If it's 3.6 MB, that takes a noticeable amount of time.

So I copied history.log to history.txt and emptied history.log. The delay went away.

Later, I created a scheduled task which, every night, runs a BTM that appends history.log to history.txt and empties history.log. I'm confident that TCC will remain snappy.

That log probably goes back four or five years. I have a couple others, zipped up and tucked away; the older one of them was saved in 2004. So I wonder (especially about the many long-time users here) ... how big is your log file?

 

[rps]

I have used a history log (history.log) for as long as I can remember. It's useful to be able go back (for me, way back) and see how I did something. I suppose the following remarks will also apply to a command log.

A few weeks ago I noticed a delay between pressing <Enter> and seeing command output. I reckon it was between 1/3 and 1/2 second ... but it was troublesome. I'm confident that the delay had been growing for years (and I finally noticed it). My history log had grown to about 3.6 MB and that was the culprit. When I press <Enter>, TCC and Windows must open the file, map its contents, find the end of it, write to it, save it to disk, and close it. If it's 3.6 MB, that takes a noticeable amount of time.

So I copied history.log to history.txt and emptied history.log. The delay went away.

Later, I created a scheduled task which, every night, runs a BTM that appends history.log to history.txt and empties history.log. I'm confident that TCC will remain snappy.

That log probably goes back four or five years. I have a couple others, zipped up and tucked away; the older one of them was saved in 2004. So I wonder (especially about the many long-time users here) ... how big is your log file?

I set my log files in tcmd.ini to: LogName="%@path[%_cmdspec%]logs\TC%@formatn[02.0,%_day]_%_imonth%_%_year.log"
which names the log file based on today's date and TCC version. As the above illustrates they are stored in a log dir below the particular TCMD/TCC version.

So today's log file is - C:\JPSoft\TCMD21x64\logs\TC28_Aug_2017.log and it is small since today has barely started. The largest one this month is only 2,726,871 which didn't pose any problems.

In fact my largest one, this year, is 36,319,009 which is over 34 MB and I didn't notice any performance issues at the time. But I can say that things would have to really slow down for me to take notice and a typical daily log file is small (<MB).

3.6 MB doesn't seem out of line.
What do you log?
Do you have any aliases to sort through the logs and find what you're interested in?

 

[vefatica]

What do you log?
Do you have any aliases to sort through the logs and find what you're interested in?

I simply have history logging on, so it logs every unexpanded command line. I've often thought of making aliases to look through the log, but I haven't done so. Typically, I just

grep "something" h:\4ntlogs\history.txt

 

[vefatica]

In fact my largest one, this year, is 36,319,009

That's one day! You must have been using command logging and testing a large batch file (many times).

 

[rps]

Yep! I log everything in the daily file. So command history and errors as well as timed stamped items.

I did not look in that big file to see what was happening.

Since disk space is relatively cheep and very fast, why not log everything and search/sort what may be needed after the fact.

Refer to my suggestions and reply's to you in the suggestions forum. I am trying; to make what is logged more relevant, usable, understandable, and easier to find. As I pick and choose what is written to the log file, one of the biggest challenges is avoiding disk access/busy errors that can cause some things not to be recorded.

I did play around with logging literally everything (log /a); but that was a bit much even for me to sort through. I haven't given up, but need to develop some way to selectively turn /a on and off on-demand when it would be most useful.

If Rex takes my suggestion for an alias debugger, he could use the log as a place to deposit the relevant data. An alias debug log if you will. OH well, it will be interesting to see what's next.

 

[AnrDaemon]

I've used command log for ten years or so, but then I realised it is futile, I never looked through it except accidentally when stumbled upon the log directory.
And since I only used 4NT console for less than two years, I don't have any history log either. On another note, I regularly peek through bash history log, and even wrote a small piece of code to remove duplicates and often typed/hardly important commands to keep the history clean.
So far, 2k lines been enough for most hosts I care for.