#21 Echoing command line arguments in the log file
Hi!
For some reason I need to know the exact content of the command líne arguments (a copy) in the logfile for troubleshooting purposes.
I think it should be easy to implement and is a way to catch some errors in typing or in finding wrong passed arguments, as is the case with the following (an application running after hours):
2013.09.30 01:30:49 (Mon)------------Start of Session-----------------
Blat v3.1.1 (build : Feb 27 2013 20:04:23)
32-bit Windows, Full, Unicode
2013.09.30 01:30:50 (Mon): <<<getline<<< 421 Service not available, closing transmission channel
2013.09.30 01:30:51 (Mon): <<<getline<<< 421 Service not available, closing transmission channel
2013.09.30 01:30:53 (Mon): <<<getline<<< 421 Service not available, closing transmission channel
2013.09.30 01:30:53 (Mon): *** Error *** SMTP server error
2013.09.30 01:30:53 (Mon): Error: Not a socket.
2013.09.30 01:30:53 (Mon): Error: Not a socket.
2013.09.30 01:30:53 (Mon)-------------End of Session------------------
Where I don't know wat to look for.
Also, some times the log file get mixed lines from different sessions running the same application and wanting to send an email. This will show the resulting file:
2013.09.30 12:38:09 (Mon)------------Start of Session-----------------
Blat v3.1.1 (build : Feb 27 2013 20:04:23)
32-bit Windows, Full, Unicode
2013.09.30 12:38:09 (Mon): <<<getline<<< 250 Ok
2013.09.30 12:38:09 (Mon): >>>putline>>> DATA
2013.09.30 12:38:10 (Mon): <<<getline<<< 421 Service not available, closing transmission channel
2013.09.30 12:38:10 (Mon): <<<getline<<< 354 End data with <cr><lf>.<cr><lf>
2013.09.30 12:38:11 (Mon): <<<getline<<< 250 2.0.0 Ok: queued as 4ED71216E2BBC
2013.09.30 12:38:11 (Mon): >>>putline>>> QUIT
2013.09.30 12:38:11 (Mon): <<<getline<<< 221 Bye
2013.09.30 12:38:11 (Mon)-------------End of Session------------------
2013.09.30 12:38:11 (Mon): <<<getline<<< 421 Service not available, closing transmission channel
2013.09.30 12:38:13 (Mon): <<<getline<<< 220 us45.toservers.com ESMTP Postfix 2.8.0
2013.09.30 12:38:13 (Mon): >>>putline>>> EHLO serv-ibm
2013.09.30 12:38:13 (Mon): <<<getline<<< 250-towebs
2013.09.30 12:38:13 (Mon): <<<getline<<< 250-AUTH LOGIN PLAIN
2013.09.30 12:38:13 (Mon): <<<getline<<< 250 AUTH=LOGIN PLAIN
... and many more lines.</lf></cr></lf></cr>
As you can see, there is a line with 'End of session' in the middle, while there are more lines below from the same or different session.
This happens frequently.
My point of view is that Blat puts the lines one by one in the log as it gets; the solution could be put all the lines in batch at the end of the run.
Regards,
Claudio
I will see what can be done to get your command line options into the log file.
In the meantime, "421 Service not available" looks like the port number is incorrect for the selected SMTP server.
Interleaved blat logs indicates that you have told each instance of Blat to write to the same log. Blat does not have any semaphore logic for log file output, so you will need to have each instance write to different log files, or serialize the execution of each Blat instance.
Chip
Last edit: Chip 2013-10-12
I understand what you say, and changed the way it writes to the log file (changing the name each instance).
The "421" is something I can't identify, because the programm always use the default port number (25). This is turning us crazy, no one knows what happens with this (neither the hosting provider, nor the ISP or the tech boys that connects everything).
Thank you for the support and best regards!
Claudio
Your email to Cor'e was automatically blocked as SPAM because correspondence with Cor'e requires his SPAM Key to be placed in the email body or Subject line.
SPAM Key: =)
hi Parsiad,
I can't understand what you are trying to tell with the SPAM blocking and the term "Cor'e" (sorry).
Best regards,
Claudio
I had forgotten about this request until this morning. I have some code working to log command line options, but I have a question first. Should I log command line options always, or log the options only on demand using a new -logcmds option?
Chip