Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
2020/08/07 20:03 ... Thorsten Glaser: Using (char *)-1 can cause traps on some platforms, or the compiler to replace the entire codepath (including backwards!) with nōnsense. And if the platform is x86, what of long and short pointers? Or do all the C-compilers use only the longest? If pointer value is -1, what does the compiler to make it longer when called for, and how does it know that it is? ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Thorsten Glaser wrote in
:
|Steffen Nurpmeso dixit:
|
||>> socks5_proxy = _value;
|
|Just use that; the file already has a magic value
|you can use (hostname).
Whereas this is true, i still do not see the problem here really.
lynx uses (PTR)-1 itself, at least in src/tidy_tls.c, and it even
seems to have been written by Thomas Dickey himself!?!
Until absolutely necessary i will not exchange a builtin fixed
constant with some symbol that the linker must resolve
dynamically! I mean, for nothing???
|bye,
|//mirabilos
|--
|“It is inappropriate to require that a time represented as
| seconds since the Epoch precisely represent the number of
| seconds between the referenced time and the Epoch.”
| -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
I would really like to have CLOCK_TAI in the standard, getting rid
of leapsecond noise in calculations. ('Being all in favour of
keeping UTC aligned with the sun, whatever this means. However,
it seems we will not see leap seconds for a couple of more years,
if i read that right:
I believe there will be several years between the the last leap second
and the next, as there was between December 31, 1998 and December 31,
2005. The IERS publishes a long-term prediction of the average
rotation rate of the Earth, which they update in their Bulletin A each
week. The August 6, 2020, issue of Bulletin A contains this line:
UT1-UTC = -0.2147 - 0.00010 (MJD - 59075) - (UT2-UT1)
UT2 captures the seasonal change in the length of day, so it can be
ignored for long-term estimates. The important number, therefore, is
-0.00010, which I will call the UT1 slope.
The June 9, 2016, issue of Bulletin A contains this line:
UT1-UTC = -0.1734 - 0.00147 (MJD - 57556) - (UT2-UT1)
Which has UT1 slope equal to -0.00147. Since then the value of UT1
slope has increased steadily to its present value. It is larger now
than it has been at any time since January 6, 2005, which is the oldest
issue of Bulletin A that I have been able to locate. Based on the
current value of -0.00010 I estimate that the next leap second will be
on December 31, 2025, an interval of 9 years, which is longer than the
previous long interval of 7 years.
Hm.)
--End of
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
[...(char *)-1...] > You know -- i for one do not care about the issue, Ah. Then, goodbye. If you don't even care about portability issues in lynx, there I have nothing more of value to contribute to this thread. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Steffen Nurpmeso dixit: |>> socks5_proxy = _value; Just use that; the file already has a magic value you can use (hostname). bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Mouse wrote in <202008081942.paa25...@stone.rodents-montreal.org>: |>> So, in summary, except for the null-pointer-constant special case, |>> converting integers to pointers is intended to be useful in |>> machine-dependent code, but is not portable beyond that. |> ISO C99 specifies intptr_t and uintptr_t though, | |Yes - but there is no promise that an intptr_t or uintptr_t obtained in |any way other than casting a pointer-to-void to it will convert to |anything useful. | |Also, it says that "[t]hese types are optional"; they do not have to |exist. You know -- i for one do not care about the issue, i have always done that, as below. The point for me was lynx tests for and uses intptr_t, and provides a "long" fallback i'd say (from git grep output, i have no idea of autotools). |> and POSIX [...] has a notion of (PTR)-1 for long, |I'm not sure whether "for long" here is "for a long time" or whether it |has something to do with C's long type. Also, "has a notion of" is |notably imprecise; what exactly does POSIX specify about them? | |> just "recently" (in Issue 6) gave (void*)-1 the symbolic MAP_FAILED |> constant name. | |Ugh. Mandating what something like MAP_FAILED epxands to defeats much |of the point of giving it a symbolic name. They converted the "magic" use of (void*)-1 to a specific MAP_FAILED. |But I don't think that means it has to differ from (void *)0, or any |other specific void * not obtained from mmap, though, does it? |MAP_FAILED just has to differ from any possible valid mmap return, or |at least that's what (little) I've read says. No, they got away from (void*)-1 to MAP_FAILED. |> It never hit me, i always used (register-sized-integer)/(pointer) |> back and forth casting. | |And, I would hazard the guess, you have always been using mainstream |hardware and OSes. As I said, Yes, that is true. Two's-complement, sizeof(void*)=="sizeof(size_t)" only. |>> On most current systems, no, it won't cause trouble; it will do |>> pretty much what you presumably expect. | |And, if you don't care about portability beyond "most current systems", |then, sure, go for it. | |But, as I also wrote, | |>> I would hope that lynx wants to be more portable than that, though. | |As for | |>> char magic_value; // maybe static, if not needed beyond file scope | |>> socks5_proxy = _value; |>>... |>> if (socks5_proxy == _value) ... | |> Really not!! If so then (char*)(intptr_t)-1! | |This is slightly less portable than (char *)-1 (slightly less because |intptr_t is an optional type, and no more because (a) the intptr_t in |question was not obtained by casting a void * and thus there are no |promises about what it may convert to and (b) because you're casting it |to char *, something about which no promsies are made anyway - the |promises are about converting intptr_t to void *). | |I can't make you write portable code. Nor would I if I could. But, |with a project like lynx that I care about, I do feel a duty to call |out blatant nonportabilities as such. If lynx lets this sort of code |in, I'll be disappointed in them, but that's about where it'll end. If |I get bitten by a resulting portability lose, I'll deal with that when |it happens, like any other portability lose. That is utter rubbish, Mouse. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
>> So, in summary, except for the null-pointer-constant special case, >> converting integers to pointers is intended to be useful in >> machine-dependent code, but is not portable beyond that. > ISO C99 specifies intptr_t and uintptr_t though, Yes - but there is no promise that an intptr_t or uintptr_t obtained in any way other than casting a pointer-to-void to it will convert to anything useful. Also, it says that "[t]hese types are optional"; they do not have to exist. > and POSIX [...] has a notion of (PTR)-1 for long, I'm not sure whether "for long" here is "for a long time" or whether it has something to do with C's long type. Also, "has a notion of" is notably imprecise; what exactly does POSIX specify about them? > just "recently" (in Issue 6) gave (void*)-1 the symbolic MAP_FAILED > constant name. Ugh. Mandating what something like MAP_FAILED epxands to defeats much of the point of giving it a symbolic name. But I don't think that means it has to differ from (void *)0, or any other specific void * not obtained from mmap, though, does it? MAP_FAILED just has to differ from any possible valid mmap return, or at least that's what (little) I've read says. > It never hit me, i always used (register-sized-integer)/(pointer) > back and forth casting. And, I would hazard the guess, you have always been using mainstream hardware and OSes. As I said, >> On most current systems, no, it won't cause trouble; it will do >> pretty much what you presumably expect. And, if you don't care about portability beyond "most current systems", then, sure, go for it. But, as I also wrote, >> I would hope that lynx wants to be more portable than that, though. As for >> char magic_value; // maybe static, if not needed beyond file scope >> socks5_proxy = _value; >>... >> if (socks5_proxy == _value) ... > Really not!! If so then (char*)(intptr_t)-1! This is slightly less portable than (char *)-1 (slightly less because intptr_t is an optional type, and no more because (a) the intptr_t in question was not obtained by casting a void * and thus there are no promises about what it may convert to and (b) because you're casting it to char *, something about which no promsies are made anyway - the promises are about converting intptr_t to void *). I can't make you write portable code. Nor would I if I could. But, with a project like lynx that I care about, I do feel a duty to call out blatant nonportabilities as such. If lynx lets this sort of code in, I'll be disappointed in them, but that's about where it'll end. If I get bitten by a resulting portability lose, I'll deal with that when it happens, like any other portability lose. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Mouse wrote in <202008080031.uaa13...@stone.rodents-montreal.org>: |>>> + socks5_proxy =3D (char*)-1; |>> Don=E2=80=99t do that, that is not portable. |> Really?? This i do not understand. | |Casting an integer, other than a compile-time constant expression with |value 0, to a pointer? That is never portable. (char *)-1 could do |anything from trapping immediately to producing a nil pointer to |producing a pointer that happens to match something else in live use |to, well, pretty much anything. C99 says (6.3.2.3) | | [#5] An integer may be converted to any pointer type. | Exceptaspreviouslyspecified, the result is | implementation-defined, might not be correctly aligned, | might not point to an entity of the referenced type, and | might be a trap representation.56) | |The "previously specified" text covers, in [#3], the "integer constant |expression with value 0" case I mentioned above, in which case the |conversion is required to yield a nil pointer (C99 calls this a null |pointer; I don't like that name because of the confusion surrounding |NULL - see http://ftp.rodents-montreal.org/mouse/blah/2009-10-09-1.html |for my thoughts on that). ([#1], [#2], and [#4] cover conversions |between various pointer types, not relevant to converting integers to |pointers.) | |"[I]mplementation-defined" means, among other things, that the next |implementation over may do something completely different from whatever |it is you expect. | |Footnote 56 says | | 56)The mapping functions for converting a pointer to an | integer or an integer to a pointer are intended to be | consistent with the addressing structure of the execution | environment. | |So, in summary, except for the null-pointer-constant special case, |converting integers to pointers is intended to be useful in |machine-dependent code, but is not portable beyond that. ISO C99 specifies intptr_t and uintptr_t though, and POSIX has a notion of (PTR)-1 for long, just "recently" (in Issue 6) gave (void*)-1 the symbolic MAP_FAILED constant name. It never hit me, i always used (register-sized-integer)/(pointer) back and forth casting. |On most current systems, no, it won't cause trouble; it will do pretty |much what you presumably expect. (While I didn't see enough context to |really know what you expect, most such suggestions come from a mindset |that I can perhaps summarize as "I thought every computer worked the |way mine does", which these days usually means either Windows or Linux |running on x86 or x64.) In code that's not intended to be portable |beyond "most current systems", it may be fine. I would hope that lynx |wants to be more portable than that, though. | |If you want a distinguished char * pointer that is not nil, the simple |_portable_ thing to do is to allocate a char and point to it: | |char magic_value; // maybe static, if not needed beyond file scope | | socks5_proxy = _value; |... | if (socks5_proxy == _value) ... Really not!! If so then (char*)(intptr_t)-1! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Hello. Thorsten Glaser wrote in : |Steffen Nurpmeso dixit: | |>Really?? This i do not understand. | |You’re only allowed to take pointers to actual objects. |It should probably be possible to use NULL somewhere, |but you can use as magic pointer. | |Using (char *)-1 can cause traps on some platforms, or |the compiler to replace the entire codepath (including |backwards!) with nōnsense. Well, hm, but not on POSIX compatible platforms for sure. MAP_FAILED for example is now explicitly defined (since Issue 6) where (void*)-1 was formerly used (also by the standard). There is also (iconv_t)-1 standardized, where iconv_t is usually a pointer. So this ISO C, then. Hm. But ok, i can use intptr_t, it is already used in the lynx code. Thanks for pointing this out. | |bye, |//mirabilos |-- |In traditional syntax ' is ignored, but in c99 everything between two ' is |handled as character constant. Therefore you cannot use ' in a preproces- |sing file in c99 mode.-- Ragge He unfortunately seems to leave. For weeks the server was totally gone, now at least the name resolves, but i cannot access it nonetheless. I really like pcc. |No faith left in ISO C99, undefined behaviour, etc. --End of Ciao, and a nice Sunday! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
>>> + socks5_proxy =3D (char*)-1; >> Don=E2=80=99t do that, that is not portable. > Really?? This i do not understand. Casting an integer, other than a compile-time constant expression with value 0, to a pointer? That is never portable. (char *)-1 could do anything from trapping immediately to producing a nil pointer to producing a pointer that happens to match something else in live use to, well, pretty much anything. C99 says (6.3.2.3) [#5] An integer may be converted to any pointer type. Exceptaspreviouslyspecified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.56) The "previously specified" text covers, in [#3], the "integer constant expression with value 0" case I mentioned above, in which case the conversion is required to yield a nil pointer (C99 calls this a null pointer; I don't like that name because of the confusion surrounding NULL - see http://ftp.rodents-montreal.org/mouse/blah/2009-10-09-1.html for my thoughts on that). ([#1], [#2], and [#4] cover conversions between various pointer types, not relevant to converting integers to pointers.) "[I]mplementation-defined" means, among other things, that the next implementation over may do something completely different from whatever it is you expect. Footnote 56 says 56)The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to be consistent with the addressing structure of the execution environment. So, in summary, except for the null-pointer-constant special case, converting integers to pointers is intended to be useful in machine-dependent code, but is not portable beyond that. On most current systems, no, it won't cause trouble; it will do pretty much what you presumably expect. (While I didn't see enough context to really know what you expect, most such suggestions come from a mindset that I can perhaps summarize as "I thought every computer worked the way mine does", which these days usually means either Windows or Linux running on x86 or x64.) In code that's not intended to be portable beyond "most current systems", it may be fine. I would hope that lynx wants to be more portable than that, though. If you want a distinguished char * pointer that is not nil, the simple _portable_ thing to do is to allocate a char and point to it: char magic_value; // maybe static, if not needed beyond file scope socks5_proxy = _value; ... if (socks5_proxy == _value) ... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Steffen Nurpmeso dixit: >Really?? This i do not understand. You’re only allowed to take pointers to actual objects. It should probably be possible to use NULL somewhere, but you can use as magic pointer. Using (char *)-1 can cause traps on some platforms, or the compiler to replace the entire codepath (including backwards!) with nōnsense. bye, //mirabilos -- In traditional syntax ' is ignored, but in c99 everything between two ' is handled as character constant. Therefore you cannot use ' in a preproces- sing file in c99 mode. -- Ragge No faith left in ISO C99, undefined behaviour, etc. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
!#!@!!!
Thorsten Glaser wrote in
:
|Steffen Nurpmeso dixit:
|
||+ socks5_proxy = (char*)-1;
|
|Don’t do that, that is not portable.
Really?? This i do not understand.
|| cleanup:
||-if (socks5_proxy != NULL) {
||+if (socks5_proxy != (char*)-1) {
|| FREE(socks5_new_url);
|| FREE(socks5_protocol);
|| FREE(socks5_host);
|
|If this is just for freeing… free(3) takes NULL as no-op.
|Otherwise, find a better way to flag this.
|
|Your patch also changes something wrt. socks5_orig_url.
That is just plain terrible! What a mess.
Thanks a lot for looking into the patch, Thorsten!
Well, at least this shows i use lynx exclusively via -socks5_proxy
ever since the functionality is there.
Fixed, and tested with _and_without_ -socks5_proxy.
(The patch applies to the git snapshot, not the dev5 ball, due to
manual page, the former has the first, the latter the, hmm,
latter.
-.B \-socks5\-proxy=URL
-.B \-socks5-proxy=URL
Ciao, and a nice weekend.
Good night.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
diff --git a/WWW/Library/Implementation/HTTCP.c b/WWW/Library/Implementation/HTTCP.c
index 2834c2c7..49be41f3 100644
--- a/WWW/Library/Implementation/HTTCP.c
+++ b/WWW/Library/Implementation/HTTCP.c
@@ -1847,8 +1847,13 @@ int HTDoConnect(const char *url,
*s = -1; /* nothing is open yet */
-/* In case of a present SOCKS5 proxy, marshal */
-if ((socks5_orig_url = socks5_proxy) != NULL) {
+/* In case of a present SOCKS5 proxy, marshal.
+ * Perform a getenv(3) lookup only once */
+if (socks5_proxy == NULL &&
+ (socks5_proxy = getenv("SOCKS5_PROXY")) == NULL)
+ socks5_proxy = (char*)-1;
+
+if (socks5_proxy != (char*)-1) {
int xport;
xport = default_port;
@@ -2264,7 +2269,7 @@ int HTDoConnect(const char *url,
#endif /* INET6 */
/* Now if this was a SOCKS5 proxy connection, go for the real one */
-if (status >= 0 && socks5_orig_url != NULL) {
+if (status >= 0 && socks5_proxy != (char*)-1) {
unsigned char pbuf[4 + 1 + 255 + 2];
unsigned i;
@@ -2393,7 +2398,7 @@ int HTDoConnect(const char *url,
}
cleanup:
-if (socks5_proxy != NULL) {
+if (socks5_proxy != (char*)-1) {
FREE(socks5_new_url);
FREE(socks5_protocol);
FREE(socks5_host);
diff --git a/lynx.man b/lynx.man
index 14927858..4b8ca61a 100644
--- a/lynx.man
+++ b/lynx.man
@@ -805,9 +805,16 @@ If enabled the transfer rate is shown in bytes/second.
If disabled, no transfer rate is shown.
Use lynx.cfg or the options menu to select KB/second and/or ETA.
.TP
-.B \-socks5\-proxy=URL
-(Via which) SOCKS5 proxy to connect.
-This controls the builtin SOCKS5 support, and is therefore unrelated to
+.B \-socks5_proxy=URL
+(Via which) SOCKS5 proxy to connect: any network traffic, including all
+DNS resolutions but the one for URL itself, will be redirected through
+the SOCKS5 proxy.
+URL may be given as \*(``proxy.example.com\*('',
+\*(``proxy.example.com:1080\*('', \*(``192.168.0.1\*('', or
+\*(``192.168.0.1:1080\*('' (and IPv6 notation if so supported).
+A SOCKS5 proxy may also be specified via the environment variable
+.B SOCKS5_PROXY .
+This option controls the builtin SOCKS5 support, which is unrelated to
the option \fB\-nosocks\fP.
.TP
.B \-soft_dquotes
@@ -1138,6 +1145,11 @@ wais_proxy
.IP
See \fBLynx Users Guide\fR for additional details and examples.
.TP
+.B SOCKS5_PROXY
+Is inspected if
+.B \-socks5_proxy
+has not been used (for the same content).
+.TP
.B SSL_CERT_DIR
Set to the directory containing trusted certificates.
.TP
diff --git a/src/LYMain.c b/src/LYMain.c
index 6d5166d4..45fc3ce2 100644
--- a/src/LYMain.c
+++ b/src/LYMain.c
@@ -3916,7 +3916,7 @@ saves session to that file on exit"
),
#endif
PARSE_STR(
- "socks5-proxy", 2|NEED_LYSTRING_ARG, socks5_proxy,
+ "socks5_proxy", 2|NEED_LYSTRING_ARG, socks5_proxy,
"=URL\n(via which) SOCKS5 proxy to connect (unrelated to -nosocks!)"
),
PARSE_SET(
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Steffen Nurpmeso dixit:
|+ socks5_proxy = (char*)-1;
Don’t do that, that is not portable.
| cleanup:
|-if (socks5_proxy != NULL) {
|+if (socks5_proxy != (char*)-1) {
| FREE(socks5_new_url);
| FREE(socks5_protocol);
| FREE(socks5_host);
If this is just for freeing… free(3) takes NULL as no-op.
Otherwise, find a better way to flag this.
Your patch also changes something wrt. socks5_orig_url.
bye,
//mirabilos
--
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (389 (415) bugs: 1 RC, 264 (283) I, 124 (131) M, 0 F)
‣ src:dash (90 (105) bugs: 0 RC, 48 (52) I, 42 (53) M, 0 F)
‣ src:mksh (0 bugs: 0 RC, 0 I, 0 M, 0 F)
dash has two RC bugs they just closed because they don’t care about quality…
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Hello.
In April i sent a message saying
Steffen Nurpmeso wrote in
<20200421152638.pl92s%stef...@sdaoden.eu>:
|Please find attached an extension to the -socks5-proxy patch that
|made it in. On FreeBSD, they have started adding support for
|a $SOCKS5_PROXY environment variable, see for example commit
|[bf579e30a4d54a2d7203cdb1d1689dde46db5db6]:
|
| ...
| This change adds SOCKS5 support to the library fetch(3) and
| updates the man page.
|
| Details: Within the fetch_connect() function, fetch(3) checks if
| the SOCKS5_PROXY environment variable is set. If so, it connects
| to this host rather than the end-host. It then initializes the
| SOCKS5 connection in
| ...
|
|I felt it would be nice to integrate within this automatic proxy
|selection and added support for the MUA i maintain (in as of
|v14.9.18), and here is the same for lynx.
|
|I also changed the option name -socks5-proxy to -socks5_proxy,
|i apologise for creating an option name that stands out from all
|other options at first. Sorry.
|
|Better documentation comes as part of this, too.
|
|Ciao and good luck everybody from Germany,
...
Is there any interest in that?
|diff --git a/WWW/Library/Implementation/HTTCP.c b/WWW/Library/Implementa\
|tion/HTTCP.c
|index 2834c2c7..e3ef663e 100644
|--- a/WWW/Library/Implementation/HTTCP.c
|+++ b/WWW/Library/Implementation/HTTCP.c
|@@ -1847,8 +1847,13 @@ int HTDoConnect(const char *url,
|
| *s = -1; /* nothing is open yet */
|
|-/* In case of a present SOCKS5 proxy, marshal */
|-if ((socks5_orig_url = socks5_proxy) != NULL) {
|+/* In case of a present SOCKS5 proxy, marshal.
|+ * Perform a getenv(3) lookup only once */
|+if (socks5_proxy == NULL &&
|+ (socks5_proxy = getenv("SOCKS5_PROXY")) == NULL)
|+ socks5_proxy = (char*)-1;
|+
|+if (socks5_proxy != (char*)-1) {
| int xport;
|
| xport = default_port;
|@@ -2393,7 +2398,7 @@ int HTDoConnect(const char *url,
|}
|
| cleanup:
|-if (socks5_proxy != NULL) {
|+if (socks5_proxy != (char*)-1) {
| FREE(socks5_new_url);
| FREE(socks5_protocol);
| FREE(socks5_host);
|diff --git a/lynx.man b/lynx.man
|index e1900a28..5b6e011c 100644
|--- a/lynx.man
|+++ b/lynx.man
|@@ -805,9 +805,16 @@ If enabled the transfer rate is shown in bytes/second.
| If disabled, no transfer rate is shown.
| Use lynx.cfg or the options menu to select KB/second and/or ETA.
| .TP
|-.B \-socks5-proxy=URL
|-(Via which) SOCKS5 proxy to connect.
|-This controls the builtin SOCKS5 support, and is therefore unrelated to
|+.B \-socks5_proxy=URL
|+(Via which) SOCKS5 proxy to connect: any network traffic, including all
|+DNS resolutions but the one for URL itself, will be redirected through
|+the SOCKS5 proxy.
|+URL may be given as \*(``proxy.example.com\*('',
|+\*(``proxy.example.com:1080\*('', \*(``192.168.0.1\*('', or
|+\*(``192.168.0.1:1080\*('' (and IPv6 notation if so supported).
|+A SOCKS5 proxy may also be specified via the environment variable
|+.B SOCKS5_PROXY .
|+This option controls the builtin SOCKS5 support, which is unrelated to
| the option \fB\-nosocks\fP.
| .TP
| .B \-soft_dquotes
|@@ -1139,6 +1146,11 @@ wais_proxy
| .IP
| See \fBLynx Users Guide\fR for additional details and examples.
| .TP
|+.B SOCKS5_PROXY
|+Is inspected if
|+.B \-socks5_proxy
|+has not been used (for the same content).
|+.TP
| .B SSL_CERT_DIR
| Set to the directory containing trusted certificates.
| .TP
|diff --git a/src/LYMain.c b/src/LYMain.c
|index 6d5166d4..45fc3ce2 100644
|--- a/src/LYMain.c
|+++ b/src/LYMain.c
|@@ -3916,7 +3916,7 @@ saves session to that file on exit"
|),
| #endif
|PARSE_STR(
|- "socks5-proxy",2|NEED_LYSTRING_ARG,socks5_proxy,
|+ "socks5_proxy",2|NEED_LYSTRING_ARG,socks5_proxy,
| "=URL\n(via which) SOCKS5 proxy to connect (unrelated to -nosocks!)"
|),
|PARSE_SET(
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
[Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Hello.
Please find attached an extension to the -socks5-proxy patch that
made it in. On FreeBSD, they have started adding support for
a $SOCKS5_PROXY environment variable, see for example commit
[bf579e30a4d54a2d7203cdb1d1689dde46db5db6]:
...
This change adds SOCKS5 support to the library fetch(3) and
updates the man page.
Details: Within the fetch_connect() function, fetch(3) checks if
the SOCKS5_PROXY environment variable is set. If so, it connects
to this host rather than the end-host. It then initializes the
SOCKS5 connection in
...
I felt it would be nice to integrate within this automatic proxy
selection and added support for the MUA i maintain (in as of
v14.9.18), and here is the same for lynx.
I also changed the option name -socks5-proxy to -socks5_proxy,
i apologise for creating an option name that stands out from all
other options at first. Sorry.
Better documentation comes as part of this, too.
Ciao and good luck everybody from Germany,
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
diff --git a/WWW/Library/Implementation/HTTCP.c b/WWW/Library/Implementation/HTTCP.c
index 2834c2c7..e3ef663e 100644
--- a/WWW/Library/Implementation/HTTCP.c
+++ b/WWW/Library/Implementation/HTTCP.c
@@ -1847,8 +1847,13 @@ int HTDoConnect(const char *url,
*s = -1; /* nothing is open yet */
-/* In case of a present SOCKS5 proxy, marshal */
-if ((socks5_orig_url = socks5_proxy) != NULL) {
+/* In case of a present SOCKS5 proxy, marshal.
+ * Perform a getenv(3) lookup only once */
+if (socks5_proxy == NULL &&
+ (socks5_proxy = getenv("SOCKS5_PROXY")) == NULL)
+ socks5_proxy = (char*)-1;
+
+if (socks5_proxy != (char*)-1) {
int xport;
xport = default_port;
@@ -2393,7 +2398,7 @@ int HTDoConnect(const char *url,
}
cleanup:
-if (socks5_proxy != NULL) {
+if (socks5_proxy != (char*)-1) {
FREE(socks5_new_url);
FREE(socks5_protocol);
FREE(socks5_host);
diff --git a/lynx.man b/lynx.man
index e1900a28..5b6e011c 100644
--- a/lynx.man
+++ b/lynx.man
@@ -805,9 +805,16 @@ If enabled the transfer rate is shown in bytes/second.
If disabled, no transfer rate is shown.
Use lynx.cfg or the options menu to select KB/second and/or ETA.
.TP
-.B \-socks5-proxy=URL
-(Via which) SOCKS5 proxy to connect.
-This controls the builtin SOCKS5 support, and is therefore unrelated to
+.B \-socks5_proxy=URL
+(Via which) SOCKS5 proxy to connect: any network traffic, including all
+DNS resolutions but the one for URL itself, will be redirected through
+the SOCKS5 proxy.
+URL may be given as \*(``proxy.example.com\*('',
+\*(``proxy.example.com:1080\*('', \*(``192.168.0.1\*('', or
+\*(``192.168.0.1:1080\*('' (and IPv6 notation if so supported).
+A SOCKS5 proxy may also be specified via the environment variable
+.B SOCKS5_PROXY .
+This option controls the builtin SOCKS5 support, which is unrelated to
the option \fB\-nosocks\fP.
.TP
.B \-soft_dquotes
@@ -1139,6 +1146,11 @@ wais_proxy
.IP
See \fBLynx Users Guide\fR for additional details and examples.
.TP
+.B SOCKS5_PROXY
+Is inspected if
+.B \-socks5_proxy
+has not been used (for the same content).
+.TP
.B SSL_CERT_DIR
Set to the directory containing trusted certificates.
.TP
diff --git a/src/LYMain.c b/src/LYMain.c
index 6d5166d4..45fc3ce2 100644
--- a/src/LYMain.c
+++ b/src/LYMain.c
@@ -3916,7 +3916,7 @@ saves session to that file on exit"
),
#endif
PARSE_STR(
- "socks5-proxy", 2|NEED_LYSTRING_ARG, socks5_proxy,
+ "socks5_proxy", 2|NEED_LYSTRING_ARG, socks5_proxy,
"=URL\n(via which) SOCKS5 proxy to connect (unrelated to -nosocks!)"
),
PARSE_SET(
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
