Re: [PATCH] _hdiutil: run candidate-collecting loops outside the pipeline subshell

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Fri, May 29, 2026 at 10:05 PM Clay Caviness <clay@xxxxxxxxxx> wrote:
>
> I apologize for the incorrect diagnosis. My incorrect diagnosis stemmed from my own usage: I almost always invoke `hdiutil eject` with a mount point (`hdiutil eject /Volumes/Foo`). Therefore, when `hdiutil eject /<TAB>` produced no results, I assumed the helper was broken and thought the issue was with subshell semantics rather than realizing the completion only offers the bare entity identifier form (`disk4s1`). With an image actually attached and tabbing from a bare `hdiutil eject `, the existing helper works as designed.
>
> I'll withdraw this patch and work on another that implements the local/read -r changes, figure out if we should be using bare `hdiutil` or the full path (I think bare?) and see if I can add support for offering mount points and completions.

That makes sense, but do note also that compsys will local REPLY (and
other stuff) upon entry to the completion system, see line ~180 in
compinit where _comp_setup is set (this is eval'd when completion
starts). I don't have an osx machine so I don't know the output format
of this hdiutil, but if it can output arbitrary paths separated by
newlines, then IFS= read -r is usually the way to go to avoid problems
with spaces and backslashes. The other option is something like local
-a output=( ${(f)"$(hdiutil blabla)"} ) which explicitly splits the
raw output only by newlines. I'm assuming there won't exactly be
megabytes of output here so the streambased foo | while read handling
isn't strictly needed. That said, if it only ever outputs simple ascii
identifiers like disk4s1 then there's not really any reason to change
anything.

-- 
Mikael Magnusson