Wow, keep up the great work! I made compression work on linux and added a github action to build for both mac/linux https://github.com/thecloudexpanse/sit/pull/3
sit - Create StuffIt archives on Unix systems
- Thread starter thecloud
- Start date
Thanks! Appreciate your contributions. I haven't been testing my changes on Linux to this point, so the github action will certainly help.
EDIT: looks like the action is running successfully! https://github.com/thecloudexpanse/sit/actions
Last edited:
@thecloud I have some similar solutions for shortcuts on AppleScript, so I adapted them quickly enough.
AppleScript:
tell application "Finder"
--Creating an array for selected files
set SelectedItems to {}
-- Create an array for the POSIX list of paths
set POSIXList to {}
-- We transfer the paths of all selected files and directories to the array
set SelectedItems to selection as alias list
-- We go through each chosen path
repeat with SelectedItem in SelectedItems
-- We take the path in quotation marks and convert it to POSIX format and add a space
set end of POSIXList to (quoted form of POSIX path of SelectedItem) & " "
end repeat
-- Determine the root by the first selected file or directory
set RootFolder to POSIX path of ((container of SelectedItem) as alias) as text
-- Set the name of the archive
set ArchName to quoted form of (RootFolder & "Archive.sit")
-- SIT It!
do shell script "/usr/local/bin/sit -o" & space & ArchName & space & POSIXList
end tellAttachments
Thanks! I had noticed that my quick-and-dirty script was only handling one selection, and really needed to iterate over the list as you have done.
There was some debate here about the need to encode Stuffit 1.5.1 *.sit files (for uploading to Macintosh Garden, etc.) using BinHex or MacBinary. The thinking was initially that the older v1.5.1 lacked Resource Forks, but then the dialog got kind of convoluted and nothing specific was mentioned about why older SIT files may get corrupted when uploaded. Thoughts?
There is nothing stored in the resource fork of a StuffIt 1.5.1 file. They would not have a resource fork if they were created by the StuffIt 1.5.1 program. I proved this to myself just now by creating a new archive in StuffIt 1.5.1, adding some files to it, saving, and quitting StuffIt. Then I tried opening it with ResEdit and got the dialog "This file does not have a resource fork. Do you want to add one?"
I certainly understand and support this general idea: if a file *can* have a resource fork, then you want to archive it in a data-only container format that won't lose anything. Certainly that's true for, say, Disk Copy 4.2 or DART images which store checksum info in the resource fork (the former in a 'dCpy' resource, the latter in 'CKSM' resources.)
But StuffIt 1.5.1 archives only use the data fork, not the resource fork. No resource information can get lost by copying that .sit container to a different OS. No data can get lost either, as long as you're using binary transfers. (Back in the day, files would be transferred via text-only newsgroups or FTP'd in TEXT mode, and that's what the BinHex .hqx format solved.) Note that .bin files are binary files, and also would need to be transferred in binary mode.
I read the entire thread that you pointed out, and I found it concerning that one user claims their .sit files get corrupted while .bin files do not, yet they admit they do not understand the issue and just scream that everyone should use a .bin wrapper because it's somehow safer and they can't explain why.
What might explain their scenario: they encountered a StuffIt file created by a *later* version of StuffIt that *did* have essential information in the resource fork of the .sit file, and that resource fork was lost. Such a file *would* need to be wrapped. (Another explanation offered in that long thread: old web browsers might not have treated the upload as a binary upload unless it had the .bin extension.) Therefore, handwaving and screaming that all container files must always be bin-encoded for their peace of mind.
The differences between the file formats created by different versions of StuffIt are confusing, and without getting all the versions together and creating archives from each one, I am not exactly sure if/whether the line of "no resource fork, doesn't have or need one" was actually crossed.
But I do know this: both StuffIt 1.5.1 and the `sit` program only create StuffIt 1.5.1 files. Those .sit files do not have a resource fork, in exactly the same way that .bin files do not have a resource fork, and as such, they really don't need to be double-wrapped.
Last edited:
One possible advantage of double-wrapping with MacBinary is that it allows the type and creator of the StuffIt file itself [SIT!/SIT!] to be set when decoded. It's a bit superfluous, as StuffIt Expander is smart enough to read the header of the file and identify it as a 1.5.1-format archive. When transferring any file to Mini vMac via its ImportFl helper app, the type and creator of the imported file is always set to [BINA/SITx] so it will open in StuffIt Expander when double-clicked. However, downloading .sit files from a generic server won't set their type and creator like Mini vMac does, and people may not remember that holding the option key down allows any type of file to be opened by StuffIt Expander.
Do folks here think it would be useful to add MacBinary-encoding functionality to the
Do folks here think it would be useful to add MacBinary-encoding functionality to the
sit tool? i.e. if you specify a -b option, the output is encoded as .sit.bin instead of just .sit?
Giving people power and options is always nice, but after reading your recent replies, would that feature only confuse people into thinking they somehow need that encoding? Because you made it pretty clear that no encoding is necessary for SIT files.
Giving people power and options is always nice, but after reading your recent replies, would that “encoding” feature only confuse users into thinking they somehow need that encoding? Because you made it pretty clear that no encoding is necessary for SIT files.
I agree with what @thecloud said. I've seen a lot of sit files and none have had anything in the resource fork.
bin/hqx was a way to keep the type/creator of sit files so when you downloaded them (via Fetch/Netscape/Explorer/NNTP) they would (normally) automatically decode as the file was transferred, so to the end user they'd just end up with a .sit file with a type/creator set event though it went over the internet where there is no concept of a type/creator/resource fork. So the benefit of bin'ing would be if you were on a vintage computer and downloading with a client that auto decoded, it would show up 'nicely' on your desktop - or else you'll just end up taking 2x the amount of time to unbin then unsit.
But really in 2025 doesn't matter. As long as the file is archived.
The only exception I know for images/compression is disk copy 6 NDIF format disk images - if you loose the resource fork you'll not be able to recreate the file. (But if it was bin/hqx/sit'd you can use https://github.com/mhjacobson/ndif2raw to convert it to a raw image (even supports apple double
)
bin/hqx was a way to keep the type/creator of sit files so when you downloaded them (via Fetch/Netscape/Explorer/NNTP) they would (normally) automatically decode as the file was transferred, so to the end user they'd just end up with a .sit file with a type/creator set event though it went over the internet where there is no concept of a type/creator/resource fork. So the benefit of bin'ing would be if you were on a vintage computer and downloading with a client that auto decoded, it would show up 'nicely' on your desktop - or else you'll just end up taking 2x the amount of time to unbin then unsit.
But really in 2025 doesn't matter. As long as the file is archived.
The only exception I know for images/compression is disk copy 6 NDIF format disk images - if you loose the resource fork you'll not be able to recreate the file. (But if it was bin/hqx/sit'd you can use https://github.com/mhjacobson/ndif2raw to convert it to a raw image (even supports apple double
)@JDW And the attack of cloned messages? 
@eric I didn't know about such a utility, thank you, I'll try it.
My passion for vintage machines began not so long ago, and at the very beginning of the journey in the garden or repository I read that you need to use only BIN so that metadata does not disappear.
Since then, I have created a small archive of applications that I packed and encoded on Mac OS 7.6.1 using StuffIt Deluxe v5.5.1.
But I agree, when I transfer the sit archive to my machines, it opens with a double click and I don't need to use Fix-a-Fork to fix it.
Probably @thecloud is right, additional manipulations are not needed for proper operation. Only if it's a habit, like mine.
@eric I didn't know about such a utility, thank you, I'll try it.
My passion for vintage machines began not so long ago, and at the very beginning of the journey in the garden or repository I read that you need to use only BIN so that metadata does not disappear.
Since then, I have created a small archive of applications that I packed and encoded on Mac OS 7.6.1 using StuffIt Deluxe v5.5.1.
But I agree, when I transfer the sit archive to my machines, it opens with a double click and I don't need to use Fix-a-Fork to fix it.
Probably @thecloud is right, additional manipulations are not needed for proper operation. Only if it's a habit, like mine.
If you are talking about why I linked to that discussion in the other forum, the answer is because if we don’t say anything here, I think some people might Google that other forum, and be a bit confused about whether they need to encode or not. But as we discussed here, it seems to be pretty clear that there is no need to encode SIT files.@JDW And the attack of cloned messages?
I think that "cloned messages" is referring to your messages #31 and #32 in this thread, which looks like a minor edit that got saved as a whole new message. There were at least 3 copies of that message yesterday but one is gone today.
And I tend to agree with your sentiment: rather than adding more features, keep the Unix philosophy of small tools to do a single job. There should not be any need to rewrap the .sit files that are produced by this tool. If some upload workflow is translating binary files and corrupting the upload, then it's a problem with that workflow, and likely not even an issue anymore with current browsers.
Also, there is already a macutils project, which someone has revived with a full meson/ninja build system (overkill, IMO) to handle MacBinary and BinHex: https://github.com/wnayes/macutils. The `macbinary` tool that ships as part of macOS is useless for most Mac files, since it only works if the input files are in AppleSingle or AppleDouble encoding. EDIT: Scratch that -- I had a different `macbinary` installed. The stock `macbinary` seems to work fine if you give it the correct encoding arguments, e.g.
macbinary encode --type 2 Archive.sit
Last edited:
I wasn’t aware of any cloned messages at all. Interesting.
What I can say is that whenever I use my iPhone to write a reply here on TinkerDifferent (within mobile Safari), when I click the “Post reply“ button, sometimes nothing happens. I don’t see my reply posted. So I reload the page and then click the button again and then it gets posted. That never happens when I use my desktop Macs. It only happens when I use my iPhone and it’s pretty regular too. Not sure what the problem is.
I’m using my iPhone right now, so let’s see what happens.
EDIT: No problem this time. It got posted on the first button click. Weird.
What I can say is that whenever I use my iPhone to write a reply here on TinkerDifferent (within mobile Safari), when I click the “Post reply“ button, sometimes nothing happens. I don’t see my reply posted. So I reload the page and then click the button again and then it gets posted. That never happens when I use my desktop Macs. It only happens when I use my iPhone and it’s pretty regular too. Not sure what the problem is.
I’m using my iPhone right now, so let’s see what happens.
EDIT: No problem this time. It got posted on the first button click. Weird.
Ah! It looks like I was mistaken... I had something called `macbinary` in /usr/local/bin which was a symbolic link to another program called `megatron`. Not sure how that got installed.
But on a fresher system, the built-in macbinary command appears to work fine:
megatron is part of Netatalk 2.x and was removed from newer versions due build issues. Don't know how it would have appeared on a macOS machine!