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: