Use ASV #2
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
See bonsai/harakit#19
fortune(1) should keep using the format it always has. There's no reason to change it, we have files written for it, and it keeps interoperability with other implementations.
We have a character set specifically catered to use in this context. We
have the luxury of not having to worry about breaking compatibility
because we are a cohesive system and there is a native tabular format
that is specifically designed to circumvent weirdness like using a
percent sign as a tabular character.
As a note, 9front’s fortune(1) implementation seems to work differently
to how Unix fortune(1) does. It has no percent characters as far as I
can see.
https://git.9front.org/plan9front/plan9front/c813cfa1981b3566a34b4d614fa5ec2aaee53819/sys/man/1/fortune/f.html
I was correct.
9front's format is the same as the historical implementation; if I recall correctly the first implementation used a 500B buffer and looped fgets(3) randomly. The percent delimiter might have been a BSD invention. It's nice to be able to see the sources for quotes without bad line-wrapping.
We don't exist in a vacuum. There already exists two fortune file formats. I don't want to invent a third.
ed(1) used
\n.\nto cease input.\n%\nfits with that pattern. It's not like%as a single fortune is useful.While it may be true that two
fortune(5)formats exist (actually three, the cat-v fortunes are double-newline separated and 9front/plan 9’s are single-newline), we have our own tabular parsing library that will be part of the Mu standard library (whichkoan(1)will eventually be written in) and which will be the native format for the system. Having one weird format for a toy is kind of counter to the entire spirit of the project—holding onto legacy cruft for a minor advantage, with a simple conversion sitting in between.If we use ASV, we don’t need to implement the search functionality that a typical
fortune(1)implementation may support. Instead, since we have a one-byte delimiter that doesn’t depend on any whitespace, it becomes trivial to search for fortunes by keyword with something like agrep(1)-analogue andfit(1), because we don’t have to worry about ourgrep(1)-analogue being a line-based search; it can be an ASV-delimiter-based search. This reduces the size of the utility (fortune(1)in OpenBSD is 1200 lines).You’re right that we don’t exist in a vacuum—that’s why we’re bothering to even make a toy utility like this. But it would be a disservice to our prospective users to cling to the historic format of any
fortune(1)utility at the expense of coherence; what would you have me say to a user who looks at the file format manual for ourfortune(5)analogue and, expecting coherence with the system-native tabular format, is thrown off and confused that we have for some reason, here, and only here, decided to stick with the legacy cruft?How do we decide which
fortune(5)format to go with out of the three? Why?if i saw a couple goobers claiming to have this new paradigm of computing with this wacky new "coherent" operating system and i looked inside and saw inexplicable copy-pasted unix cruft, it'd be real hard for me to take the rest of it seriously. let's leave the dead gods alone with their cultists, we have brighter futures to create.