hdiutil attach command returning extra spaces in Tahoe

It does the same thing using macOS 13.x Ventura so this seems to be the normal behavior for many years now. It seems to be how it works.

So what is the problem? If you follow the instructions online to use a one liner to format the RAM Disk, it works even with those extra spaces. If you need to retrieve the device identifier for some other purpose, then just use the typical command line utilities to remove the spaces.

BTW, I used the following command to confirm how the command shown works:

aa="$(hdiutil  attach  -nomount  ram://2097152)"; echo "***${aa}***"

Edit: If anyone uses the sample command, just remember to use Disk Utility to eject the item associated with the device identifier printed...can be done with the Disk Utility GUI or with the following command (notice no double quotes around the variable so spaces are removed for the command to work...safe to do in this case anyway):

diskutil  eject  $aa

Apple has a pretty strict philosophy regarding command-line tools. They are meant to be used by developers or IT, but only interactively. They can change at any time and regularly do so. They are not supported in any way. The only thing Apple supports is what it calls "API", meant to be used from C, Objective-C, and Swift. And even then, Apple regularly breaks its officially supported API. When that happens, it's a big deal. You can be pretty much assured that Apple will fix the bug in a few months.

If you're writing scripts, you're on your own. In certain limited cases, Apple does provide machine readable output using an "-xml" or "-plist". But otherwise, literally anything goes. You're only complaining about spaces. I've seen cases where Apple added ASCII escape codes for colour output. Good luck parsing that. 😄

At a basic level, I would recommend a more powerful scripting language. On the Mac, that means one thing and one thing only - Perl. Perl is included with the operating system. Python is not. So use Perl. You are doing better than most people by acknowledging the existence of zsh. The "IT crowd" typically only knows about bash.

神林 wrote:

Since Tahoe,

`hdiutil attach -nomount ram://2097152` returns `/dev/disk4[A_LOT_OF_SPACES]` instead of `/dev/disk4`.

Is it a bug?

I can now only use `| xargs` to remove things, otherwise the `if [[ -d` will always fail.

[Re-Titled by Moderator]

Original Title: hdiutil returning more spaces

I have no insight here.

from the Terminal.app you can read more if something changed with the CLI,

search "Creating a RAM-backed device and filesystem"

copy & paste:

man hdiutil | more

Call Customer Support (800) MY–APPLE (800–692–7753)

or on line https://getsupport.apple.com/

or call AppleCare Support at 1-800-APLCARE (800-275-2273)

Outside the USA—Contact Apple for support and service by phone

See a list of Apple phone numbers around the world.

Contact Apple Support - Apple Support

神林 wrote:

I started to use it from 15.5, half a year ago, had already put it into zshrc and runs every time starting Terminal, and i always using quotes, it works fine on 15.5, after 26, it starts to give extra spaces.

I tested with Ventura 13.7.6 which appears to have been released at the same time of 15.5 according to MacTracker and the command gives extra spaces after the "/dev/diskX". It did not just start with Tahoe. Perhaps the behavior somehow changes with various OS updates if you are not seeing the issue with 15.5.

You can say "Yep, it was been going on for a long time" but it doesn't mean it is not a bug.

I never said it was not a bug. If a bug sticks around for years, then either Apple doesn't consider it a bug, or considers it not worthy of their time to address which means it is "normal".

I have made it compatible by removing the spaces.

But i don't think it is a good resolution, it should be fixed by Apple.

You can certainly provide feedback to Apple and/or file an actual bug report with Apple. I seriously doubt it will matter for this issue, but you can alert Apple to the problem.

@etresoft has provided some great insight as well. @etresoft is a third party developer with decades of first hand experience, so they are quite familiar with how macOS and Apple work.