BINHEX(1)

💖 BINHEX(1) 💖

okay bestie, welcome to the General Commands Manual for binhex — yes, that binhex, the one and only, and she is serving classic Unix realness today ✨

---

🌸 NAME 🌸

binhex — hexifies a series of files 🎀

---

🦋 SYNOPSIS 🦋

binhex [ - options ] [ files ]

---

✨ DESCRIPTION ✨

so, like, binhex takes the files you specify and hexifies them into BinHex 4.0 format, right onto standard output, subject to whatever options you gave it. periodt 💅

and listen — if files also names some directories, she follows them recursively, and every single file she finds gets hexified. no file left behind, no cap.

but if you don't pass a files parameter at all? then binhex reads a MacBinary stream from standard input and hexifies the files she finds in there. heads up though: folder information is lost 😭 the folders simply do not survive the vibe check.

---

👑 OPTIONS 👑

now here's the tea. with zero options present, binhex just takes the files you named and silently hexifies them to BinHex 4.0 format, writing the result to standard output. directories named in files get followed recursively, and all files found will be hexified. files are assumed to be in MacBinary format.

BUT. plot twist 🫢 if the filename ends with .info, the file is assumed to be the info fork of a MacIntosh file split amongst more than one file. in that case, the files with .data and .rsrc extensions are also read (if present). also, if the info fork is mentioned in the parameter list, the names of data and resource forks can also be mentioned, but those will be ignored — and that's on purpose, bestie, it's to allow wild-card expansion by the shell 🐚

furthermore, if some form of AppleShare is supported by the installed program, and if the current directory, or one of the directories found during recursive processing, is a directory in the format of the supported version of AppleShare, those files will be handled according to the properties of AppleShare. slay 🍓

---

• -r — no intelligent file-processing is performed; all files named are assumed to be plain resource files, and are hexified as if they were MacIntosh resource files with creator "RSED" and type "RSRC", unless another creator and/or type are specified.
• -d — no intelligent file-processing is performed; all files named are assumed to be plain data files, and are hexified as if they were MacIntosh data files with creator "MACA" and type "TEXT", unless another creator and/or type are specified.
• -u — as -d, but the codes for CR and LF are interchanged. 🔄
• -U — is a synonym for -u. (twinning fr fr 👯)
• -c creator — defines the creator name to be used if one of the previous options is specified.
• -t type — defines the type name to be used if one of the previous options is specified.
• -R — do not use run-length encoding during the conversion. this option may speed up the encoding a bit, but it is merely a historical artifact. 💀 like she's literally just here for the lore.
• -l — list every file and directory processed. 📋
• -i — do not output files, give information only (implies -l.) 🙈
• -q — ask the user for every file/directory whether it should be visited (implies -l.) 🫶 very demure, very mindful, asking permission first.
• -V — gives the patchlevel of the program, and other information. other options are ignored and the program quits immediately.
• -H — give short information about the options. other options are ignored and the program quits immediately.

---

💀 BUGS 💀

as this is a beta release, there may still be some problems. not me exposing her flaws on main 😭 she's growing, okay, be nice.

---

🌈 SEE ALSO 🌈

macutil(1)

---

💜 AUTHOR 💜

Dik T. Winter, CWI, Amsterdam, The Netherlands (dik@cwi.nl) — an absolute icon, honestly, we stan 👑

---

real talk bestie: everything above is exactly as the page says it. i'm just the messenger with better nails 💅

---

and that's the whole page, babes 🎀 shoutout to the 3rd Berkeley Distribution, dated October 22, 1992 — vintage, iconic, still relevant. mwah 💖✨