I have this problem:
I need to control the perl-debugger from an external script.
By research I found out about various solutions, but I don't understand them.
I failed to properly set up the RemotePort option (editing ".perldb"), which was the first I tried, and found no useful information on providing a filehandle from which the debugger would get its input (by somehow setting #cmdfhs)
I found both options over here: http://search.cpan.org/~nwclark/perl-5.8.6/lib/perl5db.pl
It would be nice if you could tell me how to provide the filehandle from which the debugger gets its input, or if you know a link where this is explained?
Here's a simple example setting it up using RemotePort, which seemed easier to me:
The trick to using RemotePort is that you have to have someone listening on the remote end BEFORE you launch the script to be debugged.
As soon as you launch your script with -d Perl will attempt to connect to RemotePort. So you have to make sure the initial connection succeeds by having someone listening there beforehand.
Here I assume some Linux/Unix variant, which has the netcat utility installed. We use netcat to wait for incoming connections in this example, but you can use anything else you wish too which is able to create a service port and shuffle data between that and the current TTY:
In terminal 1:
# Use netcat to listen for incoming connections on port 9999
> nc -l -p 9999
In terminal 2:
# Start perl with -d and request a RemotePort connection
> PERLDB_OPTS=RemotePort=127.0.0.1:9999 perl -d my_script.pl
As soon as you do that in terminal 1 you will see something like this:
Loading DB routines from perl5db.pl version 1.39_10
Editor support available.
Enter h or 'h h' for help, or 'man perldebug' for more help.
main::(my_script.pl:4):
DB<1>
There you go..debug away.
Devel::Trepan is a gdb-like debugger. Although it has remote control, you can also run it at the outset with the option --command which will "source" (in the gdb-sense) or run a series of debugger commands.
To go into remote control, either start the debugger using the --server option or inside the debugger use the "server" command once inside the debugger.
See Options for a list of options you can give at the outset.
Related
So I have a serious fundamental gap in my knowledge that I'm sure has an easy answer, but after googling and looking on here, I can't find what I'm looking for:
I use nmap and telnet on an almost daily basis for checking ports and logging into IP codecs and I use them through either the powershell or cmd consoles, but when I tried to script something and run that script with either a .bat or .ps1 suffix, either will give me the classic not recognized... message. But, if you're able to run it in the console, you should be able to script it, right? How can one go about that?
Sample code for telnet (that works in when inputting to either console, but not in script form):
telnet 192.168.87.21
Sample code for nmap (again, works when inputting to either console, but not in script form):
nmap -p 9999 192.168.87.101
Add a '&' symbol before 'telnet' like that: & telnet 127.0.0.1
For more information how to run executables from Powershell look there: https://social.technet.microsoft.com/wiki/contents/articles/7703.powershell-running-executables.aspx
I wana use the pyoo.py package to control libreOffice via Python.
There are good tutorials available. First step is to open a socket with following command.
soffice --nologo --norestore --nodefault --accept="socket,host=localhost,port=2002;urp;"
But it does not work, it stucks.(Stucks means I enter the command in the cmd but no response)
If I kill the sOffice Process in the Task-Manger it will continue.
It worked once and than never again.
I use Win7 64bit and LibreOffice 5
First be sure that all instances and processes of soffice are closed, because if office is already open, it will not start listening on a socket.
Well there is something wrong with your command; it isn't working for me. What I normally use is:
chdir "%ProgramFiles(x86)%\LibreOffice 5\program\"
start soffice -accept=socket,host=0,port=2002;urp;
On Linux I use the following command, and the same arguments work on Windows:
loffice "--accept=socket,host=localhost,port=2002;urp;" --writer
EDIT:
From your comment, it sounds like you were able to get it to work by removing various arguments to see which one was causing the problem.
I am having a strange issue. I have written a script which is basically running a perl script in remote server using ssh.
This script is working fine but after completion of the above operation it will ask user to choose the next operation.
it is showing the options in the command prompt but while I am giving any input it is not showing in the screen even after hitting enter also it remain same.
I am not getting what is the exact issue, but it seems there is some issue with the ssh command because if I am commenting out the ssh command it is working fine.
OPERATION:
print "1: run the script in remote server \n2: Exit\n\nEnter your choice:";
my $input=<STDIN>;
chomp($input);
..........
sub run_script()
{
my $com="sshg3.exe server -q --user=user --password=pass -exec script >/dev/null";
system("$com");
goto OPERATION;
}
after completing this ssh script it is showing in screen:
1: run remote script
2: exit
Enter your choice:
but while I am giving any input it is not displaying in the screen until and unless I am exiting it using crtl C.
Please can anyone help what might be the issue here ?
One of the classic gotchas with ssh is this - that it normally runs interactively, and as such will attach STDIN by default.
This can result in STDIN being consumed by ssh rather than your script.
Try it with ssh -n instead.
You can redirect the output in command prompt if -n option is not available for you.
try this one it might work for you.
system("$com />null");
As per https://support.ssh.com/manuals/client-user/62/sshg3.html there is an option for redirecting input use --dev-null (*nix) or --null (Windows).
-n, --dev-null (Unix), -n, --null (Windows)
Redirects input from /dev/null (Unix) and from NUL (Windows).
Is there any way to save the PuTTY output to a file using the command line? I know this is easily done using the GUI but in my case it has to be done automatically.
What I'm working on:
User clicks batch file -> starts PuTTY, automatically connects to my device over SSH and runs a bunch of commands -> PuTTY should save the output to a file.
The last part I can't get working. Is there any command to do this?
This can be done with putty. The answer is little late considering the time the questions was asked, however this might help someone.
In putty, using GUI, you can save sessions with logging option on, as shown below.
Enter Host Name, Name the session, Go to Logging Option in the left top corner, select all sessions, provide log file name and location, go back to Session tab, click on the save button. Done, you have saved a session.
Now open CMD and write the command as below
You are done. Every time this session is invoked, the commands and output will be logged.
Hope this helps.
The specific program putty is not designed for this. Instead use plink, a different program in the PuTTY suite,
which uses the same session settings and keys as putty but gets input from stdin and puts output to stdout,
both of which can be redirected in the usual ways. See http://the.earth.li/~sgtatham/putty/0.63/htmldoc/Chapter7.html#plink .
As mentioned in previous answer, use plink for this.
Make sure it is in your environment path, by typing
plink -V
in your console. If it returns a version number, then you know it is in environment path variables. If it doesn't, probably best to fix this first. There are plenty of good SO answers to help you with this. Failing that, use the full path to your plink.exe in the CLI command that follows.
Then use plink to open your ssh connection, with the option -v set to provide verbose output. Finally, this all needs to be piped to a log file.
The complete cli command that I use is
plink -v username#xxx.xxx.xxx.xxx > ssh-output.log 2>&1
Open up the file ssh-ouput.log to see the results.
Expanding on Dave's and Charlie's answers...
Apart from making sure plink is in the path, also check whether you have write access to local ouput file.
This is how you redirect command output from remote machine to local file with plink. In this example we store an output from man page for nfcapd:
plink joe#192.168.50.50 -pw joespassword man nfcapd > output.log 2>&1
The first time you try to access the server, it will ask you store key in cache. So make sure to access the machine at least once before:
plink joe#192.168.50.50 -pw joespassword
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
...
Store key in cache? (y/n)
What I'm trying to do is get the Xdebug debugger running on a file in a vim session, all from a perl script. If I wanted to do this from the command line, I would open vim, then issue a command (specific to the debugger) in vim that makes vim listen to port 9000 (by pressing F5 in normal mode), and then open the page I want to debug in a browser, which starts the debugging session in vim. I have done this with success.
For doing it within perl, my idea has been to use a fork and system calls.
use LWP::Simple;
if ($pid = fork) {
system('vi -c ":normal ^[[15~"');
} else {
sleep;
get 'http://localhost/homepage/index.php?XDEBUG_SESSION_START=1';
exit(0);
}
(The '-c ":normal ^[[15~"' option makes vim start out by waiting for a new connection on port 9000.)
This doesn't work. The problem seems to have to do with sockets, as far as I can tell. Is there a way to get too processes to talk to one another across such a connection from within perl?
Making the connection from within vim works:
vim -c 'let x = system("sleep 2; wget http://localhost/homepage/index.php?XDEBUG_SESSION_START=1; &")' -c 'normal ^[[15~'