CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
Search Posts SEARCH
Who's Online WHO'S
Log in LOG

Home: Perl Programming Help: Intermediate:
How to pass string msg from called from



Jul 14, 2014, 5:56 AM

Post #1 of 5 (4524 views)
How to pass string msg from called from Can't Post

  • Perl 5.8.8 on Linux RHEL 5.5.56.
  • I don't think the use of modules is a good idea since I know nothing of writing modules, in fact I'm just learning to use modules and hash refs and array refs. I do not have time to learn modules, but perhaps later.
  • I'm trying to keep this simple. Not using modules, and using separate .pl files, is a good solution for us at this time.

    I have a Perl program,, which reads an email, and based on that email, determines which other Perl script to call, like also opens its own log/error file. So if program gets called, and has an error, I want to pass an error string back to, so I can log it to the same log file is using. This will help centralize error messages to one file.

  • Can exit do that? If not, how can I do this?

  • I know exit returns a numeric code, sometimes negative, so if that's all I can do, it's acceptable. But surely people can understand my want for a more useful string error message.

  • I'm doing it this way to make it modular, because in the future we expect to use the same email account to process a variety of files. Each different file will need a different script to process.
    For now we will be using the same email address to process 2 types of files, and calling 2 Perl scripts.

    Also, this is how is calling the script:

                $script='$HOME/'.$mprintreqdir."/ address.dat $msgnum "; 
    $script.="/export/home/userxx/perl/custm/2014mprintreq -delete";
    # Exit status in $?.
    $err=`$script`; # Capture output to $err.

    Is that correct for calling another program, returning to the original program, and capturing any string messages?

    $mprintreqdir can vary based on if I'm in the production or testing directory, both of which are on the same server. This does not use a database so there is no need to have a different server, or different database for testing and production. I will deal with the changing of $mprintreqdir later, but if you have ideas, like a field of corn, I'm all ears.

    Thank you.

    (This post was edited by bulrush on Jul 14, 2014, 6:22 AM)


    Jul 14, 2014, 6:33 AM

    Post #2 of 5 (4492 views)
    Re: [bulrush] How to pass string msg from called from [In reply to] Can't Post

    I do not think that there is a good way to do what you ask. Is there any reason the function of cannot be implemented as one or more subroutines that are packaged in a module If so, the subroutine could throw an exception (die with message string) when an error occurs. The calling program ( could trap the exception and recover the message with eval. If you really need a script, you could write one that does little but call the functions in
    Good Luck,

    Veteran / Moderator

    Jul 14, 2014, 7:59 AM

    Post #3 of 5 (4437 views)
    Re: [bulrush] How to pass string msg from called from [In reply to] Can't Post

    The module approach that Bill suggested is probably what I'd do, but if you want yo keep these as separate independent scripts, your next best option would be to use IPC::Open3

    That will allow you to run the external script and capture its stdout and stderr and exit code.

    (This post was edited by FishMonger on Jul 14, 2014, 7:59 AM)


    Jul 14, 2014, 8:10 AM

    Post #4 of 5 (4428 views)
    Re: [FishMonger] How to pass string msg from called from [In reply to] Can't Post

    Ugh. It looks like I can't debug and step into "perl" when I use $err=system("perl"). Is that right?

    Veteran / Moderator

    Jul 14, 2014, 8:16 AM

    Post #5 of 5 (4422 views)
    Re: [bulrush] How to pass string msg from called from [In reply to] Can't Post is a separate independent script, so that's how you should test/debug it.


    Search for (options) Powered by Gossamer Forum v.1.2.0

    Web Applications & Managed Hosting Powered by Gossamer Threads
    Visit our Mailing List Archives