Seems most are using the traditional way of print for debugging purpose, is there anyone that uses remote debug for perl in linux?
There are reasonably straightforward directions here: http://search.cpan.org/dist/Enbugger/lib/Enbugger.pod#From_gdb
Though that presupposes you have a long-running perl process (mod_perl, fastcgi, etc) that wasn't expecting to be run under the debugger. If you are just using vanilla CGI, you can configure your webserver to run perl -d and set the debugger to remote debugging via its TTY or RemotePort options. Or go ahead and use Enbugger in your actual perl code as in the directions above (again, setting TTY or RemotePort).
What sort of debugging? An actual perl debugger or using warn() with tail -f /var/log/apache/error.log?
In the end i would suggest swicting to Log::Log4perl. Unless you need an actual step by step debugger.
You you need an actual debugger, you likely won't want to use Apache in the mix. You can run your cgi from the command line and pass arguments CGI.pm.
Related
I'm new to mojolicious but have been using Perl for some time. I have to jump through some hoops but I can get the interactive Perl debugger (and Komodo) working with remote connections for Apache but I can't find anything about interactive debugging with hypnotoad or morbo.
The command line examples in the basic tutorial on http://mojolicio.us/perldoc/Mojolicious/Guides/Tutorial#Hello-World work fine because you can launch them with perl -d, but I don't see anyway to tell the hypnotoadctl script to put the service in interactive debug mode ala apache.
Is this not possible? Hints? Tips? Pointers?
morbo and hypnotoad are perl programs, so you can launch them with the -d switch.
perl -d $(which morbo) myMojoApp.pl
It's probably easiest to sprinkle a bunch of $DB::single = 1 statements around you app where you want your initial breakpoints to go and run c as the first debugger command. When you run a request that hits a breakpoint, you'll get a debugger prompt in the terminal that launched morbo.
hypnotoad will be trickier to use with the debugger because it quickly closes all the standard filehandles, calls fork several times, and becomes a daemon.
As JHThorsen points out, standard Mojolicious tests are actually ordinary Perl scripts, so you can debug your tests with:
perl -d t/mytest.t
The -Ilib adds the lib/ directory to the #INC include list so your modules will be loaded.
One catch is that many modules are not loaded until execution time, so if the debugger hassles you about symbols that aren't loaded yet, you'll probably want to set breakpoints after forcing a debug prompt with a carefully inserted
$DB::single = 1;
Thanks to 'pink_mist'. You can do:
perl -d myMojoApp.pl daemon -l http://*:29849
But application config is not applyied. I do not know why.
I have a Perl program written by someone else. When I run it, it silently exits without writing anything to the logfile. Is there a way I can run this Perl program step by step, line by line by the interpreter and thus get to see where it terminates?
Yes, there is the Perl debugger which you can invoke with perl -d.
Documentation can be found in perldoc perldebug and perldoc perldebtut.
Probably the most useful commands would be:
s - step into current line.
n - step over current line.
r - step out of current function.
p <expr> - print the expression.
b <line|subnm> - sets a breakpoint
T - produce a stack trace.
c [<line|subnm>] - continue running with optional one-time breakpoint.
h - help (for other commands).
Hachi has the answer. Use the Perl debugger by running perl with the -d flag. For information on how to use the debugger past starting it, see the Perl Debugging Tutorial.
There is a Perl module called "ptkdb" which is a standalone Perl interactive debugger. It works using the Tcl/Tk GUI, so you'll need that, too.
Depending on your OS you'll need to add some required modules.
Invoke it using
perl -d:ptkdb <your script>
If running some Unix/Linux system, you also need an X server.
There are two ways. The first is the one which Hachi and llioin already gave which is using the command-line switch "-d".
Or use an IDE. I am tried and used Komodo IDE which works like charm.
I'm trying to write a perl script that redirects its stdin to a remote machine and at the same time redirects the stdout of the remote machine to its stdout:
callingProgram <--> myScript <--> sshTunnelToRemote
See this question and bdonlan's answer for the purpose of the script.
First I tried to use the open2() function from the IPC library but for reasons described here it doesn't seem to be a good approach, I didn't even get a simple grep command working.
My second idea was to use the Net::SSH::Perl or the Expect libraries but they're not available on the machine where the script is supposed to be executed and I can't install libraries there.
So my question is what could be a simple way to achieve what I want? Solutions using [ba]sh or even C++ are also possible. The targeted platform is Solaris 10.
Seems like you could probably get away with nothing more than system() — don't pass the data from your stdin to ssh's stdin and from your stdout to ssh's stdout; just let ssh inherit your stdin and stdout. Unless you need to modify the data in transit somehow.
cpanminus can do this for you
Running:
cd ~/bin
curl -LO http://xrl.us/cpanm
chmod +x cpanm
Now you can try your problem using the right tools (e.g. Net::SSH::Perl).
The power of perl is cpan, and cpanminus gives you the ability to install whatever you need even if you don't have permission to install to the system-wide libraries.
Read the module documentation for the full details.
I have a Perl script running on a Windows machine. I need this script to open a ssh session to a remote Unix machine, and to be able to execute certain commands on that Unix machine and to be able to get the output returned from these commands.
These commands are generated during the run-time of the script, and there are many of them executed at different times.
How can I do it?
Approach 1: Use CYGWIN: http://perlwin32ssh.blogspot.com/2007/07/test_4418.html
Approach 2: Use Net::SSH::W32Perl module.
This is one thread discussing how to install it: http://code.activestate.com/lists/perl-win32-users/29180/ (It seems to require downloading custom version of the module)
This thread should help with the problems arising from dependencies on math libraries needed for ssh calculations: http://www.issociate.de/board/post/494356/I%27m_trying_to_install_%27Net::SSH::Perl%27_on_a_Windows_Box..html
Caveat emptor: I never installed this, the above is just result of some analysis of google results.
#!/usr/bin/perl
system("ssh foo 'ls -l'");
Or go through the hassle of using ptmx(4) on the local side and ssh -t for remote.
I have this command that I load (example.sh) works well in the unix command line.
However, if I execute it in Perl using the system or ` syntax, it doesn't work.
I am guessing certain settings like environment variables and other external sh files weren't loaded.
Is there an example coding to ensure it will work?
More Updates on coding execution failure (I have been trying with different codes):
push (#JOBSTORUN, "cd $a/$b/$c/$d; loadproject cats; sleep 60;");
...
my $pm = new Parallel::ForkManager(3);
foreach my $job (#JOBSTORUN) {
$pm->start and next;
print(`$job`);
$pm->finish;
}
print "\n\n[DONE] FINISHED EXECUTING JOBS\n";
Output Messages:
sh: loadproject: command not found
Can you show us what you have tried so far? How are you running this program?
My first suspicion wouldn't be the environment if you are running it from a login shell. any Perl script you start (well, any program, really) inherits the same environment. However, if you are running the program through cron, then that's a different story.
The other mistakes I usually make in these situations is specifying the relative paths incorrectly. The paths are fine from the command line, but my Perl script has some other current working directory.
For general advice, see Interact with the system when Perl isn't enough. There's also a chapter in Learning Perl about this.
That's about the best advice you can hope for given the very limited information you've shared with us.