The version of Fossil currently running this forum...

FWIW, my server is also currently running that branch. So far, so good.

Viva la revolución!

✊

Viva la revolución!

As suggested off-list by Richard moments ago:

We'd love to see some designs for logos and/or slogans for the "No CRLF" movement¹. The formal name isn't, AFAIK, set in stone, but the logos/slogans should revolve around the idea of proudly being devoid of carriage-return-line-feed combinations².

As an example, a stylized version of "100% CRLF-Free*" with the * referring to small text at the bottom saying "Ask me for details!"

Bonus points if the logo can be expressed in pikchr!

1. ^{^} "And that's what it is: the Alice's Restaurant Anti-CRLF movement." (With apologies to Arlo Guthrie.)
2. ^{^} Note that carriage-return by itself is often used on Unix systems when generating progress-style output on the console. The crusade here is against CRNL as an end-of-line delimiter.

C: circle "CRLF" big big bold thick thick fit

A bit of trivia for future code archeologists: we added the new "open in /pikchrshow" links directly in response to this thread's series of pikchrs.

C: circle "CRLF" big big bold thick thick fit
sin45 = sin(3.141592653/4)
line thick thick from (C.x+sin45*C.radius*0.5,C.y+sin45*C.radius*0.5) \
                 to (C.x+sin45*C.radius,C.y+sin45*C.radius)
line thick thick from (C.x-sin45*C.radius*0.5,C.y-sin45*C.radius*0.5) \
                 to (C.x-sin45*C.radius,C.y-sin45*C.radius)
text "CRLF-free" "Software" fit with .n at C.s

That's pretty neat!
One observation I have is that if you open the link in a new tab, the pikchr code isn't present in the pikchrshow tool.
There may not be much that can be done about it, so no sweat, just an observation.

Otherwise, it's a great addition! Thank you!

One observation I have is that if you open the link in a new tab, the pikchr code isn't present in the pikchrshow tool.

Apologies, Sean, i missed this report. If you just left-click on the link it will open in a new tab automatically. Indeed, if you middle-click (or otherwise explicitly "open in new tab") then the event handler does not get to set the pikchr code into the session before the tab is opened. That's definitely a bug but i'm not sure how to work around that :/.

Edit: several experiments were made to handle the "auxclick" (middle-button) and to update the session on the mouse-down, regardless of which mouse button is used, but neither have the desired effect of making the middle button behave like the left button, for reasons beyond my current understanding :/.

Therefore, let everyone who seeks peace and simplicity and the flourishing of humanity

That's me and I support this logo and the movement.

One gets the impression you are rather enjoying yourself here... 😆

Hear hear.

Worth getting this some more publicity. A worthy use of some of your institutional credit.

It would be neat if the linked manifesto covered what exactly is meant by the “considered harmful” part. I’d prefer an all-NL universe as well but I’m not clear on how the extra character is harming anyone.

It would be neat if the linked manifesto covered what exactly is meant by the “considered harmful” part.

It's a reference to a common naming convention used in articles which are critical of a topic. AFAIK (but very possibly incorrect) the original such instance was Recursive Make Considered Harmful. If you'll search, e.g., HackerNews for "considered harmful" you'll find references to lots of critiques which follow that convention.

Edit: you'll find another instance of that within this project at Rebase Considered Harmful, which is a critique of git's rebase functionality.

Nope, it was Dijkstra.

Nope, it was Dijkstra.

Indeed ("Go To Statement Considered Harmful"), and Wikipedia even has a page on this naming convention: https://en.wikipedia.org/wiki/Considered_harmful

Communications of the ACM, "Summer of" 1968.

I’m familiar with the lore! I believe the format originally came from Dijkstra’s “GOTO considered harmful” paper.

Still, I think the article should live up to the headline. The “Rebase Considered Harmful” article definitely does that, this one not so much! The CR piece sounds like a “ha ha only serious” sentiment (after all, it’s backed by actual changes to code running in prod) so take this nitpick in a similar spirit :)

I retitled the document. I'm open to further improvements. Make your suggestions.

and various protocols (HTTP, SMTP, CSV)

**CVS

-bch

CSV == RFC-4180

Works for me with:

• Fossil CGI behind Apache on FreeBSD¹
• fossil ui on localhost with and without SSL/TLS on Windows
• curl and wget to fossil-scm.org and sqlite.org URLs
• my custom Fossil and SQLite Forum dashboards (PHP/curl)
• my custom Fossil Forum scraper (with scripted login to bypass the anti-bot defenses)
• my custom downloader script²

To check if a random server really replies with NL-only headers:

• fossil pull --once "ANY_URL" --httptrace -R "SOME_DUMMY_REPOSITORY"
• Examine the line endings of the http-[reply|request]-N.txt files in the current directory.

As a someone grown up with Windows (30+ years ago), CRLF feels natural to me, and NL-only feels odd... ;-) Decent text editors have handled this automatically for decades, and even the pain caused by occasional forced use of Windows Notepad failing with NL-only is gone! But I know that the topic is important to you, I remember a statement of yours (to which I can't find a reference right now) that you'd consider someone changing the line ending mode of a file in the Fossil repository a more serious insult.

I don't care too much about carrying forward old design decisions, because I think they mostly don't matter any more with nowadays ridiculous CPU powers and RAM capacities. But of course, writing code to fiddle with CRLF instead on LN-only may be more error-prone.

From this perspective, should UTF-16 be considered harmful is a similar topic. Windows has adopted Unicode in the UTF-16 (well, UCS-2) era before UTF-8 was invented (or, at least before it was known to the Windows devs), and some believe that UTF-8 would have been the better choice. But I think it really doesn't matter any more with regard to CPU and RAM usage, and programming with UTF-16 is easier than programming with UTF-8. (UTF-8 has illegal lead bytes, overlong forms, extra trail bytes, intermittent illegal code points, i.e. the UTF-16 surrogates. UTF-16 just has scalar or surrogate code points, yet the latter may be unpaired, I must admit.) And in the end, every single code point to be read by a human has to be converted to UTF-32 to find a corresponding glyph in some font resource for display in web browsers, text editors, and terminals. Samely same.

1. ^{^} Apache translates NL-only to CRLF in reply headers.
2. ^{^} Javascript run by the Windows Script Host, using the WinHttp.WinHttpRequest.5.1 interface; the script even looks for CRLF when parsing HTTP headers, which seem to be translated from NL-only to CRLF, internally!

Javascript run by the Windows Script Host, using the WinHttp.WinHttpRequest.5.1 interface; the script even looks for CRLF when parsing HTTP headers, which seem to be translated

We had an off-list report that the Chocolatey tool, based on PowerShell, cannot handle the CR-free headers. Can you confirm or deny that?

(Edit: that post finally made it here to this thread - just below this response.)

programming with UTF-16 is easier than programming with UTF-8

UCS-4, then. Or 3-byte encoding. UTF-16 still has surrogate pairs and variable length, so really is not much easier than UTF-8.

There is no way to access from PowerShell.

> Invoke-WebRequest https://www.fossil-scm.org/
Invoke-WebRequest : The server committed a protocol violation. Section=ResponseStatusLine
At line:1 char:1
+ Invoke-WebRequest https://www.fossil-scm.org/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

So that it is unable to install fossil, etc by Chocolatey on Windows.

> choco install -y fossil
Chocolatey v2.3.0
Installing the following packages:
fossil
By installing, you accept licenses for the packages.
Downloading package from source 'https://community.chocolatey.org/api/v2/'
Progress: Downloading fossil 2.24.0... 100%
fossil v2.24.0 [Approved]
fossil package files install completed. Performing other installation steps.
Attempt to get headers for https://www.fossil-scm.org/home/uv/fossil-w64-2.24.zip failed.
  The remote file either doesn't exist, is unauthorized, or is forbidden for url 'https://www.fossil-scm.org/home/uv/fossil-w64-2.24.zip'. Exception calling "GetResponse" with "0" argument(s): "The server committed a protocol violation. Section=ResponseStatusLine"
Downloading fossil 64 bit
  from 'https://www.fossil-scm.org/home/uv/fossil-w64-2.24.zip'
ERROR: The remote file either doesn't exist, is unauthorized, or is forbidden for url 'https://www.fossil-scm.org/home/uv/fossil-w64-2.24.zip'. Exception calling "GetResponse" with "0" argument(s): "The server committed a protocol violation. Section=ResponseStatusLine"
This package is likely not broken for licensed users - see https://docs.chocolatey.org/en-us/features/private-cdn.
The install of fossil was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\fossil\tools\chocolateyInstall.ps1'.
 See log for details.
Chocolatey installed 0/1 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Failures
 - fossil (exited 404) - Error while running 'C:\ProgramData\chocolatey\lib\fossil\tools\chocolateyInstall.ps1'.
 See log for details.

There is no way to access from PowerShell.

FWIW, my initial response to "there is no way to access from PowerShell" was "so what? The UI isn't meant to be scriptable/crawlable," but fetching a download from /uv is certainly a valid use of a script.

Not involved in zig or the hacker news thread, but there was a report of zig's http client breaking here:

https://news.ycombinator.com/item?id=41832519

which points to:

https://github.com/ziglang/zig/issues/21674

How about I start writing some "changing deeply rooted stuff below people's feet considered harmful" article ^_^

Peace is achieved by proposing some new alternative and then make people migrate to it, not by instantly changing inner mechanics (DNA or elections anyone) of the environment you're in (in America they say "cancel culture" I hear), thus disrupting flows and killing stuff/people.

Really sad to see that even renowned data scientists (?), or SCM makers (branches anyone?) do not know that.

not by instantly changing inner mechanics

To be fair, we initially had no examples of software which did not follow HTTP RFC's suggestion that plain LF be treated as acceptable and could not imagine why anyone would forego that recommendation. We now know better.

It is certain that servers cannot remove CRs until most clients have been adapted to ignore them.

The action plan needs to be returned from the client to the server.

Why not, install a copy of a Fossil to demonstrate CR-less operation and encourage people to test their library, application with this site?

In addition to that publish RFCs to have their clients ignore CRs.

Why not, install a copy of a Fossil to demonstrate CR-less operation and encourage people to test their library, application with this site?

That was precisely what happened. All of the sites hosted under the umbrella of Hwaci (Richard's company), as well as my own, were using CR-free builds from the start of this change until the past half-day. It all worked just fine within our various tools and we received zero complaints from browser users that the forums were misbehaving.

Unfortunately, though, the fall-out across the greater internet was much, much higher than anticipated.

What are the repercussions? There's only one ticket for Zig and Chocolatey/Powershell.

What are the repercussions? There's only one ticket for Zig and Chocolatey/Powershell.

The comment thread in https://news.ycombinator.com/item?id=41830717¹ is rife with both uproar and examples of sites and tools which behave poorly when given only LFs in HTTP headers. Examples aside, when a large portion of the developer community is adamantly against a change, it's hardly worth the effort of ice-skating up that hill.

Edit: Chocolatey uses the PowerShell API for networking connections, so it's not a simple a case of "get it fixed upstream." Any such change to PowerShell would take many years to propagate.

Edit: it also broke Fossil instances served via Apache. Richard added a fossil-side workaround for that one, though.

1. ^{^} This one is a different article than Kyle posted, and the uproar is focused in this one.

Ok, that's clearer. There are several versions of Powershell. Without the powershell version it's not conclusive. Microsoft is already trying to kill VBScript by 2027...

Microsoft is already trying to kill VBScript by 2027...

I say this as a heavy VB/VBScript user back in the 90s: Good

I say this as a heavy VB/VBScript user back in the 90s: Good

I programmed in VBScript and T-SQL exclusively for 5 years the ERP and websites of a publishing house. VBScript is excellent. If it had been maintained and updated, I would never have switched to PHP for anything.

Aside: I am a heavy VBScript user too. Is there some conversion tool to get my code to a new language?

PHP is pretty close to VBScript. At one point I considered writing a VBScript to PHP translator because we had three million lines of VBScript. It turns out I changed jobs which cleared up the problem.

For my current employer, the volume of VBScript is so low that a manual conversion is enough. And I don't know of any translator for this language.

Maybe try this tool: https://design215.com/toolbox/asp_translator.php

See the new, revised Manifesto Lite.

Let's open a new issue that, according to Djikstra, is a very bad thing: One True Brace or OTB! The use of that format prevents the eye from connecting up the start and end of braces in code. Let's start a new campaign to get rid of OTB! :) :) :)

Laughs in Pascal and Python

HTTP/1.1 has updated RFC: RFC9112.

There're also HTTP/2 and HTTP/3 now.

Personally, I've mostly ignored those new HTTP incarnations, but having a quick look at e.g. section 3.4 of the HTTP/2 spec, I see that CRLF are buried there quite deeply:

The client connection preface starts with a sequence of 24 octets, which in hex notation is:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

That is, the connection preface starts with the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n".

Unless you are a superset of the environment or are able to enumerate all the components or have enough power to breakthrough everything then you have to assume the worst case.

And what the harmful part of CR is? It looks more harmful in call to violate standards and break compatibility. It's OK to propose "let's stop integrating this thing into new protocols and software", but convincing to do "even ig technically incorrect" is... irresponsible, at best.

And what the harmful part of CR is?

1. Wasted bytes

2. Extra complication for parser to deal with.

3. Countless hours of developer time wasted trying to debug and fix line-ending problems.

4. Exploits and bugs resulting from unfixed line-ending problems.

5. Machines around the world wasting countless kilowatt-hours of power dealing with a circa 1950s anachronism.

Allow me to add to this list a problem I keep having to fix and re-fix around the office, downstream of someone using Visual Studio or some other such Windows editor that can inject carriage returns into existing files. Write a script starting with #!/bin/sh, but save with CRLF line endings. Mark it executable and try to run it. Does it run? No, because the carriage return gets interpreted as part of the interpreter filename.