> The script parses macOS’s system_profiler SPUSBHostDataType2 command, which produces a dense, hard-to-scan raw output
I couldn’t find source (the link in the article points to a GitHub repo of a user’s home directory. I hope for them it doesn’t contain secrets), but on my system, system_profiler -json produces json output. From that text, it doesn’t seem they used that.
Last bash source: https://github.com/kaushikgopal/dotfiles/blob/7f37454a887989...
First Go source: https://github.com/kaushikgopal/dotfiles/blob/f0f158398b5e4d...
internally uses the same root command btw. in fact this recently changed for Tahoe (as the article mentions).
started out as a shell script but switched to a go binary (which is what is linked).
I hope this doesn't become a trend. Moving it to go means you need to compile it before you run it, or blindly run an uninspected binary from some random guy
It's not like the performance of this could have motivated it
I'll take the minimal hassle of having to compile a go program over a complex shell script that only the author understands (if that) any day.
Performance isn't everything; readability and maintainability matter too.
> Performance isn't everything; readability and maintainability matter too.
Is that case for this vibe-coded thing? https://news.ycombinator.com/item?id=45513562
No idea, I haven't had a look at this code in particular.
I'm just saying that I've seen several "small tools that could have been shell scripts" in Go or another more structured language and never wished they were shell scripts instead.
I mean, you shouldn't blindly run a shell script anymore than a binary anyways. And if you're reading the code I'd rather read Go than bash any day. That said, yes there is an extra compilation step.
Correct. But you didn't see that the source was one level up in the directory tree from the untrustworthy binary blob?
* https://github.com/kaushikgopal/dotfiles/blob/master/bin/usb...
Presumably there is a sensible way to do this in go by calling an API and getting the original machine-readable data rather than shelling out to run an entire sub-process for a command-line command and parsing its human-readable (even JSON) output. Especially as it turns out that the command-line command itself runs another command-line command in its turn. StackExchange hints at looking to see what API the reporter tool under /System/Library/SystemProfiler actually queries.
> But you didn't see that the source was one level up in the directory tree from the untrustworthy binary blob?
No, silly me. Shortly searched for a src directory, but of course, should have searched for a bin directory, as that’s where vibe coding stores sources /s.