Hello.

I have a strange problem that I do not understand.

I have 4 very similar servers, same Linux distribution (Debian 10), identical configurations.
I want to debug some PHP CLI applications, but this works only on 3 out of the 4 servers.

If I run the Wizard on one of the 3 working servers, I get this :


And on the failing one, I get this :


This is not a connection problem : even on the failing server, the terminal console opens perfectly.

It seems actually that what is failing is the actual running of the PHP script after terminal opening, either because the launching command doesn't work, or because the client PhpED application doesn't detect that the terminal has opened, and thus doesn't run the script afterwards.

The four PPJ project files are identical at the point I can open them with a text compare utility, compare textually line by line (this needs some sorting of course) and see differences only at the lines relevant to the fact that servers and SSH accounts are different.
These SSH accounts are identical the same way of course.

In fact the biggest differences are that the working servers are real dedicated located in the same country as me (one even inside my home) whereas the not working one is a VPS located about 5500 km away.
And this concerns only CLI debugging. HTTP debugging works perfectly on all servers.

Please could I have some ideas of the running protocol of the CLI connections in order do debug this, and find the very tiny difference making it not working?

I use PhpED Pro 19.1 Build 19111, 64 bit (I know, this begins to be somewhat old).

Regards,

Gingko

Hi, in CLI mode PhpED connects to the server, opens terminal session, then runs script in the shell. It need to know when the script started and most importantly when it finished. You know script may finish right away or fail to start at all or just run for very long time while you're working with something else. In either case it's crucial for the IDE to recognize command prompt. Command prompt is what shell posts to the output when it's idle and ready to run next command. In your shell profile (like ~/.profile or ~/.bash_profile) you can set PS1 environment variable, like default for many old school Linux distros PS=\u@\h:\w\$ -- it should work just fine. Don't put there anything that changes every time, like time stamp itself. Directory is ok.

Hello, and thank you for your answer.

Actually I do have a very complex PS1 pattern including time stamps and ANSI colouring, helping me to check that I am on the server where I think I am, but:

1. This don't seems to be the problem as all 4 servers have the same one (except for one colour: each server has its own colour), and the debugging fails on only one of them.
   
2. I already thought to that anyway and tried to suppress this temporarily, reverting to the default Debian one: even then, the debugging do not work better.
   Now I also tried to set "\u@\h:\w\$" as the Debian default one also uses timestamp, but it doesn't work either.
   

Anyway (as I like my custom prompt), in order to be clear on this, I included a test in my bash initialization scripts, on the TERM environment variable (my normal connections identify as "linux" whereas yours identify as "xterm"), in order to conditionally disable this.
But still not working.

(By the way, maybe you could use something more specific than "xterm" for your terminal-type strings? Like "phped" or user configurable?)

…

Now in order to still trying to solve the problem …

Would it be possible that the extra time latency due to the 5500 km distance could prevent the debugging from working?
Although it's not very important, my usual SSH connections on this server have a perceptible longer delay than with other servers for connecting. Maybe 100mS ?

Gingko

Is there some way to debug this connection session?
Can I know the details of the used underlying protocol?
How can I trace the whole networking session at the most basic level?
If you look for some string in the prompt, how do you do it? Do you use a regular expression? Is yes, which regular expression are you using?
How do you read the prompt contents? Do you try to match the test on the whole console contents?
Could something else appearing in the console text contents could prevent the test from matching?

Gingko

Hi, thanks for saving my time -- you've already tried what was going to suggest to check next.
Correct, xterm is the only terminal type implemented in PhpED. So you can rely on that and that's not configurable and won't be in foreseen future unless we find a good terminal library for windows and decide to use it. Then it would be configurable.
Regarding ping/round trip time, I'm not sure how to test that. Seems all my servers are in really close range and I doubt it's the root cause. Other than that, there could be some other settings/configuration options for your shell, terminal etc that prevent PhpED CLI client from working. For debugging the debugger, you can try to enable CLI output window -- the terminal and PhpED will show it whenever you try to debug. Wizard won't show it anyways, but you can try without the wizard to see what PhpED is doing.
Also I can help if you send me either vmware or oracle compatible virtual machine configured exactly like your server (except account password, of course) and I'll check myself what's going on. Alternatively, may be there is a chance you can let me try one of your real servers. If either way works for you, please ping me in private message.

Why not just using “dumb”?
Is there something you really need in console output formating or positionning in order to debug programs, in a console in which users are not expected to interact directly?

Or you could just add a field for choosing that string, in the SSH Terminal Account configuration, with “xterm” value as default.

PuTTY has an option like that and it works perfectly.



I already tried that. This doesn't show significant informations.
Here is how it looks like during wizard (if I click “Details”), after having set a minimal prompt:



Everything blocks after that display.

And without the Wizard, the console always open anyway, and it shows exactly the same thing.


As I previously said, I already have three other servers configured “exactly like my server (except account password, of course)” that do not have the same problem.

Do you seriously think I have a chance to create a 5th one and be able to duplicate the CLI issue on it?

If I succeed on this, I think I will also have found the solution of my problem.


I may try to create a specific user account for you on the faulty server in order to allow you to check.

But remember I am using PhpED Pro 19.1 Build 19111, 64 bit, thus I have set the corresponding dbg-php-7.3.so module to that version on all my servers.

If you connect using another (likely more recent) version, I'm not sure it will work properly.


I will.

Regards,

Gingko

BTW I'd suggest you to update to version 19.3 first. Its wizard is able to detect more issues and there are some fixes related to CLI / terminal client code. Good chances it will work right away.

RE xterm vs dumb terminal. I don't get that. Why would you need dumb terminal? It wouldn't help debugger anyway.

Good idea.

I just made a try by installing the trial version 19.3 Build 19338 - 64 bit in a virtual machine (as I suppose I can't run the trial over a paid version).
(and in order to help solving version concurrency issues, I made a BASH script for all servers for quickly switching between debugger modules versions)

And the result is :

• The behaviour is exactly the same :
  • not working on the very far server,
  • correctly working on a close (I tried just one) server.
• The wizard do not detect more issues.

It's just a string.

Allow users to change it may give them more chances to be able to fix some weird issues.

Regards,

Gingko

no, no, it's not just a string. It's how client part informs service part what standard or protocol it supports. By changing this string, you won't change the client part -- it won't recognize server response, won't render correctly and you won't see anything good out of it, just like changing logo on your car wouldn't change the car. Since PhpED's built-in terminal client supports only xterm, you can't change it to anything else. So it's static and non-configurable

I changed it to “linux” in PuTTY, which also defaults to “xterm”, and I'm not dead.

But maybe you can suggest me a better way do detect PhpED connections from my login BASH scripts?

Gingko

thanks I checked your servers and it appeared that indeed there is a problem with 4th server. You know that when you type a command, the output contains the command itself echoed here, then the command result. The problem on the 4th is that the echo of the command may be mixed up with previous command output. In particular when the IDE issued "echo $0" to identify shell type, it received "echo $0" itself as an echo mixed up with output from the profile script.

I always wondered the reason of this "echo $0" string, but I can see this in both server, whatever it works or not afterwards.
How do you send it?

I mean, if I open a SSH shell myself, if I type (with double quotes):I get :But if I type (with single quotes):I get:This conforms to the BASH rules about double and single quotes.

Could there be some issue related to this ?

And if what you name the “4th” server is the one I think, this is the working one for me.

If not for you, this is truly a distance problem.

Other thing: while you were connecting on the other server (not the “4th”), you generated a lot of lines like this one in my logs:… like of you were trying to open several times at once the same tunnel.
I don't know if you finally solved it, but I suppose that you must have had some difficulties related to this.

I wish I had an open chat with you during this time to tell you that, but I didn't.

Gingko