I have a client who have relied on Blat for many years. Until recently they were on an old version (2 point something) but, as they're upgrading all their systems, they've just gone up to 3.2.10.
They send emails via a batch file, one component of which is the -af switch. The attachments file may be empty or it may contain a list of attachments, it all depends on the circumstance.
The old version seemed to be perfectly happy with the empty attachments file but the new one gets most upset: it complains that it can't find anything matching the search string "[square block character]" and stops.
I created an empty filelist.txt that contains only a carriage return / line feed, and I do not see any issue when I used -af filelist.txt. I also tested with a zero length filelist.txt, still no issue.
If possible, please get a copy of your client's empty attachment list file so I can reproduce the issue and get it fixed.
Thanks,
Chip
Last edit: Chip 2015-11-20
Hi Chip,
Thanks for the reply. I've reproduced the issue on my machine here so it does seem to be transportable. I can run the test batch file with Blat 2.6.2 and all is well, but with 3.2.10 I get the error message.
I've attached the emplty attachments file.
I've found that if I put a comma into the attachments file, rather than leaving it completely empty, then it will work. I've been planning to use this as a workaround if all else fails.
The test batch file that I'm using is as follows:
"C:\Program Files (x86)\Blat\blat.exe" "c:\program files (x86)\Blat\temp\blatmail.txt" -af "c:\program files (x86)\blat\temp\attach.txt" -to xx@xxx.co.uk -subject "Blat test" -server smtp.xxx.co.uk -u xxx -p xxx -f xx@xxx.co.uk -priority 1
Thank you. I see that your file is an empty Unicode file, where I was using an empty ASCII file. This gives me something to look at. :)
Chip
I found the issue, I was not handling an empty Unicode string properly. Here is a new 32-bit executable to check out. If this works for you, as I expect it will, then I will get this new version posted for general download.
Chip
Last edit: Chip 2015-11-20
Excellent, many thanks for the quick response - I'll give it a go first thing in the morning and let you know how it goes.
Hi Chip,
Yes, that has indeed fixed it.
Something else with the new version is going to give us difficulty though, and this seems to be more of a design decision - if it can't find an attachment in the path it just refuses to send the email.
We're calling Blat from within another program, and the users never see Blat's messages. In this case then, they will think that they've sent an email but in fact they won't have done. This is far worse than sending the email with no attachment!
Would it be possible to add a switch to override this?
Many thanks,
Rob
To make sure I understand correctly, you would like to have a new command line option that tells Blat to go ahead and send the email even though it is unable to locate the named attachment file. Such a new command might be -IMAF to Ignore Missing Attachment Files. Along with this, you would like to continue to see "No files found matching search string "NonExistentFIle.txt"" added to the log file that indicates a file was not found, where NonExistentFIle.txt is the requested filename that was not found,
Chip
Yes, that would fit the bill perfectly. Thanks.
Last edit: robert widdicombe 2015-11-22
If your clients want to continue with version 3.2.11, and if an attachment file is missing, Blat will exit with value 12. The client can check the return code after Blat to know if Blat succeeded or failed. A zero means Blat finished successfully. A non-zero value means there was an error.
Here is the 32-bit Full executable to check out, it supports the -imaf option.
Chip
Hi Chip,
That's great - many thanks for doing that so quickly. I've tested it and it's working fine.
It's handy to know about the return codes, but in this case I'll just use 3.2.12 with the -imaf flag as a simple drop-in replacement for Blat 2.6.2.
Thanks again,
Rob
Last edit: robert widdicombe 2015-11-22