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~'
Related
I have some utility scripts that copy text to my clipboard using pyperclip (python library).
When I use vscode in ssh mode to develop on my remote server, I want to still be able to run these scripts in the integrated terminal of the remote server, but make it copy text to my local clipboard.
I suspect there might be a way to do this, since running code <dirname> in the remote terminal, for example, opens a vscode window in my local machine, so I assume there's a way to intercept the commands to make them do something locally even if they run on the remote machine. Any suggestions?
xsel might help you.
I'm trying to get a similar result using a dev container, although I could use some help myself. My problem is that I can't configure X11 forwarding. If you can set that up, then the following might move you forward a bit:
copy-to-clipboard-file() {
[[ "$REGION_ACTIVE" -ne 0 ]] && zle copy-region-as-kill
print -rn -- $CUTBUFFER > xsel --clipboard
}
zle -N copy-to-clipboard-file
bindkey "^X" copy-to-clipboard-file
I don't know if zle is available in your shell; I'm using zsh. This binds Ctrl-X to copy the selected text. You'll need to install xsel.
You'll know if X11 forwarding is working because this will output something:
echo $DISPLAY
Also see:
How do I highlight text for copying and pasting in the VS Code terminal?
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 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).
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.
I use an emacs daemon to preserve my emacs session even if I have to reboot the machine that I run my X server on or if I want to access the same session from a different machine. This works very well but when restoring a session I'd quite like to just run "emacsclient --create-frame --no-wait" to connect to the daemon without opening a new file. It won't let me get away without specifying a filename.
I've tried using --eval to execute a function rather than open a file but the window just goes away when the evaluation is complete.
(Emacs 23.1 via backports on Debian GNU/Linux 5.0.)
From the help provided by emacsclient, you have a few options. First, is the one mentioned already which is emacsclient -c. That will try to create a frame associated with the emacs daemon. The advantage to this is that if DISPLAY is not set, then it will open emacs in the terminal.
Which brings us to the next best option (especially if you are logging in remotely): emacsclient -t which forces emacs to open up in terminal mode even if DISPLAY is set.
Also keep in mind that you can set the display from the command-line as well. I use this often when logging in remotely from VNC. The full command would be emacsclient -d DISPLAY -c
emacsclient -c works for me.
emacsclient -n -e "(make-frame)"
The -n flag means that the emacsclient doesn't wait, and the emacs instance doesn't destroy the frame.
If you are using emacs from the command line, you might also want to consider emacsclient -t