On 29.07.2021 04:51, hongy...@gmail.com wrote:
> 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?

From the environment. (As the man page also tells you.)

Janis

> HY
>

"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 */

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

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

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

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

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

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

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 */

"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 */

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

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 */

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

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

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.

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 */

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

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.

"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 */

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.

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 */

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

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

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

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