Member Avatar for arishy 
From the script below, the commented part of the script is to prevent the script from hanging. The script as is , is working once I uncomment the openning of the file to retieve the body of the email, the script hang.    

  use Email::Send;
use Email::Send::Gmail;
use Email::Simple::Creator;

# open the file that contains the body of the email
# local $/ = undef;
# open(FH,'<','body.txt') or die "file does not exists $!";
# my $body=<FH>;
# close(FH); 

  my $email = Email::Simple->create(
      header => [
          From    => 'arishy@gmail.com',
          To      => 'arishy@gmail.com',
          Subject => 'testing sent mail to gmail',
      ],
      body => 'this is the body that works',
      ## if I uncomment the openning of a file to get the body of the email
      ## like this  body => $body,
  );

  my $sender = Email::Send->new(
      {   mailer      => 'Gmail',
          mailer_args => [
              username => 'arishy@gmail.com',
              password => 'xxxxxxxxx',
          ]
      }
  );
  eval { $sender->send($email) };
  die "Error sending email: $@" if $@;
  • 2 Contributors
  • 2 Replies
  • 343 Views
  • 4 Days Discussion Span
  • Latest Post Latest Post by arishy

Dani AI

Generated

A short, focused note that builds on the thread:

’s slurp-inside-a-limited-scope approach is the right fix for the immediate hang that saw. The underlying cause is that changing Perl’s input-record-separator at a broad scope changes how all subsequent reads behave; if that change isn’t confined to the smallest possible scope, later code and modules that read handles or expect line-oriented input can behave unexpectedly.

Practical alternatives that avoid that class of bug: use a purpose-built slurp helper (modules that return the file contents and handle encoding/closing cleanly), or perform the “read whole file” operation inside a deliberately small scope so the altered input-separator does not leak into the rest of the program. That removes the interaction between the file-read logic and the mail-sending logic and keeps life simple.

About the bank-report problem: WWW::Mechanize does not execute client-side JavaScript, so differences between browsers usually indicate the page or report is built in the browser (XHR/JS). First step is to inspect the browser’s network/XHR activity to see whether the report data comes from a direct URL or API that can be requested programmatically. If there is no useful API, use a real browser engine for automation (headless Chrome/Firefox via Selenium, or a chrome-based Mechanize wrapper) to perform the login, wait for rendering, and capture the generated DOM or exported data. Beware of MFA, bank terms of service, and credential handling — avoid hardcoding passwords and prefer app-specific credentials or environment variables.

Quick troubleshooting checklist to add: confirm the slurped text’s byte length and sample before send, ensure file I/O uses the correct encoding, enable mailer debug logging when testing, and try sending a minimal test body then increase complexity. These steps make it easier to isolate whether the problem is file-reading, encoding, or the mailer/transport.

Recommended Answers

All 2 Replies

Member Avatar for 2teez

Hi,
for your codes line numbered 7-11, replace with this:

#open the file that contains the body of the email
open(FH,'<','body.txt') or die "file does not exists $!";
my $body=do{ local $/ = undef;<FH>};
 close(FH);

then code line numbered 19-21 then do this:
body => $body,
it should work.

Member Avatar for arishy

As expected, worked.!!
This is a very hard to find bug, T thought the local $/ = undef, was enough to get the whole file ( which it did !! I checked that...) but this action affected the next part of the script; The object $mail DID NOT SEE the $body and it hanged.

Just to give you an idea why I am doing all that in case you advice me to change it.
I am accessing my bank statement using Mechanize, but the content I get is not what the statement shows ( very heavy JS stuff). If I go manually and login and save the page with IE I get nothing, but with firefox I get the report. (very weired). I need the data from the report to come up with proper anaylsis that the report does not give me.
So, I decided to get in manually (sadly) and select the report copy it to a text file.
That was ONE of the files that I read by the script I listed.
The full script takes the "body" do some calculations ( a lot ) then send me an email with the "proper" reporting.

As you can see, I am doing all the hard work manually which I do not like. I have the script that goes automatically to my account and retrieve the report ( rubbish).

Because of my lack of experience in tackling this high level debugging I am stuck with the manual way.

My hope really is to retieve the report data but I do not how ( the idea that firefox managed to save the report properly, give hope that it is possible ) what do you advice me to do.

Thank you again for you help and wonderfull support

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.