<div dir="ltr"><div>The URL is just part of a plain text paragraph so to the extent that a system makes an active link out of it <br></div><div>is just down to the heuristics of that system.</div><div><br></div><div>reading your email in gmail I see</div><div><br></div><div><img src="cid:ii_lv3tv2580" alt="image.png" width="488" height="68"><br></div><div>and gmail has inferred a link not including the . , and the link works.</div><div><br></div><div>I assume you are using a system that has inferred a URL ending in the . (that doesn't work)</div><div><br></div><div>As such I'd say it isn't really a problem that needs to be solved although perhaps the text could</div><div>be modified to give systems inferring links a bit of help such as using the <> convention so</div><div><br></div><div>For more, see the output of install-tl --help, especially th<br> -repository option. Online via <<a href="https://tug.org/texlive/doc">https://tug.org/texlive/doc</a>>.)</div><div><br></div>David<div>(Just an interested observer: I have no control over this code)<font face="monospace"><br></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Apr 2024 at 13:55, Carlos <<a href="mailto:linguafalsa@gmail.com">linguafalsa@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 17, 2024 at 09:19:11PM +0900, Norbert Preining wrote:<br>
> Hi<br>
> <br>
> I'm an not sure what you are talking about, but it seems the mirror selected by the multiplexer is out of date or broken.<br>
> <br>
> You can select any mirror manually using the<br>
> -repository ...<br>
> argument.<br>
> <br>
> Details here <a href="https://tug.org/texlive/doc/install-tl.html" rel="noreferrer" target="_blank">https://tug.org/texlive/doc/install-tl.html</a><br>
<br>
Hey Norbert. Right. But when you follow the link as normal people would do through any terminal such as foot terminal or alacritty, it returns the infamous url not found . I'm not sure xterm would allow it but whenever you follow the link from a terminal <br>
<br>
the requested > > The requested URL is not found on this server. <br>
<br>
Better yet, you can try this out and go to <br>
<br>
<a href="https://tug.org/svn/texlive/trunk/Master/install-tl?revision=70922&view=markup" rel="noreferrer" target="_blank">https://tug.org/svn/texlive/trunk/Master/install-tl?revision=70922&view=markup</a><br>
<br>
and see for yourself that when you click on the link from the online option<br>
<br>
$0: The TeX Live versions of the local installation<br>
and the repository being accessed are not compatible:<br>
local: $TeXLive::TLConfig::ReleaseYear<br>
repository: $texlive_release<br>
Perhaps you need to use a different CTAN mirror?<br>
(For more, see the output of install-tl --help, especially the<br>
-repository option. Online via <a href="https://tug.org/texlive/doc" rel="noreferrer" target="_blank">https://tug.org/texlive/doc</a>.)<br>
<br>
it's supposed to return a URL not found on the server and if it doesn't both your systems are duped to follow the link . <br>
<br>
After all both of you Karl and you are without exception and have been pretty lucky in this regards that all these modern browsers understand better the forward slash <br>
<br>
To include a dot is not common regardless of whatever the typographical gold standard happens to be <br>
<br>
See more about it in this question and answers here<br>
<br>
<a href="https://webmasters.stackexchange.com/questions/73934/how-can-urls-have-a-dot-at-the-end-e-g-www-bla-de" rel="noreferrer" target="_blank">https://webmasters.stackexchange.com/questions/73934/how-can-urls-have-a-dot-at-the-end-e-g-www-bla-de</a><br>
<br>
<br>
and Look <br>
<br>
<a href="https://www.rfc-editor.org/rfc/rfc5322" rel="noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc5322</a><br>
<br>
Several productions in structured header field bodies are simply<br>
strings of certain basic characters. Such productions are called<br>
atoms.<br>
<br>
Some of the structured header field bodies also allow the period<br>
character (".", ASCII value 46) within runs of atext. An additional<br>
"dot-atom" token is defined for those purposes.<br>
<br>
Note: The "specials" token does not appear anywhere else in this<br>
specification. It is simply the visible (i.e., non-control, non-<br>
white space) characters that do not appear in atext. It is<br>
provided only because it is useful for implementers who use tools<br>
that lexically analyze messages. Each of the characters in<br>
specials can be used to indicate a tokenization point in lexical<br>
analysis.<br>
<br>
<br>
Resnick Standards Track [Page 12]<br>
<br>
RFC 5322 Internet Message Format October 2008<br>
<br>
<br>
atext = ALPHA / DIGIT / ; Printable US-ASCII<br>
"!" / "#" / ; characters not including<br>
"$" / "%" / ; specials. Used for atoms.<br>
"&" / "'" /<br>
"*" / "+" /<br>
"-" / "/" /<br>
"=" / "?" /<br>
"^" / "_" /<br>
"`" / "{" /<br>
"|" / "}" /<br>
"~"<br>
<br>
atom = [CFWS] 1*atext [CFWS]<br>
<br>
dot-atom-text = 1*atext *("." 1*atext)<br>
<br>
dot-atom = [CFWS] dot-atom-text [CFWS]<br>
<br>
specials = "(" / ")" / ; Special characters that do<br>
"<" / ">" / ; not appear in atext<br>
"[" / "]" /<br>
":" / ";" /<br>
"@" / "\" /<br>
"," / "." /<br>
DQUOTE<br>
<br>
Both atom and dot-atom are interpreted as a single unit, comprising<br>
the string of characters that make it up. Semantically, the optional<br>
comments and FWS surrounding the rest of the characters are not part<br>
of the atom; the atom is only the run of atext characters in an atom,<br>
or the atext and "." characters in a dot-atom.<br>
<br>
<br>
<br>
<br>
<br>
<br>
> <br>
> <br>
> -- <br>
> PREINING Norbert <a href="https://www.preining.info" rel="noreferrer" target="_blank">https://www.preining.info</a><br>
> arXiv / Cornell University + IFMGA ProGuide + TeX Live<br>
> GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13<br>
> <br>
> Apr 17, 2024 21:13:13 Carlos <<a href="mailto:linguafalsa@gmail.com" target="_blank">linguafalsa@gmail.com</a>>:<br>
> <br>
> > Hello Karl:<br>
> > <br>
> > I noticed the last message to the list didn't go through at tlbuild so here then<br>
> > <br>
> > The changes for the trailing period had to be undone. And I'm fine with it. if that's what you want, so be it.<br>
> > <br>
> > But my question is what browser am I supposed to use to follow the link in and thus avoid the infamous Not Found<br>
> > The requested URL was not found on this server.<br>
> > <br>
> > in all current browsers known to mankind<br>
> > <br>
> > The TeX Live versions of the local installation<br>
> > and the repository being accessed are not compatible:<br>
> > local: $TeXLive::TLConfig::ReleaseYear<br>
> > repository: $texlive_release<br>
> > Perhaps you need to use a different CTAN mirror?<br>
> > (For more, see the output of install-tl --help, especially the<br>
> > -repository option. Online via <a href="https://tug.org/texlive/doc" rel="noreferrer" target="_blank">https://tug.org/texlive/doc</a>.)<br>
> > <br>
> > Is it a text based browser like lynx or elinks or anything else that would allow me to read the page ?<br>
> > <br>
> > What is it am I supposed to do when I follow the link from the terminal such as foot terminal or alacritty? Append a dot/period at the end so I can avoid the URL not found <br>
> > <br>
> > If the answer is a no to all these questions, could you add to the documentation something in the lines to advise the user to append a period/dot at the end of the URL? Or copy the link just before but not either on or after the dot/period in question?<br>
> > <br>
> > But I mean.My gosh. Why does it to have so complicated?<br>
> > <br>
> > <br>
> > <br>
> > <br>
> <br>
> <br>
<br>
-- <br>
<br>
</blockquote></div>