Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Thomas Dickey wrote: > > In #1, the system setting will override STARTFILE; you'll only see > > abc.def if the system didn't specify STARTFILE. In #2, your setting > > always overrides. Either could be what you mean, you just have to know > > what it is that you mean to mean... > > I'd regard that as obvious: lynx processes the configuration information > in the order that it's given. The existing wording in lynx.cfg suggests > using the include first, and then your own customizations. Of course it's obvious to someone who's been working on the code for decades :) This is always a question with any sort of settings-with-includes setup. Sometimes the settings act like constants -- first mention wins, others either produce warnings or are ignored. Sometimes they act like variables -- last mention wins. Sometimes the winner depends on which input files are 'privileged' (like the system-owned lynx.cfg). > (patches for suggested improvements appreciated) # and now your own tweaks. # + # Lines are scanned in the order seen and the last mention of a setting 'wins'. + # To provide defaults which you will allow the INCLUDE to supersede, list them + # first. To have your own settings take precedence, list them last: + # + # # System admin may want to override this huge SESSION_LIMIT + # SESSION_LIMIT:5 + # + # # Pick up local settings + # INCLUDE:/usr/local/lib/lynx.cfg + # + # # But my STARTFILE rules supreme! + # STARTFILE:https://my.favorite.site/ + # # Starting with Lynx 2.8.2, the INCLUDE facility is yet more powerful. You can # suppress all but specific settings that will be read from included files. > > PS: there's also a LYNX_CFG_PATH environment variable. A system admin > > could do something like: > > in the manual page: > >LYNX_CFG_PATHIf set, this variable overrides the compiled-in > search-list of directories used to find the > configuration files, e.g., lynx.cfg and lynx.lss. > The list is delimited with ":" (or ";" for > Windows) like the PATH environment variable. Right, I just mentioned it because not everyone has read or fully absorbed the man page. > > - add ~/lynx/lynx.cfg to standard files created at account creation time > > > > - it contains 'INCLUDE:/correct/path/to/that/systems/lynx.cfg' followed > > by an 'overrides go here' comment > > > > - set a systemwide LYNX_CFG_PATH environment variable which points to > > the user path first; or compile it directly into the Lynx binary > > actually, the admin might read the install-instructions and compile-in > a suitable value (environment variables are for users) As I said. Anyway, 'might' is the key word. People don't read manuals, it's best to bludgeon them over the head with the needed info right at the point of need. I mean, it's better anyway, in an absolute sense. Was life better when memory DIMMs were all anonymous and you needed a parts catalog to figure out which was a 2MB-ECC vs. an 8MB-parity stick? Or now, when every unit is clearly labeled with its size, speed, manufacturer, and as much bling as they can manage to squeeze on (possibly including a little LCD which plays Doom with itself)? >Bela<
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
On Wed, Feb 09, 2022 at 11:48:06PM -0800, Bela Lubkin wrote: > It's easy to use your own lynx.cfg while still keeping up with system > changes. This is documented near the top of the standard lynx.cfg; but > with an important omission. > > lynx.cfg has an 'include' facility. So all you need to do is write: > > INCLUDE:/etc/lynx-cur/lynx.cfg > STARTFILE:https://abc.def > > in your own file, let's say ~/lynx/lynx.cfg; and conspire for Lynx to > invoke that at startup time. Which you can do with either: > > alias lynx=/usr/bin/lynx -cfg ~/lynx/lynx.cfg > > or: > > export LYNX_CFG=~/lynx/lynx.cfg > > (using your shell's form of alias / function, or environment export...) > > = > > The important omission (at least in 2.9.0dev.7) is that it doesn't > discuss ordering. These have different meanings: > > (1) > > STARTFILE:https://abc.def > INCLUDE:/etc/lynx-cur/lynx.cfg > > (2) > > INCLUDE:/etc/lynx-cur/lynx.cfg > STARTFILE:https://abc.def > > In #1, the system setting will override STARTFILE; you'll only see > abc.def if the system didn't specify STARTFILE. In #2, your setting > always overrides. Either could be what you mean, you just have to know > what it is that you mean to mean... I'd regard that as obvious: lynx processes the configuration information in the order that it's given. The existing wording in lynx.cfg suggests using the include first, and then your own customizations. (patches for suggested improvements appreciated) > = > > Which means, in *most* cases, the user will want something like: > > INCLUDE:/path/to/system/lynx.cfg > STUFF:that the user wants to override > > (Thomas, can you add a few words to clarify include ordering, in default > lynx.cfg?) > > >Bela< > > PS: there's also a LYNX_CFG_PATH environment variable. A system admin > could do something like: in the manual page: LYNX_CFG_PATH If set, this variable overrides the compiled-in search-list of directories used to find the configuration files, e.g., lynx.cfg and lynx.lss. The list is delimited with ":" (or ";" for Windows) like the PATH environment variable. > - add ~/lynx/lynx.cfg to standard files created at account creation time > > - it contains 'INCLUDE:/correct/path/to/that/systems/lynx.cfg' followed > by an 'overrides go here' comment > > - set a systemwide LYNX_CFG_PATH environment variable which points to > the user path first; or compile it directly into the Lynx binary actually, the admin might read the install-instructions and compile-in a suitable value (environment variables are for users) > > Then any user can do this by just editing one pre-existing file. > > OR the system lynx.cfg could have an 'INCLUDE:~/lynx/lynx.cfg' at its > end (and the user better not have the same); except -- if that file > doesn't exist, it errors out. Needs an 'INCLUDE_OPTIONAL:file' > directive... > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
It's easy to use your own lynx.cfg while still keeping up with system changes. This is documented near the top of the standard lynx.cfg; but with an important omission. lynx.cfg has an 'include' facility. So all you need to do is write: INCLUDE:/etc/lynx-cur/lynx.cfg STARTFILE:https://abc.def in your own file, let's say ~/lynx/lynx.cfg; and conspire for Lynx to invoke that at startup time. Which you can do with either: alias lynx=/usr/bin/lynx -cfg ~/lynx/lynx.cfg or: export LYNX_CFG=~/lynx/lynx.cfg (using your shell's form of alias / function, or environment export...) = The important omission (at least in 2.9.0dev.7) is that it doesn't discuss ordering. These have different meanings: (1) STARTFILE:https://abc.def INCLUDE:/etc/lynx-cur/lynx.cfg (2) INCLUDE:/etc/lynx-cur/lynx.cfg STARTFILE:https://abc.def In #1, the system setting will override STARTFILE; you'll only see abc.def if the system didn't specify STARTFILE. In #2, your setting always overrides. Either could be what you mean, you just have to know what it is that you mean to mean... = Which means, in *most* cases, the user will want something like: INCLUDE:/path/to/system/lynx.cfg STUFF:that the user wants to override (Thomas, can you add a few words to clarify include ordering, in default lynx.cfg?) >Bela< PS: there's also a LYNX_CFG_PATH environment variable. A system admin could do something like: - add ~/lynx/lynx.cfg to standard files created at account creation time - it contains 'INCLUDE:/correct/path/to/that/systems/lynx.cfg' followed by an 'overrides go here' comment - set a systemwide LYNX_CFG_PATH environment variable which points to the user path first; or compile it directly into the Lynx binary Then any user can do this by just editing one pre-existing file. OR the system lynx.cfg could have an 'INCLUDE:~/lynx/lynx.cfg' at its end (and the user better not have the same); except -- if that file doesn't exist, it errors out. Needs an 'INCLUDE_OPTIONAL:file' directive...
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Actually Karen, once I alter the setting, I can view the site fine just for the cuttent session, so at least for now its a work around. Chime
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Mercy chime, I am going to remember this thread the next time someone suggests I tamper with the lynx.cfg here. Hope you find a way in, at least there is still the lynx.old door as well. Kare On Wed, 9 Feb 2022, Chime Hart wrote: Well, Karen, I agree with you about possible differences in the files. I ran an exec tcsh which is similar to re-logging in. I could try an unalias. My own machine is still having an issue with that site, even trying to change an option in lynx.cfg. Chime
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
On Wed, Feb 09, 2022 at 07:34:26PM -0500, Karen Lewellen wrote:
> Chime,
> I am talking about the lynx build here.
> As Luke noted the lynx.cfg file is quite large and extensive, meaning your
> personal lynx.cfg file which is not the same as the lynx.cfg file for all
> shellworld users is likely to have differences.
> Additionally, as I understand it, the feature cannot be saved in the
> options menu. No idea where you are making the change, but my personal test
In lynx.cfg:
.h2 PREFERRED_CONTENT_TYPE
# When doing a GET, lynx expects the server to provide a Content-Type, i.e.,
# the MIME name which tells it how to present data. When that is missing
# lynx uses this value.
#PREFERRED_CONTENT_TYPE: text/plain
loads the program variable LYContentType, which appears in the options
menu:
/* Preferred content type: SELECT */
PutLabel(fp0, gettext("Preferred content type"), preferred_content_string);
BeginSelect(fp0, preferred_content_string);
PutOptValues(fp0, LYContentType, content_values);
EndSelect(fp0);
and also is listed in LYrcFile.c:
MAYBE_ENU(RC_PREFERRED_CONTENT_TYPE, LYContentType,
tbl_preferred_content,
MSG_ENABLE_LYNXRC),
which says that the "ENABLE_LYNXRC" feature applies to this:
https://lynx.invisible-island.net/lynx_help/body.html#ENABLE_LYNXRC
though I overlooked adding that to the comment-block in lynx.cfg,
when I added it to the source-code in March 2018:
2018-03-21 (2.8.9dev.17)
* add PREFERRED_CONTENT_TYPE defaulting to text/plain and options-menu to
replace an assumption in HTMIMEConvert that everything is text/html.
Since most servers provide a valid Content-Type for HTML, and are more likely
to omit it for files lacking a known suffix, defaulting to text/plain is a
better choice -TD
This (in your lynx.cfg) should allow that to be saved from the options
menu, into ~/.lynxrc:
ENABLE_LYNXRC:PREFERRED_CONTENT_TYPE
> involves logging into shellworld itself with my own account, and using the
> services here, not an alias. Did you log out entirely from your setup
> before trying again?
>
> Karen
>
>
>
> On Wed, 9 Feb 2022, Chime Hart wrote:
>
> > Well, Karen, I was about to think you were correct. I tried switching an
> > option in my LYNX to html, exited, and went back to that site, no
> > changeThanks
> > Chime
> >
> >
> >
>
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Well, Karen, I agree with you about possible differences in the files. I ran an exec tcsh which is similar to re-logging in. I could try an unalias. My own machine is still having an issue with that site, even trying to change an option in lynx.cfg. Chime
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Chime, I am talking about the lynx build here. As Luke noted the lynx.cfg file is quite large and extensive, meaning your personal lynx.cfg file which is not the same as the lynx.cfg file for all shellworld users is likely to have differences. Additionally, as I understand it, the feature cannot be saved in the options menu. No idea where you are making the change, but my personal test involves logging into shellworld itself with my own account, and using the services here, not an alias. Did you log out entirely from your setup before trying again? Karen On Wed, 9 Feb 2022, Chime Hart wrote: Well, Karen, I was about to think you were correct. I tried switching an option in my LYNX to html, exited, and went back to that site, no changeThanks Chime
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Well, Karen, I was about to think you were correct. I tried switching an option in my LYNX to html, exited, and went back to that site, no changeThanks Chime
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
That is interesting Chime, When I visited the link Luke provided I reached the page just fine. additionally, the option shows correctly in the options menu now too. I wonder if this is due to your personal config not matching the universal one? Karen On Wed, 9 Feb 2022, Chime Hart wrote: Well, Karen-and-Luke, that radio tapes site has not changed for me on Shellworld, I still need to type lynx.old But yes, I have had my own lynx.cfg since I joined Shellword. Certainly glad Karen's sites are working well now. Chime
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
> Well as a positive feather for Luke's efforts with this [...] I've been exchanging a few messages offlist with Luke and I too am quite definitely positively impressed. Luke strikes me as what provider support should be but far too seldom is. /~\ 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
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Well, Karen-and-Luke, that radio tapes site has not changed for me on Shellworld, I still need to type lynx.old But yes, I have had my own lynx.cfg since I joined Shellword. Certainly glad Karen's sites are working well now. Chime
Re: [Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
Well as a positive feather for Luke's efforts with this lynx upgrade one benefit we now have is that the yahoo news site and at least for me Washington post site have active links again. previously I would have to use the control-v feature to changing tracking. Now the articles have active associated numbered links no change necessary. Karen On Wed, 9 Feb 2022, Luke, Shellworld Support wrote: On Wed, 2 Feb 2022, Ian Collier wrote: Extract from lynx.cfg: .h2 PREFERRED_CONTENT_TYPE # When doing a GET, lynx expects the server to provide a Content-Type, i.e., # the MIME name which tells it how to present data. When that is missing # lynx uses this value. #PREFERRED_CONTENT_TYPE: text/plain We did not have this section on Shellworld. It must have arrived in an update to lynx.cfg that we didn't take for reasons of not scratching existing configs. Lynx.cfg is such a huge config file, that I wish there was an efficient way to break it into a lynx.d style arrangement. Anyway, after including an appropriately modified version of this section, and compensating for the below bug, both our old and new versions of lynx can handle the URL in question (https://www.radiotapes.com) from the version of Apache that isn't sending content-type for some reason. Note: I believe there shouldn't be a space between the colon and 'text' in the lynx.cfg setting - at least it didn't work for me with a space but did work without. This means there is a bug either in the parser or in the sample lynx.cfg which comes with Lynx. I can confirm that bug, whichever it is. Luke
[Lynx-dev] Handling sites that don't send content-type (was: lynx word bleeding?)
On Wed, 2 Feb 2022, Ian Collier wrote: > Extract from lynx.cfg: > > .h2 PREFERRED_CONTENT_TYPE > # When doing a GET, lynx expects the server to provide a Content-Type, i.e., > # the MIME name which tells it how to present data. When that is missing > # lynx uses this value. > #PREFERRED_CONTENT_TYPE: text/plain We did not have this section on Shellworld. It must have arrived in an update to lynx.cfg that we didn't take for reasons of not scratching existing configs. Lynx.cfg is such a huge config file, that I wish there was an efficient way to break it into a lynx.d style arrangement. Anyway, after including an appropriately modified version of this section, and compensating for the below bug, both our old and new versions of lynx can handle the URL in question (https://www.radiotapes.com) from the version of Apache that isn't sending content-type for some reason. > Note: I believe there shouldn't be a space between the colon and 'text' > in the lynx.cfg setting - at least it didn't work for me with a space > but did work without. This means there is a bug either in the parser > or in the sample lynx.cfg which comes with Lynx. I can confirm that bug, whichever it is. Luke
