Upload fails on MacOS — different version of `stat` (and other tools)

[JoeGermuska]

For what it's worth, I tried using this on MacOS Sonoma 14.6.1 and hit an error in atfile.invoke.upload because -c is not a valid flag for the version of stat.

stat: illegal option -- c
usage: stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...]

https://github.com/electricduck/atfile/blob/main/atfile.sh#L1773

[electricduck]

Woops, this ain't my issue. Re-opening!

Should be fixed in 0.4.5.

[bdotsamir]

Hello! This is still not fixed. -c is still used.

[electricduck]

Hello! This is still not fixed. -c is still used.

Hrm. Could you do echo $OSTYPE in Bash on macOS for me? Apparently whatever I read to detect macOS doesn't work

[bdotsamir]

$OSTYPE is currently set to darwin24.0 in Zsh. in Bash, it's darwin24.

Can I ask by the way, why not just run uname ? on Linux, it'll return Linux, and on macos it'll return Darwin. That seems to be all this function is doing 👀

[electricduck]

$OSTYPE is currently set to darwin24.0 in Zsh. in Bash, it's darwin24.

Can I ask by the way, why not just run uname ? on Linux, it'll return Linux, and on macos it'll return Darwin. That seems to be all this function is doing 👀

It's a bit of futureproofing I had in mind, and I prefer using Bash-isms and built-in variables when I can, even though I imagine $OSTYPE is built from uname. If there is any more irritating problems going forward I'll probably drop it in favour of uname though

[electricduck]

To save myself from pushing out a million release, not going to do another release until I'm certain this (and any other macOS woes) is fixed.

Should be fixed in atfile.sh on 02dd356

[bdotsamir]

I have another (two) macOS woes for you 😄 date is complaining about some illegal option -, and realpath complains about -s not being an option. the former I suspect some variable isn't being set. would you like me to open another issue for this? or should we choose this thread to be the master macos annoyances thread?

[electricduck]

should we choose this thread to be the master macos annoyances thread?

Saw this coming from a mile away, haha. Yeah, we'll keep it here :+1:

Gladly accept PRs too since I'm blindly doing this, and although macOS does generally use BSD tools, from memory of using macOS years ago there was a few disparities

[electricduck]

@bdotsamir realpath and date handled in 4bb6dc817f6dc9a619f52fc5bda1eb9c5a467f6e.

The next one might be file, since I can't figure out if macOS has --mime-type or not

[bdotsamir]

I dont see date handled in that diff :( nvm it was in another commit lol And I would PR myself but it's hard to follow the code here. I'll see if I can give it a go

[bdotsamir]

looks like the date command is receiving the format wrongly:

[bdotsamir]

6 fixes the date parsing on macos at least.. though it still fails to upload. not sure what's causing it this time.

[electricduck]

6 fixes the date parsing on macos at least.. though it still fails to upload. not sure what's causing it this time.

hmm, what happens now?

[bdotsamir]

I'm not sure.. it just fails to upload. Error: Unable to upload \

[electricduck]

I'm not sure.. it just fails to upload. Error: Unable to upload

How large is the file? And could you do atfile something-broke

[bdotsamir]

The file is not large at all, 242 kb.

something-broke:

``` ATFile ↳ Version: 0.4.5 ↳ UAS: ATFile/0.4.5 Variables ↳ ATFILE_DEBUG: 0 [0] ↳ ATFILE_ENABLE_HIDDEN_COMMANDS: 0 [0] ↳ ATFILE_ENDPOINT_PDS: ↳ ATFILE_ENDPOINT_PLC_DIRECTORY: https://plc.directory [https://plc.directory] ↳ ATFILE_ENDPOINT_RESOLVE_HANDLE: https://zio.blue [https://zio.blue] ↳ ATFILE_FMT_BLOB_URL: [server]/xrpc/com.atproto.sync.getBlob?did=[did]&cid=[cid] [[server]/xrpc/com.atproto.sync.getBlob?did=[did]&cid=[cid]] ↳ ATFILE_FMT_OUT_FILE: [key]__[name] [[key]__[name]] ↳ ATFILE_INCLUDE_FINGERPRINT: 0 [0] ↳ ATFILE_MAX_LIST: 30 [30] ↳ ATFILE_OUTPUT_JSON: 0 [0] ↳ ATFILE_SKIP_AUTH_CHECK: 0 [0] ↳ ATFILE_SKIP_COPYRIGHT_WARN: 0 [0] ↳ ATFILE_SKIP_NI_EXIFTOOL: 0 [0] ↳ ATFILE_SKIP_NI_MEDIAINFO: 0 [0] ↳ ATFILE_PASSWORD: (Set) ↳ ATFILE_USERNAME: strange.boats Environment ↳ OS: null ↳ Shell: /bin/zsh ↳ Path: /Users/samir/.nvm/versions/node/v20.16.0/bin:/Users/samir/.bun/bin:/Library/Frameworks/Python.framework/Versions/3.11/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/local/MacGPG2/bin:/Library/TeX/texbin:/Applications/VMware Fusion.app/Contents/Public:/Users/samir/.nvm/versions/node/v20.16.0/bin:/Users/samir/miniconda3/condabin:/Users/samir/.bun/bin:/Users/samir/Library/pnpm:/Library/Frameworks/Python.framework/Versions/3.11/bin:/Users/samir/.cargo/bin:/Users/samir/Library/Application Support/JetBrains/Toolbox/scripts:/Users/samir/Library/Android/sdk/emulator:/Users/samir/Library/Android/sdk/platform-tools:/Users/samir/.spicetify:/Users/samir/.local/bin:/Users/samir/Library/Application Support/JetBrains/Toolbox/scripts:/Users/samir/Library/Android/sdk/emulator:/Users/samir/Library/Android/sdk/platform-tools:/Users/samir/.spicetify:/Users/samir/.local/bin Deps ↳ Bash: 3.2.57(1)-release ↳ curl: 8.7.1 ↳ ExifTool: 12.76 ↳ jq: 1.6-159-apple-gcff5336-dirty ↳ md5sum: md5sum (Darwin) 1.0 ↳ MediaInfo: (Not Installed) Actor ↳ DID: did:plc:gtxn6xv4ade4abph2dds4clf ↳ PDS: https://enoki.us-east.host.bsky.network Misc. ↳ md5sum Output: b0e62c6e9157105020c9ba4a7cfed9f3 /Users/samir/Downloads/atfile/atfile.sh ↳ Now: 2024-10-27T00:19:49Z ↳ Rows: 36 ```

[electricduck]

@bdotsamir In 7c3d928f2703c85c7e1d775000e53fd3805fb512, I've added some more debug checkpoints to see exactly where its going wrong. If you run it with ATFILE_DEBUG=1, you'll see this output

[bdotsamir]

@electricduck

Hm. Should the size field be blank?

[electricduck]

@bdotsamir

Hm. Should the size field be blank?

No, it shouldn't be. That'll be where its going wrong. That is being done with wc -c "<file>" | cut -d " " -f 1. afaik, wc has the same params on macOS/BSD... but maybe the output is different

[bdotsamir]

https://enoki.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:gtxn6xv4ade4abph2dds4clf&cid=bafkreib3bhzl3dnvtxfddumb7ge4v4kokqrajrtjm2v5j7csftpv5xpouu

🤓

(no seriously i just needed to change it like so:

- file_size="$(wc -c "$file" | cut -d " " -f 1)"
+ file_size="$(wc -c "$file" | cut -d " " -f 3)"

)

This did not fix the issue though. Uploading a different file type, .mov for example, changes the number we should be putting after -f in the cut command. Why? dunno.

iirc awk is installed everywhere and might have better support for parsing out numbers instead of cutting by space and taking the nth index

[electricduck]

Just replaced the filesize calc with stat instead of using wc

[bdotsamir]

@electricduck That did it! Not getting any more errors 🥳

[electricduck]

These fixes are in 0.4.6

[electricduck]

@JoeGermuska Could you update and confirm this works for you too (and close the ticket if it does) :smile:

[JoeGermuska]

0.4.6 works for me!