4th -- I mean the one that failed to work for you too.

echo $0 is one of the ways to find shell type. There is no quote needed as $0 is the running process -- the shell.
Let me explain again how this whole thing works. When you type "e", the first letter of echo $0 command, don't you see e in the terminal? Try to click on desktop and type "e", will you see it? No. Because desktop ignores your input and is not echoing your input. Terminal has two sides -- client and server. When client sends "e", server reacts on that input and sends "e" back -- echoing it, so you can see what you're typing. From these perspectives, IDE can read its own command it sent to the server. In case of that server, the echoed input appeared before the output from profile finished, so IDE read it like below:

<previous lines produced in your profile>
echo $0
<last lines of the output produced in your profile, like it's phped probably>
-bash
<prompt>

I think it's due to different OS version. Try it in a closer location and you'll get the same problem.

RE bind & address already in use. I didn't try to run 2nd tunnel. The problem was with killed process on the client (IDE in debugger). As a result, the server side of the tunnel remained running, so the address was in use (listening on localhost). I tried to feed it with some input using telnet so it would figure out that the input is nowhere to send because the client counterpart is not connected and therefore server process should just quit, but it didn't work. Eventually it stopped on its own and released the port then I moved forward. If it was my server, I'd just kill sshd child process from that dead tunnel session.

Bottom line: problem is reproduced and workaround will be implemented in the next version.

you can add ForwardAgent yes in your ssh config, so whenever you youself log in, shell profile will see agent is forwarded (there will be SSH_AGENT_SOCK env variable populated pointing to open socket). PhpED does not forward authentication. At least for now. When/if I add it, it will be configurable and you'd be able to turn it off.

Ok.


I highly doubt on it.

And if ever it does anyway, you are going to run into a big problem because the official release of Debian 11 is due this year.

And I won't check on my other servers because they have production websites running as opposite of this one.

Actually you seems to have tested in two different sessions.

After the first, I saw that you had left 5 (!!!!) child processes open that I killed myself in the middle.

All my servers have exactly the same kind of mixed previous output, and the "-bash" reply appears correctly everywhere.
Why only one not working?

Gingko

How do you check for the « echo $0 » reply?

Are you, for example, applying a regular expression test on the whole console screen?

If yes, which regular expression?

If not, how do you proceed otherwise?

Gingko

I already explained that. Server echoed command before previous output completed.
It can be related to shell itself, underlying terminal library or timing issue, like you suggested
Anyway, it's not your server problem. It's our problem -- CLI client not to start next command until it makes sure that previous has completed. In order to do it, it uses one more or less reliable way -- it's checking if the last line is an empty prompt. Unfortunately, in the beginning shell type is not known and prompt is not known either. This is where it lost sync on your 4th server.
Some other tools that can run commands in terminal, run echo "some unique ID" command then they are waiting for a line with this unique ID on whole line (e.g. without echo). This way they can be sure previous command has finished. It's somewhat portable and should work more or less well in all shells and terminals including windows.

Hello Dmitri

I tried to completely remove all custom strings inside the login screen (this was just a file dropped inside /etc/update-motd.d).
The display of Debian GNU/Linux 11 was fake, it was just due to a not really expected upgrade of the package “base-files” to testing version. I downgraded, so the display is now correct (although it was actually part of the extra login custom strings that I removed so you can no longer see it).

None of this made the debugging working on this server.

I don't know why you marked the topic as [resolved].

It is not.

Gingko

Back to this :
I usually connect using PuTTY, rarely from another Linux shell. So I suppose that corresponds to the PuTTY option named “Allow agent forwarding”.

But it's not better than changing the terminal-text string: this still implies changing one of the default options of my usual client (that I use much more often than PhpED debugging) to make it different from the ones of PhpED which cannot be changed.

Gingko

Using terminal type for software identification is a bad choice. The problem is only xterm is supported by PhpED. You can't change it.
Ssh certainly knows it's session with PhpED is opening session because software identification is passed along with ssh protocol version -- as per ssh protocol at SSH handshake phase, but I'm not sure whether sshd exposes this info.
If you rarely need PhpED, perhaps you can set up a different account for it with -phped suffix?
BTW is there any real issue if you don't identify PhpED and leave everything intact?

Yes an no.

Actually I did that as a try to remove my custom prompt when using PhpED while expecting this was the reason of the problem.
But it is not.
I keep asking however, as I suppose I could meet other reasons to detect PhpED in the future.

And I won't use another account because if I have a problem to debug, I usually want to do it in the running account where the problem was met.
Changing account may often means moving in another directory, changing permissions, etc, and the account itself maybe part of the problem.

Gingko

Hello,

I finally found a way to get the debugging working on this server :

It appears that BASH had been upgraded, there, to version 5.1-2 (testing).

If I downgrade to 5.0-4 (stable), it works properly.

If I upgrade again to 5.1-2 (testing), it stops working.

If I downgrade again to 5.0-4 (stable), it works properly again.

5.1-2 is expected to be released as stable this year on Debian.

Gingko