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

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.
>

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.
>
>>[...]

"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

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

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

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

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