Playing with gopher selectors Sun, 09 Nov 2025 06:24:27 +0100 +-----------------------------------------------------------------+ Perhaps a silly experiment, but that's how things are discovered, right? I'm running the gophernicus gopher server, and I was wondering what effect selectors actually have on files. I'm using the Chawan multiprotocol client, and mailcap for these tests. I'm setting the filetype in gophermap with the command :mpeg=SELECTOR, then letting gophernicus list all files in the directory with *. The URL generated by gophernicus appears as: gopher://spike.nagatha.fr:70/SELECTOR/sandbox/example-video.mpeg The test file is example-video.mpeg, and my mailcap is set to open mpeg files with mpv. +-- RESULTS ------------------------------------------------------+ Selectors, type, effect canonical types 0 (FILE) file opens with mpv 1 ( DIR) binary data fills the screen 2 ( CSO) file opens with mpv 3 ( ERR) binary data fills the screen 4 ( HQX) file opens with mpv 5 ( DOS) file opens with mpv 6 (UUEN) file opens with mpv 7 ( ASK) query form -> binary data in gophermap 8 (TELN) file opens with mpv 9 ( BIN) file opens with mpv + (MIRR) file opens with mpv g ( GIF) nothing happens I ( IMG) file opens with mpv T (TELN) file opens with mpv gopher+ types : (BITM) file opens with mpv ; ( MOV) file opens with mpv < ( SND) file opens with mpv non-canonical types d ( DOC) file opens with mpv h (HTML) binary data fills the screen i (INFO) line is not a link p ( IMG) nothing happens r ( RTF) file opens with mpv s ( SND) file opens with mpv P ( PDF) file opens with mpv X ( XML) file opens with mpv gopher mailing list addition (gopher+ ?) m (MIME) file opens with mime.type handler in mailcap (UNKN) selectors all open the file with mpv +-- CONCLUSION ---------------------------------------------------+ I repeated the test with Lynx, which gave slightly different results. So this means that gopher clients are trying to manage some selectors themselves, before giving up and opening the file and letting mailcap deal with it. And of course, each gopher client is doing it's own thing, sigh. How can we solve this? My first thought is to use an unknown selector, such as '!', or the binary selector '9', so that the file is passed to be filtered by mailcap. This works in Chawan and Lynx, but other clients like gopherus will just propose to download the file. Other clients like gophercle won't even convert some selectors to links. We have a protocol with an RFC plus suggestions that are not always followed by either servers, clients nor gopher files themselves. It's a f*****g mess. I'm starting to understand the Gemini guys, but IMHO they went too far. Gopher just needs to standardize the treatment of these items: internal processing: - folders - gophermaps - forms to relay requests (search, ask) - errors via mailcap: - plain text files (.txt) - other text files (.md, .pdf, .html, m3u, etc.) - binary files (.gif, .jpg, .png, mp3, mpeg, .ods, ,gzip, etc. see the 2500+ extensions in /etc/mime.types) *** this is exactly what the 'm' selector is supposed to do *** url selectors - URL: (html or other protocols as originally proposed) ex. http://, gemini://, spartan://, text://, etc. this would make the following types obsolete as they can be handled as either text, binary, or URL - 2,4,5,6,8,T,:,;,<,d,h,p,r,s,P,X which leaves us with - 0,1,3,7,m,+,i, plus the url selector filetype which can be anything. Gopher clients must provide: - a method of linkifying text files - Seen the inconsistant treatment of file types above, the display of filetype acronyms before the url is worse than useless. - Ideally gopher clients should support multiple protocols, as we don't live in a goldfish bowl. Change my mind at gopher@nagatha.fr https://en.wikipedia.org/wiki/Gopher_(protocol) gopher://spike.nagatha.fr/0/articles/mailcap.txt ␌