On Wednesday, July 28, 2021 at 10:24:45 PM UTC+8, Keith Thompson wrote:

"hongy...@gmail.com" <hongy...@gmail.com> writes:
[...]

Got it. To be sure, your method is right, but I happened to use an
error value of "$DISPLAY". Here, I summarize the successful methods
as follows:

Obtain the value of `$DISPLAY' locally on the ssh server:

$ echo $DISPLAY
:1

Or use the following method:

$ xdpyinfo | grep -i display
name of display: :1

That seems pointless. xdpyinfo gets the value to show by looking at
$DISPLAY. (I had suggested running xdpyinfo just to see whether it
succeeds or fails.)

Then, where does $DISPLAY come from?

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"hongy...@gmail.com" <hongyi.zhao@gmail.com> writes:

On Wednesday, July 28, 2021 at 10:24:45 PM UTC+8, Keith Thompson wrote:

"hongy...@gmail.com" <hongy...@gmail.com> writes:
[...]

Got it. To be sure, your method is right, but I happened to use an
error value of "$DISPLAY". Here, I summarize the successful methods
as follows:

Obtain the value of `$DISPLAY' locally on the ssh server:

$ echo $DISPLAY
:1

Or use the following method:

$ xdpyinfo | grep -i display
name of display: :1

That seems pointless. xdpyinfo gets the value to show by looking at
$DISPLAY. (I had suggested running xdpyinfo just to see whether it
succeeds or fails.)

Then, where does $DISPLAY come from?

It's an environment variable, of course. It's set by sshd (if X
forwarding is enabled) and inherited by your shell, or it's set by
whatever invokes your terminal emulator if you launch it on the system
itself, or by anything else that sets it.

emacs displays the message
Display localhost:10.0 unavailable, simulating -nw
if and only if XOpenDisplay("localhost:10.0") returns a null pointer.

Is it correct that running `emacs` displays that error message and
running `xlogo` *from the same shell process* successfully displays a
window with the X logo? (Please verify before answering.) If so, then something weird is going on. I don't know why xlogo's call to
XOpenDisplay would succeed while emacs's call would fail. If that is
what's happening, try running emacs followed by xlogo, and xlogo
followed by emacs.

I suggest setting PS1 to some unique value so you can be sure you're
running all the commands from the same shell process. (Since you're
ssh'ing from one system to another, it's conceivable that you could
return to another shell without noticing it if the prompt never
changes.)

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed
all the details.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 29, 2021 at 12:50:12 PM UTC+8, Keith Thompson wrote:

"hongy...@gmail.com" <hongy...@gmail.com> writes:

On Wednesday, July 28, 2021 at 10:24:45 PM UTC+8, Keith Thompson wrote:

"hongy...@gmail.com" <hongy...@gmail.com> writes:
[...]

Got it. To be sure, your method is right, but I happened to use an
error value of "$DISPLAY". Here, I summarize the successful methods
as follows:

Obtain the value of `$DISPLAY' locally on the ssh server:

$ echo $DISPLAY
:1

Or use the following method:

$ xdpyinfo | grep -i display
name of display: :1

That seems pointless. xdpyinfo gets the value to show by looking at
$DISPLAY. (I had suggested running xdpyinfo just to see whether it
succeeds or fails.)

Then, where does $DISPLAY come from?

It's an environment variable, of course. It's set by sshd (if X
forwarding is enabled) and inherited by your shell, or it's set by
whatever invokes your terminal emulator if you launch it on the system itself, or by anything else that sets it.

emacs displays the message
Display localhost:10.0 unavailable, simulating -nw
if and only if XOpenDisplay("localhost:10.0") returns a null pointer.

Thank you for your explanation. I found the following option of sshd_config:

$ man sshd_config |egrep -A4 '^[ ]*X11DisplayOffset$'
X11DisplayOffset
Specifies the first display number available for sshd(8)'s X11 for‐
warding. This prevents sshd from interfering with real X11 servers.
The default is 10.

Is it correct that running `emacs` displays that error message and
running `xlogo` *from the same shell process* successfully displays a
window with the X logo? (Please verify before answering.)

Yes.

If so, then something weird is going on. I don't know why xlogo's call to XOpenDisplay would succeed while emacs's call would fail. If that is
what's happening, try running emacs followed by xlogo, and xlogo
followed by emacs.

Same results observed.

I suggest setting PS1 to some unique value so you can be sure you're
running all the commands from the same shell process. (Since you're
ssh'ing from one system to another, it's conceivable that you could
return to another shell without noticing it if the prompt never
changes.)

Thank you for your suggestions. I always notice the host name part of the prompt string, which is different from each other for the test case discussed here, when I'm on different hosts.

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed
all the details.

If I logged in to the ssh server from the noVNC console of vitrual machine running in pve, the $DISPLAY value will be
"localhost:10.0"; if I locally check the variable's value on the ssh server, it will be ":1".

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-07-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

I suggest setting PS1 to some unique value so you can be sure you're
running all the commands from the same shell process. (Since you're
ssh'ing from one system to another, it's conceivable that you could
return to another shell without noticing it if the prompt never
changes.)

*this*

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed
all the details.

A common pitfall is that xauth hasn't been installed on the ssh server,
so you may want to check that (which xauth).

Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-07-29, hongy...@gmail.com <hongyi.zhao@gmail.com> wrote:
....

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed
all the details.

If I logged in to the ssh server from the noVNC console of vitrual machine running in pve, the $DISPLAY value will be
"localhost:10.0"; if I locally check the variable's value on the ssh server, it will be ":1".

Not sure what you are saying but that sounds as it should be. The
display on the machine itself should be :1 (or whatever you logged in
as) while the display into the ssh from a remote machine should be :10. Different X displays, different numbers. Imagine it is not a virtual
machine but is a different physical machine. One is "put the X stuff
onto the local screen" and the other one is "put the X stuff onto the
screen of the system which sshed into me"
That both screens are the actually the same physical piece of hardware is irrelevant.

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I'm wondering if it's by chance a script that's artificially changing / overriding the DISPLAY environment variable.

It might not be, but it's something simple to check and it quite likely
would keep it from working if such shenanigans were afoot.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 29, 2021 at 5:30:06 PM UTC+8, Peter van Hooft wrote:

On 2021-07-29, Keith Thompson <Keith.S.T...@gmail.com> wrote:

I suggest setting PS1 to some unique value so you can be sure you're running all the commands from the same shell process. (Since you're
ssh'ing from one system to another, it's conceivable that you could
return to another shell without noticing it if the prompt never
changes.)

*this*

What's your meaning by saying the above word?

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed
all the details.

A common pitfall is that xauth hasn't been installed on the ssh server,
so you may want to check that (which xauth).

Yes, see below:

werner@X10DAi:~$ which xauth
/usr/bin/xauth

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 29, 2021 at 10:01:11 PM UTC+8, William Unruh wrote:

On 2021-07-29, hongy...@gmail.com <hongy...@gmail.com> wrote:
....

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed
all the details.

If I logged in to the ssh server from the noVNC console of vitrual machine running in pve, the $DISPLAY value will be
"localhost:10.0"; if I locally check the variable's value on the ssh server, it will be ":1".

Not sure what you are saying but that sounds as it should be. The
display on the machine itself should be :1 (or whatever you logged in
as) while the display into the ssh from a remote machine should be :10. Different X displays, different numbers. Imagine it is not a virtual
machine but is a different physical machine. One is "put the X stuff
onto the local screen" and the other one is "put the X stuff onto the
screen of the system which sshed into me"
That both screens are the actually the same physical piece of hardware is irrelevant.

Now, I've set the following on the ssh server:

$ grep -i ^x11 /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10
$ sudo systemctl restart sshd

Then I ssh on to it:
$ ssh werner@192.168.10.100
$ echo $DISPLAY

$

As you can see, the `$DISPLAY' is still empty. Why?

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor <gtaylor@tnetconsulting.net> writes:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I suggest "type emacs" rather than "which emacs".

"which" is an external command, which means it doesn't know about shell functions or aliases. "type" is a shell builtin that tells you what
typing "emacs" will actually do.

For bash, "help type" shows more information about the capabilities of
the "type" command.

I'm wondering if it's by chance a script that's artificially changing
/ overriding the DISPLAY environment variable.

It might not be, but it's something simple to check and it quite
likely would keep it from working if such shenanigans were afoot.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"hongy...@gmail.com" <hongyi.zhao@gmail.com> writes:

On Thursday, July 29, 2021 at 10:01:11 PM UTC+8, William Unruh wrote:

On 2021-07-29, hongy...@gmail.com <hongy...@gmail.com> wrote:
....

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed
all the details.

If I logged in to the ssh server from the noVNC console of vitrual machine running in pve, the $DISPLAY value will be
"localhost:10.0"; if I locally check the variable's value on the ssh server, it will be ":1".

Not sure what you are saying but that sounds as it should be. The
display on the machine itself should be :1 (or whatever you logged in
as) while the display into the ssh from a remote machine should be :10.
Different X displays, different numbers. Imagine it is not a virtual
machine but is a different physical machine. One is "put the X stuff
onto the local screen" and the other one is "put the X stuff onto the
screen of the system which sshed into me"
That both screens are the actually the same physical piece of hardware is
irrelevant.

Now, I've set the following on the ssh server:

$ grep -i ^x11 /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10
$ sudo systemctl restart sshd

Then I ssh on to it:
$ ssh werner@192.168.10.100
$ echo $DISPLAY

We can't tell whether the ssh command silently failed and left you in
the same shell, or whether it was successful and the echo command was
run on the target system. The former is unlikely, but this is why I
requested that you set the prompt to some unique value that shows where
you are. I suggest:

PS1="\u@\h pid=$$ \!\$ "

$

As you can see, the `$DISPLAY' is still empty. Why?

What is $DISPLAY on the initial system, before you run ssh?

What happens when you replace "ssh" by "ssh -X" or "ssh -Y"?

X11 forwarding has to be enabled by both the client and the server.

Is $DISPLAY unset or empty? The behavior should be similar either way,
but it could be helpful to know. Consider `set -o nounset`, at least temporarily, so you get an error message referring to an unset variable.

$DISPLAY being either empty or unset is inconsistent with the symptom
you reported originally, emacs complaining about "localhost:10.0".
It's not at all clear what significance the information you're giving us
now has to your original problem.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/29/21 9:49 PM, hongy...@gmail.com wrote:

proxychains-ng-socks5 $EMACS "$@"

Why are you running emacs via proxychains?

That's almost definitely going to mess with it's ability to connect to
an X11 server, wherever it is, unless said proxy can communicate with
said X11 server.

Try running /usr/local/bin/emacs and seeing if that works.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/29/21 9:45 PM, hongy...@gmail.com wrote:

I use a self-written wrapper script to start Emacs, but I really
haven't overridden the DISPLAY environment variable in the script. See
the following for more detailed info:

No, you're not altering the DISPLAY environment variable. But you are
quite likely intercepting any and all network connection attempts and
routing them through the configured proxy, including attempts to connect
to the value of $DISPLAY.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 9:00:59 AM UTC+8, Grant Taylor wrote:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I'm wondering if it's by chance a script that's artificially changing / overriding the DISPLAY environment variable.

I use a self-written wrapper script to start Emacs, but I really haven't overridden the DISPLAY environment variable in the script. See the following for more detailed info:

$ which emacs
/home/werner/.local/bin/emacs

$ which emacs |xargs egrep '^[^#]'| grep -v '^[ ]*#' script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

HY

It might not be, but it's something simple to check and it quite likely
would keep it from working if such shenanigans were afoot.
--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 10:50:56 AM UTC+8, Keith Thompson wrote:

Grant Taylor <gta...@tnetconsulting.net> writes:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I suggest "type emacs" rather than "which emacs".

$ type emacs
emacs is hashed (/home/werner/.local/bin/emacs)

$ type -a emacs
emacs is /home/werner/.local/bin/emacs
emacs is /usr/local/bin/emacs
emacs is /usr/bin/emacs
emacs is /bin/emacs

So, the first entry will be picked by shell, and see the following for more detailed info about the corresponding script:

$ egrep '^[^#]' /home/werner/.local/bin/emacs | grep -v '^[ ]*#' script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

"which" is an external command, which means it doesn't know about shell functions or aliases. "type" is a shell builtin that tells you what
typing "emacs" will actually do.

For bash, "help type" shows more information about the capabilities of
the "type" command.

I'm wondering if it's by chance a script that's artificially changing
/ overriding the DISPLAY environment variable.

It might not be, but it's something simple to check and it quite
likely would keep it from working if such shenanigans were afoot.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 11:02:10 AM UTC+8, Keith Thompson wrote:

"hongy...@gmail.com" <hongy...@gmail.com> writes:

On Thursday, July 29, 2021 at 10:01:11 PM UTC+8, William Unruh wrote:

On 2021-07-29, hongy...@gmail.com <hongy...@gmail.com> wrote:
....

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed >> >> all the details.

If I logged in to the ssh server from the noVNC console of vitrual machine running in pve, the $DISPLAY value will be
"localhost:10.0"; if I locally check the variable's value on the ssh server, it will be ":1".

Not sure what you are saying but that sounds as it should be. The
display on the machine itself should be :1 (or whatever you logged in
as) while the display into the ssh from a remote machine should be :10.
Different X displays, different numbers. Imagine it is not a virtual
machine but is a different physical machine. One is "put the X stuff
onto the local screen" and the other one is "put the X stuff onto the
screen of the system which sshed into me"
That both screens are the actually the same physical piece of hardware is >> irrelevant.

Now, I've set the following on the ssh server:

$ grep -i ^x11 /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10
$ sudo systemctl restart sshd

Then I ssh on to it:
$ ssh wer...@192.168.10.100
$ echo $DISPLAY

We can't tell whether the ssh command silently failed and left you in
the same shell, or whether it was successful and the echo command was
run on the target system. The former is unlikely, but this is why I
requested that you set the prompt to some unique value that shows where
you are. I suggest:

PS1="\u@\h pid=$$ \!\$ "

Now, on the ssh server, I append the following lines at the bottom of my ~/.bashrc file:

set -o nounset
export PS1="\u@\h pid=$$ \!\$ "

$

As you can see, the `$DISPLAY' is still empty. Why?

What is $DISPLAY on the initial system, before you run ssh?

werner@X10DAi pid=1948000 501$ echo $DISPLAY
:1

What happens when you replace "ssh" by "ssh -X" or "ssh -Y"?

If I don't log in to the ssh server from the pve noVNC console:

$ ssh -X werner@192.168.10.100
werner@X10DAi pid=2452674 501$ echo $DISPLAY

werner@X10DAi pid=2452674 495$

X11 forwarding has to be enabled by both the client and the server.

Is $DISPLAY unset or empty? The behavior should be similar either way,
but it could be helpful to know. Consider `set -o nounset`, at least temporarily, so you get an error message referring to an unset variable.

$DISPLAY being either empty or unset is inconsistent with the symptom
you reported originally, emacs complaining about "localhost:10.0".

If I log in to the ssh server from the pve noVNC console:

$ ssh -X werner@192.168.10.100
werner@X10DAi pid=1622407 501$ echo $DISPLAY
localhost:10.0
werner@X10DAi pid=1622407 496$

It's not at all clear what significance the information you're giving us
now has to your original problem.
--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 29 Jul 2021 17:50:14 -0700 (PDT)
"hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:

On Thursday, July 29, 2021 at 5:30:06 PM UTC+8, Peter van Hooft wrote:

On 2021-07-29, Keith Thompson <Keith.S.T...@gmail.com> wrote:

I suggest setting PS1 to some unique value so you can be sure you're running all the commands from the same shell process. (Since you're ssh'ing from one system to another, it's conceivable that you could return to another shell without noticing it if the prompt never
changes.)

*this*

What's your meaning by saying the above word?

It means he emphatically agrees with Keith Thompson.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 12:07:25 PM UTC+8, Grant Taylor wrote:

On 7/29/21 9:45 PM, hongy...@gmail.com wrote:

I use a self-written wrapper script to start Emacs, but I really
haven't overridden the DISPLAY environment variable in the script. See
the following for more detailed info:

No, you're not altering the DISPLAY environment variable. But you are
quite likely intercepting any and all network connection attempts and
routing them through the configured proxy, including attempts to connect
to the value of $DISPLAY.

Wonderful analysis, I confirmed the above assertion, as described below:

After I logged in to the ssh server, if the `xlogo' can run correctly, the `/usr/local/bin/emacs', i.e., without using the wrapper script, hence bypassing the proxychains proxy set there, will work with X smoothly.

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 29 Jul 2021 20:49:40 -0700 (PDT)
"hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:

On Friday, July 30, 2021 at 10:50:56 AM UTC+8, Keith Thompson wrote:

Grant Taylor <gta...@tnetconsulting.net> writes:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I suggest "type emacs" rather than "which emacs".

$ type emacs
emacs is hashed (/home/werner/.local/bin/emacs)

$ type -a emacs
emacs is /home/werner/.local/bin/emacs
emacs is /usr/local/bin/emacs
emacs is /usr/bin/emacs
emacs is /bin/emacs

So, the first entry will be picked by shell, and see the following for more detailed info about the corresponding script:

$ egrep '^[^#]' /home/werner/.local/bin/emacs | grep -v '^[ ]*#' script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

Unless the comments in the script have some private information you don't want the world to see or are very long , it would have been better to also show
the comments because they might give some valuable clue. In any case , instead of
egrep '^[^#]' /home/werner/.local/bin/emacs | grep -v '^[ ]*#'

using
grep -v '^ *#' /home/werner/.local/bin/emacs

does the same job.

Perhaps $HOME/.local/libexec/script_name.sh does something with the DISPLAY variable. I suggest modifying your script as follows

echo "Point A : the value of DISPLAY is =$DISPLAY=" script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}
echo "Point B : the value of DISPLAY is =$DISPLAY="
[ ... Rest the same ...]

I also second the advice to try running emacs directly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"hongy...@gmail.com" <hongyi.zhao@gmail.com> writes:

On Friday, July 30, 2021 at 9:00:59 AM UTC+8, Grant Taylor wrote:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I'm wondering if it's by chance a script that's artificially changing /
overriding the DISPLAY environment variable.

I use a self-written wrapper script to start Emacs, but I really
haven't overridden the DISPLAY environment variable in the script. See
the following for more detailed info:

Then the obvious next step is to try the same thing, but running
/usr/bin/emacs directly rather than your wrapper script.

$ which emacs
/home/werner/.local/bin/emacs

$ which emacs |xargs egrep '^[^#]'| grep -v '^[ ]*#' script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

Frankly, it should already have occurred to you to try invoking
the emacs executable directly. It's an added layer, and you need
to strip away any such layers while trying to figure out what's causing
the problem. Do the simplest set of steps that reproduces the problem.

Even more obvious than bypassing your wrapper script: Telling us that
you're using one. You should have mentioned that in your original post.
Don't withhold information like that, and don't make us drag it out of
you.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 12:25:34 PM UTC+8, Spiros Bousbouras wrote:

On Thu, 29 Jul 2021 20:49:40 -0700 (PDT)
"hongy...@gmail.com" <hongy...@gmail.com> wrote:

On Friday, July 30, 2021 at 10:50:56 AM UTC+8, Keith Thompson wrote:

Grant Taylor <gta...@tnetconsulting.net> writes:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what type of file emacs is.

I suggest "type emacs" rather than "which emacs".

$ type emacs
emacs is hashed (/home/werner/.local/bin/emacs)

$ type -a emacs
emacs is /home/werner/.local/bin/emacs
emacs is /usr/local/bin/emacs
emacs is /usr/bin/emacs
emacs is /bin/emacs

So, the first entry will be picked by shell, and see the following for more detailed info about the corresponding script:

$ egrep '^[^#]' /home/werner/.local/bin/emacs | grep -v '^[ ]*#' script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

Unless the comments in the script have some private information you don't want
the world to see or are very long , it would have been better to also show the comments because they might give some valuable clue. In any case , instead
of
egrep '^[^#]' /home/werner/.local/bin/emacs | grep -v '^[ ]*#'
using
grep -v '^ *#' /home/werner/.local/bin/emacs

No difference, but thank you for the more concise grep command:
$ grep -v '^ *#' /home/werner/.local/bin/emacs script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

$

does the same job.

Perhaps $HOME/.local/libexec/script_name.sh does something with the DISPLAY variable. I suggest modifying your script as follows

echo "Point A : the value of DISPLAY is =$DISPLAY=" script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}
echo "Point B : the value of DISPLAY is =$DISPLAY="
[ ... Rest the same ...]

werner@X10DAi pid=2452674 483$ emacs
Point A : the value of DISPLAY is ==
Point B : the value of DISPLAY is ==
[...]

I also second the advice to try running emacs directly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor <gtaylor@tnetconsulting.net> writes:

On 7/29/21 9:49 PM, hongy...@gmail.com wrote:

proxychains-ng-socks5 $EMACS "$@"

Why are you running emacs via proxychains?

That's almost definitely going to mess with it's ability to connect to
an X11 server, wherever it is, unless said proxy can communicate with
said X11 server.

Try running /usr/local/bin/emacs and seeing if that works.

That's assuming that /usr/local/bin/emacs is an executable.

You have /usr/bin/emacs, /bin/emacs, and /usr/local/bin/emacs in your
path. I'm guessing /usr/bin/emacs and /bin/emacs are the same -- but
check that. Try all three.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 12:41:55 PM UTC+8, Keith Thompson wrote:

Grant Taylor <gta...@tnetconsulting.net> writes:

On 7/29/21 9:49 PM, hongy...@gmail.com wrote:

proxychains-ng-socks5 $EMACS "$@"

Why are you running emacs via proxychains?

That's almost definitely going to mess with it's ability to connect to
an X11 server, wherever it is, unless said proxy can communicate with
said X11 server.

Try running /usr/local/bin/emacs and seeing if that works.

That's assuming that /usr/local/bin/emacs is an executable.

This is the self-compiled git master version.

You have /usr/bin/emacs, /bin/emacs, and /usr/local/bin/emacs in your
path. I'm guessing /usr/bin/emacs and /bin/emacs are the same -- but
check that. Try all three.

These are the system versions, they are equivalent:

$ realpath -e /usr/bin/emacs
/usr/bin/emacs-nox

$ realpath -e /bin/emacs
/usr/bin/emacs-nox

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 12:40:18 PM UTC+8, Keith Thompson wrote:

"hongy...@gmail.com" <hongy...@gmail.com> writes:

On Friday, July 30, 2021 at 9:00:59 AM UTC+8, Grant Taylor wrote:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I'm wondering if it's by chance a script that's artificially changing / >> overriding the DISPLAY environment variable.

I use a self-written wrapper script to start Emacs, but I really
haven't overridden the DISPLAY environment variable in the script. See
the following for more detailed info:

Then the obvious next step is to try the same thing, but running /usr/bin/emacs directly rather than your wrapper script.

$ which emacs
/home/werner/.local/bin/emacs

$ which emacs |xargs egrep '^[^#]'| grep -v '^[ ]*#' script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

Frankly, it should already have occurred to you to try invoking
the emacs executable directly. It's an added layer, and you need
to strip away any such layers while trying to figure out what's causing
the problem. Do the simplest set of steps that reproduces the problem.

Even more obvious than bypassing your wrapper script: Telling us that
you're using one. You should have mentioned that in your original post.

I didn’t realize this until I got the relevant tips here.

Don't withhold information like that, and don't make us drag it out of
you.

TBF, I really omit the fact the X11 communication is also effected by the proxy settings by proxychains.

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 12:06:09 PM UTC+8, Grant Taylor wrote:

On 7/29/21 9:49 PM, hongy...@gmail.com wrote:

proxychains-ng-socks5 $EMACS "$@"

Why are you running emacs via proxychains?

As far as this problem is concerned, I am in a dilemma: Emacs itself don't support socks5 very well, and I want to install packages from melpa and github repos, which will need socks5 proxy for working smoothly at my location.

That's almost definitely going to mess with it's ability to connect to
an X11 server, wherever it is, unless said proxy can communicate with
said X11 server.

I really have taken it for granted that X11 protocol should work seamlessly with TCP/IP stack and all standard proxy protocols built on it.

Try running /usr/local/bin/emacs and seeing if that works.

This works, as I've tested later in another thread of this issue.

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-07-30, hongy...@gmail.com <hongyi.zhao@gmail.com> wrote:

On Friday, July 30, 2021 at 9:00:59 AM UTC+8, Grant Taylor wrote:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I'm wondering if it's by chance a script that's artificially changing /
overriding the DISPLAY environment variable.

Why the *&^&(* don't you just run
/bin/emacs
and see if that works. Or are you afraid that it will work and you will
not have anything to complian about?

I use a self-written wrapper script to start Emacs, but I really haven't overridden the DISPLAY environment variable in the script. See the following for more detailed info:

So find out whether you self written script is a piece of junk and run /bin/emacs directly to see what happens.

$ which emacs
/home/werner/.local/bin/emacs

$ which emacs |xargs egrep '^[^#]'| grep -v '^[ ]*#' script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

HY

It might not be, but it's something simple to check and it quite likely
would keep it from working if such shenanigans were afoot.
--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 1:10:23 PM UTC+8, William Unruh wrote:

On 2021-07-30, hongy...@gmail.com <hongy...@gmail.com> wrote:

On Friday, July 30, 2021 at 9:00:59 AM UTC+8, Grant Taylor wrote:

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:

Xterm works, but Emacs still report the same problem.

I'm starting to question the "emacs" command.

Please do a "which emacs" and then "file /path/to/emacs" to see what
type of file emacs is.

I'm wondering if it's by chance a script that's artificially changing /
overriding the DISPLAY environment variable.

Why the *&^&(*

What's the meaning?

don't you just run
/bin/emacs
and see if that works. Or are you afraid that it will work and you will
not have anything to complian about?

I use a self-written wrapper script to start Emacs, but I really haven't overridden the DISPLAY environment variable in the script. See the following for more detailed info:

So find out whether you self written script is a piece of junk and run /bin/emacs directly to see what happens.

It's a nox version:

$ realpath -e /bin/emacs
/usr/bin/emacs-nox

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.07.2021 06:41, Keith Thompson wrote:

Grant Taylor <gtaylor@tnetconsulting.net> writes:

On 7/29/21 9:49 PM, hongy...@gmail.com wrote:

proxychains-ng-socks5 $EMACS "$@"

Why are you running emacs via proxychains?

That's almost definitely going to mess with it's ability to connect to
an X11 server, wherever it is, unless said proxy can communicate with
said X11 server.

Try running /usr/local/bin/emacs and seeing if that works.

That's assuming that /usr/local/bin/emacs is an executable.

It was listed [as such] in the type -a output. Would it be there if
it's not executable? (Rhetorical question.)

Janis

You have /usr/bin/emacs, /bin/emacs, and /usr/local/bin/emacs in your
path. I'm guessing /usr/bin/emacs and /bin/emacs are the same -- but
check that. Try all three.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.07.2021 07:10, William Unruh wrote:

Why the *&^&(* don't you just run
/bin/emacs
and see if that works. Or are you afraid that it will work and you will
not have anything to complian about?

LOL. I guess it fits with another recent post where someone changed
- because of his personal mental conception how shell scripts should
work - a *running* script or command and was wondering why it doesn't
work any more in his changed form.

But it's not untypical that folks wrap commands to "get things done",
forget about that, and when the use case changes or gets extended
they are wondering about the tools not working any more as expected
or at all.


WRT H's question what "*&^&(*" means; actually the same as "!$&%/*"
(some approximate the meaning with "f***", which is considered more
offensive, though, or the less offensive "h***").

Janis

I use a self-written wrapper script to start Emacs, but I really haven't overridden the DISPLAY environment variable in the script. See the following for more detailed info:

So find out whether you self written script is a piece of junk and run /bin/emacs directly to see what happens.

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"hongy...@gmail.com" <hongyi.zhao@gmail.com> writes:

On Friday, July 30, 2021 at 12:41:55 PM UTC+8, Keith Thompson wrote:

Grant Taylor <gta...@tnetconsulting.net> writes:

On 7/29/21 9:49 PM, hongy...@gmail.com wrote:

proxychains-ng-socks5 $EMACS "$@"

Why are you running emacs via proxychains?

That's almost definitely going to mess with it's ability to connect to
an X11 server, wherever it is, unless said proxy can communicate with
said X11 server.

Try running /usr/local/bin/emacs and seeing if that works.

That's assuming that /usr/local/bin/emacs is an executable.

This is the self-compiled git master version.

You have /usr/bin/emacs, /bin/emacs, and /usr/local/bin/emacs in your
path. I'm guessing /usr/bin/emacs and /bin/emacs are the same -- but
check that. Try all three.

These are the system versions, they are equivalent:

$ realpath -e /usr/bin/emacs
/usr/bin/emacs-nox

$ realpath -e /bin/emacs
/usr/bin/emacs-nox

The executable "emacs-nox" is a version of Emacs without X11 support.

--
Dan Espen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:

On 30.07.2021 06:41, Keith Thompson wrote:

[...]

That's assuming that /usr/local/bin/emacs is an executable.

It was listed [as such] in the type -a output. Would it be there if
it's not executable? (Rhetorical question.)

Sorry, I meant *binary* executable.

My thought was that the word "executable" when used as a noun refers to
binary executable file, not a script, but I wasn't sufficiently clear.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/21 11:35 AM, Grant Taylor wrote:

socat immediately comes to mind as providing the ability to listen on an
IP & port for local connections and translating them to the proper
SOCKS(5) call to the SOCKS(5) backend.

Another option would be to make sure that the SOCKS(5) proxy can
communicate with your local X11 server.

An external SOCKS(5) proxy will likely have quite a difficult time communicating with your local X11 server.

You could run a local SOCKS(5) proxy which can conditionally reach your
local X11 server /and/ *chain* to the external SOCKS(5) server you need
to use to access the repos. Think of this as a SOCKS(5) level router
that can pick different routes; local vs chained external SOCKS(5)
proxy, depending on the desired destination.

This is effectively augmenting the communications path that your
existing proxychains-ng-socks5 is using. ;-)

Learn about the problem, understand the problem ~> box, and then think
outside of said box. }:-)

Aside: DANTE has been my go-to SOCKS(5) proxy server for many things.
If DANTE can't provide what I need, I usually turn to parts of BadVPN
and more trickery. Trickery like adding a normal (IP) route via a
tunnel that goes into tun2socks. Tun2socks will then socksify the
traffic it receives from the tunnel interface and send it to the
configured SOCKS server. Thus you can rely on traditional routing to
decide if traffic should go through the SOCKS server or not. }:-D



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/21 12:20 PM, Keith Thompson wrote:

My thought was that the word "executable" when used as a noun refers to binary executable file, not a script, but I wasn't sufficiently clear.

You're entitled to your own opinion of what "executable" means.

But to me, an "executable" is something that you are able to execute.
And seeing as how you are able to execute binaries /and/ scripts, I
don't see why scripts would be excluded from "executables".

I tend to say "binary" and "script" when I want to differentiate between
the two. Possibly prefixing "executable " to each to differentiate
between a library when is a binary which tends to not directly executable.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/29/21 11:03 PM, hongy...@gmail.com wrote:

As far as this problem is concerned, I am in a dilemma: Emacs itself
don't support socks5 very well, and I want to install packages from
melpa and github repos, which will need socks5 proxy for working
smoothly at my location.

I read that as you need access to things in melpa / github repos that
provide SOCKS(5) interface. I also read that as emacs doesn't
(sufficiently for your needs) support SOCKS(5). Thus you need
/something/ to bridge the communications gap.

A proxifyer / socksifyer is probably the first choice. But it's not the
only choice.

Consider setting something up as a proxy (I dislike using that term when differentiating from SOCKS) of sorts. E.g. something that has normal communications that emacs can support and gateways through SOCKS(5) to
the target you need.

socat immediately comes to mind as providing the ability to listen on an
IP & port for local connections and translating them to the proper
SOCKS(5) call to the SOCKS(5) backend.

I really have taken it for granted that X11 protocol should work
seamlessly with TCP/IP stack and all standard proxy protocols built
on it.

That's probably a safe assumption for most cases. /However/ proxifyers
/ socksifyers work by leveraging LD_PRELOAD to replace the usual
networking sys calls with version that translate to the given proxy
protocol; SOCKS(5) / HTTP / etc. Thus when you use a proxifyer /
sockisfyer for a typical X11 client, you end up altering, if not
breaking, the usual network path.

This works, as I've tested later in another thread of this issue.

*nod*

So the problem definitely is not with your X11 configuration, but how
you're trying to use it.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <se41c8$oeo$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 7/30/21 12:20 PM, Keith Thompson wrote:

My thought was that the word "executable" when used as a noun refers to
binary executable file, not a script, but I wasn't sufficiently clear.

You're entitled to your own opinion of what "executable" means.

Leader Keith *is* the standard.

But to me, an "executable" is something that you are able to execute.
And seeing as how you are able to execute binaries /and/ scripts, I
don't see why scripts would be excluded from "executables".

In a sense, what we call binary executables are, in fact, scripts that are interpreted by an interpreter called "ld.so". In a sense, the only pure executable is the kernel.

Now, the above can be seen as nitpicking, but I think what Keith was
actually going for was the idea that the emacs binary executable was
probably put together by trusted people and can be assumed to be correct, whereas any shell scripts that exist as "wrappers" around the binary
executable were probably written by amateurs like you and me (and HY) and
are, thus, suspect.

We all know that if there are errors in the chain (and, it seems, in this
case, there are), they are more likely to be in the shell script wrappers rather than in the emacs binary itself.

--
The last time a Republican cared about you, you were a fetus.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-08-01, Kenny McCormack <gazelle@shell.xmission.com> wrote:

In article <se41c8$oeo$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 7/30/21 12:20 PM, Keith Thompson wrote:

My thought was that the word "executable" when used as a noun refers to
binary executable file, not a script, but I wasn't sufficiently clear.

You're entitled to your own opinion of what "executable" means.

Leader Keith *is* the standard.

But to me, an "executable" is something that you are able to execute.
And seeing as how you are able to execute binaries /and/ scripts, I
don't see why scripts would be excluded from "executables".

In a sense, what we call binary executables are, in fact, scripts that are interpreted by an interpreter called "ld.so". In a sense, the only pure executable is the kernel.

WEll, hardly. ld.so may well load the executable into memory, but then
it hands the code over to be run (directly transfered to) the cpu. It
speaks the language of the CPU, not some other language that then needs
to be interpreted. A script on the other hand, loaded directly into the
CPU would simply produce may kinds of faults. It needs a number of
layers of translation before the CPU can do anything with it.

Now, the above can be seen as nitpicking, but I think what Keith was
actually going for was the idea that the emacs binary executable was
probably put together by trusted people and can be assumed to be correct, whereas any shell scripts that exist as "wrappers" around the binary executable were probably written by amateurs like you and me (and HY) and are, thus, suspect.

We all know that if there are errors in the chain (and, it seems, in this case, there are), they are more likely to be in the shell script wrappers rather than in the emacs binary itself.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, August 1, 2021 at 1:35:17 AM UTC+8, Grant Taylor wrote:

On 7/29/21 11:03 PM, hongy...@gmail.com wrote:

As far as this problem is concerned, I am in a dilemma: Emacs itself
don't support socks5 very well, and I want to install packages from
melpa and github repos, which will need socks5 proxy for working
smoothly at my location.

I read that as you need access to things in melpa / github repos that
provide SOCKS(5) interface. I also read that as emacs doesn't
(sufficiently for your needs) support SOCKS(5). Thus you need
/something/ to bridge the communications gap.

A proxifyer / socksifyer is probably the first choice. But it's not the
only choice.

This method is generally simple to use and has many user-friendly configuration options.

Consider setting something up as a proxy (I dislike using that term when differentiating from SOCKS) of sorts. E.g. something that has normal communications that emacs can support and gateways through SOCKS(5) to
the target you need.

socat immediately comes to mind as providing the ability to listen on an
IP & port for local connections and translating them to the proper
SOCKS(5) call to the SOCKS(5) backend.

To be frank, for the problem discussed here, I still can't figure out an equivalent implementation with socat like tools.

I really have taken it for granted that X11 protocol should work
seamlessly with TCP/IP stack and all standard proxy protocols built
on it.

That's probably a safe assumption for most cases. /However/ proxifyers
/ socksifyers work by leveraging LD_PRELOAD to replace the usual
networking sys calls with version that translate to the given proxy
protocol; SOCKS(5) / HTTP / etc. Thus when you use a proxifyer /
sockisfyer for a typical X11 client, you end up altering, if not
breaking, the usual network path.

Thank you for your in-depth analysis.

This works, as I've tested later in another thread of this issue.

*nod*

So the problem definitely is not with your X11 configuration, but how
you're trying to use it.
--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/21 8:29 PM, hongy...@gmail.com wrote:

This method is generally simple to use and has many user-friendly configuration options.

Yep. When it works, it usually works well. When it doesn't ... well
that's a different story.

To be frank, for the problem discussed here, I still can't figure
out an equivalent implementation with socat like tools.

Based on a 30 second search, having done this in the past, something
like the following seems to be close to what you want.

socat TCP4-LISTEN:$LOCAL_PORT,fork SOCKS5:$SOCKS_SERVER:$REMOTE_IP:$REMOTE_PORT,socksport=$SOCKS_PORT

It will listen on $LOCAL_PORT and send connections to it to $REMOTE_PORT
on $REMOTE_IP via $SOCKS_PORT on $SOCKS_SERVER.

The idea being have as many of these listeners as you need for your
emacs client to connect to where it needs to /without/ a proxifyer.
That way emacs can connect to the local X11 server /and/ connect to the
port / IP that socat is providing.

Thank you for your in-depth analysis.

You're welcome.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, August 2, 2021 at 7:53:21 AM UTC+8, Grant Taylor wrote:

On 7/31/21 8:29 PM, hongy...@gmail.com wrote:

This method is generally simple to use and has many user-friendly configuration options.

Yep. When it works, it usually works well. When it doesn't ... well
that's a different story.

To be frank, for the problem discussed here, I still can't figure
out an equivalent implementation with socat like tools.

Based on a 30 second search, having done this in the past, something
like the following seems to be close to what you want.

socat TCP4-LISTEN:$LOCAL_PORT,fork SOCKS5:$SOCKS_SERVER:$REMOTE_IP:$REMOTE_PORT,socksport=$SOCKS_PORT

It will listen on $LOCAL_PORT and send connections to it to $REMOTE_PORT
on $REMOTE_IP via $SOCKS_PORT on $SOCKS_SERVER.

Some relevant questions:

1. For my case, I don't have a specific $REMOTE_IP:$REMOTE_PORT, instead, I want to proxy most non-local Internet access.

2. How to let Emacs communicates with the $LOCAL_PORT, i.e., the socat's listening port?

The idea being have as many of these listeners as you need for your
emacs client to connect to where it needs to /without/ a proxifyer.
That way emacs can connect to the local X11 server /and/ connect to the
port / IP that socat is providing.

Thank you for your in-depth analysis.

You're welcome.
--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/21 7:08 PM, hongy...@gmail.com wrote:

Some relevant questions:

1. For my case, I don't have a specific $REMOTE_IP:$REMOTE_PORT,
instead, I want to proxy most non-local Internet access.

Then you are going to need to get in and very personal with the traffic
to find out how you can route various things.

Sometimes you can use what I call SSH local port forwarding ... Anycast
Style [1] for one or more ports on one or more IPs.

Sometimes you need to configure traditional proxy support via
environment variables; e.g. http_proxy, et al.

Sometimes you need to get really creative.

You will need to really understand your desired traffic flow and combine various techniques to do what you want.

2. How to let Emacs communicates with the $LOCAL_PORT, i.e., the
socat's listening port?

Don't run it through a proxifyer. emacs should try to connect using the non-hijacked system calls.

[1] SSH local port forwarding ... Anycast Style
- https://dotfiles.tnetconsulting.net/articles/2014/0303/ssh-local-port-forwarding-anycast-style.html



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, August 2, 2021 at 12:48:09 PM UTC+8, Grant Taylor wrote:

On 8/1/21 7:08 PM, hongy...@gmail.com wrote:

Some relevant questions:

1. For my case, I don't have a specific $REMOTE_IP:$REMOTE_PORT,
instead, I want to proxy most non-local Internet access.

Then you are going to need to get in and very personal with the traffic
to find out how you can route various things.

Sometimes you can use what I call SSH local port forwarding ... Anycast Style [1] for one or more ports on one or more IPs.

Sometimes you need to configure traditional proxy support via
environment variables; e.g. http_proxy, et al.

Sometimes you need to get really creative.

You will need to really understand your desired traffic flow and combine various techniques to do what you want.

2. How to let Emacs communicates with the $LOCAL_PORT, i.e., the
socat's listening port?

Don't run it through a proxifyer. emacs should try to connect using the non-hijacked system calls.

Why? As you can see, except the problem discussed here, I still can work with Emacs smoothly with a proxifyer like proxychins-ng. Another thing to note, for the problem disscussed here, the more elegant solution is to use the proxychins-ng's localnet
directive, i.e., set the following in its conf file:

localnet 127.0.0.0/255.0.0.0
localnet 10.0.0.0/255.0.0.0
localnet 172.16.0.0/255.240.0.0
localnet 192.168.0.0/255.255.0.0

See <https://github.com/rofl0r/proxychains-ng/issues/388#issuecomment-889968946> for more detailed info.

[1] SSH local port forwarding ... Anycast Style
- https://dotfiles.tnetconsulting.net/articles/2014/0303/ssh-local-port-forwarding-anycast-style.html

Thank you for telling me this trick, but it looks rather cumbersome.

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/2/21 8:10 AM, hongy...@gmail.com wrote:

Why? As you can see, except the problem discussed here, I still can
work with Emacs smoothly with a proxifyer like proxychins-ng.
Another thing to note, for the problem disscussed here, the more
elegant solution is to use the proxychins-ng's localnet directive,
i.e., set the following in its conf file:

I agree, using proxychains-ng's localnet feature is probably better in
this situation. I've never used proxychains-ng so I wasn't aware of it.

The proxifiers that I've used in the past didn't have such capability.

You need to know your tools, what they are capable of, and how to use
that capability.

Thank you for telling me this trick, but it looks rather cumbersome.

It's non-trivial and was written for accessing things like remote iLO /
RSA / IMM / DRACs buried deep in networks that had no normal routing to
them.

Bind the target IP locally, use SSH remote port forwarding to bind the
port(s) in question, connect to the web interface via forwarded port,
let the (at the time) Java / ActiveX code connect to what it thought was
the remote IP / ports locally, ssh forward things, and profit. It is a non-trivial solution to a complex problem. I found that many such
clients weren't conducive to changing IPs (to use localhost with
traditional port forwarding) / hostname(s) / ports. There were LOTS of
hard coded assumptions. This usually involved at least two discrete technologies; HTTP and Java or ActiveX, and frequently involved SSL certificates. So, making the expected IP & port available locally was
by far the easiest solution.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, August 2, 2021 at 11:50:57 PM UTC+8, Grant Taylor wrote:

On 8/2/21 8:10 AM, hongy...@gmail.com wrote:

Why? As you can see, except the problem discussed here, I still can
work with Emacs smoothly with a proxifyer like proxychins-ng.
Another thing to note, for the problem disscussed here, the more
elegant solution is to use the proxychins-ng's localnet directive,
i.e., set the following in its conf file:

I agree, using proxychains-ng's localnet feature is probably better in
this situation. I've never used proxychains-ng so I wasn't aware of it.

The proxifiers that I've used in the past didn't have such capability.

You need to know your tools, what they are capable of, and how to use
that capability.

Thank you for telling me this trick, but it looks rather cumbersome.

It's non-trivial and was written for accessing things like remote iLO /
RSA / IMM / DRACs buried deep in networks that had no normal routing to
them.

What's the exact meaning of "iLO / RSA / IMM / DRACs" used above?

Bind the target IP locally, use SSH remote port forwarding to bind the
port(s) in question, connect to the web interface via forwarded port,
let the (at the time) Java / ActiveX code connect to what it thought was
the remote IP / ports locally, ssh forward things, and profit. It is a non-trivial solution to a complex problem. I found that many such
clients weren't conducive to changing IPs (to use localhost with
traditional port forwarding) / hostname(s) / ports. There were LOTS of
hard coded assumptions. This usually involved at least two discrete technologies; HTTP and Java or ActiveX, and frequently involved SSL certificates. So, making the expected IP & port available locally was
by far the easiest solution.

Thank you for your in-depth explanation.

HY

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/2/21 8:02 PM, hongy...@gmail.com wrote:

What's the exact meaning of "iLO / RSA / IMM / DRACs" used above?

Uh ... now you're testing my grey matter.

Compaq ~> HP ~> HPE: Integrated Lights Out (card / controller)

IBM: Remote Server Administrator / Integrated Management Module

Dell: Dell Remote Access Controller

While I'm at it, Sun ~> Oracle has System Console / Remote System
Console / Lights Out Manager / Integrated Lights Out Manager / Advanced
Lights Out Manager.

Something like that.

They are all vendor proprietary.

Intelligent Platform Management Interface (?) is the vendor agnostic
(subset) counterpart.

Thank you for your in-depth explanation.

You're welcome.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)