@me

In terms of chronology, yes. ;)

In terms of which is more of a general thing, I think many encodings could be considered #base64, but only one particular implementation of base64 could be interpreted as #uuencode. ;)

Long live the sharutils! XD

@jdll : Cette vidéo (choisie au hasard) https://videos-libr.es/w/43oyy2QSH8KiR2TzKNxg14 nous ne savons pas bien si elle va cause de #base64 ou de #uuencode.
JdLL 2026 - Direct - Conf 7 - D2.128

PeerTube
My overnight activity on New Year's Eve was to rewrite the #uuencode utility that I lost in a battery-exhaustion incident. The old version was in #Forth, the new version in #LuaLang. Including interpreter size, the Lua version is 100x larger and 100x slower. I was not intending to provide a case study upholding Jeff Fox's writings about Forth efficiency, but there you go.
The next #Forth program I write on the HP #200LX will be #uuencode / #uudecode so I can transfer binary files to/from hosts that don't support #zmodem. #HP200LX

Does anyone know of a multi-file streaming archiving tool that can accept input from pipes, FIFOs, or commands? #tar can do what I want for output with -O, but not on input, because each file's header contains a size, which of course wouldn't be known for streaming input. Must be able to separate files back out again on the other end.

The closest I've come is #uuencode, which can concatenate output and #uudecode will identify the individual components - but of course it has a space penalty.