[SOLVED] Get main volume/disk name

My current main volume (where the OS is installed) is called Macintosh HD, but in the future if I change that name, I want my macros to still work wherever I'm using the volume's name.

Is there a way to get the name of that volume so I can save it to a variable?
I could save the name to a global variable, but I would rather have KM set this automatically for the local variables I use.

There may be other easier ways to do this, but this is the method I use:

diskutil info / | grep Volume\ Name | cut -c 31-9999

This works on all of my Macs; you can run it in a Shell Script action and save the result to a variable.

-rob.

1 Like

Thank you for the quick and helpful reply.
Do you mind clarifying what the 31-9999 part means?

Sure ... the basic command works like this:

diskutil info / | grep Volume\ Name
   Volume Name:               UltraSSD

Edit: To clarify, the basic diskutil command will spit out a ton of stuff, but I only want the volume name. So I pass the output to grep to get just that line. But that's still too much…

So then I use the pipe (|) again to pass that output to the cut command, and the -c option on cut means to cut based on columns. The name of the drive starts in column 31, and I just put 9999 to make sure I capture all the text from 31 to the end of the name.

-rob.

3 Likes

Thanks!
I just tested it and it works on my computer as well. Sweeeeet! :raised_hands:

Late to the party - sorry - but this is what I've been using for the past 4 years;

Get Startup Disk Name.kmactions (964 Bytes)

It's a simple bit of AppleScript and it looks like this

image

I run this in a macro set to be triggered at login. Here's the macro:

Download Macro(s): Startup Disk Name.kmmacros (2.2 KB)

Macro-Image

Keyboard Maestro Export

Macro-Notes
  • Macros are always disabled when imported into the Keyboard Maestro Editor.
    • The user must ensure the macro is enabled.
    • The user must also ensure the macro's parent macro-group is enabled.
System Information
  • macOS 13.6.1
  • Keyboard Maestro v11.0.2
2 Likes

Thanks for sharing. Is there any advantage of using this instead of the solution shared by @griffman ?

Don't know. I was just illustrating what Rob said

But I do know I started using it after I changed the name of my start up disk and some of my macros stopped working properly. I've now changed the name two more times with no further issues, so it definitely works for me!

1 Like

Which is the same reason I originally wrote mine :).

As for which is better, the answer is neither: It's just two different ways of doing the same thing. There's probably at least a third and a fourth that we haven't bumped into yet.

But if you're into raw speed, the AppleScript version appears to be faster:

     0.113: AppleScript path
     0.147: Terminal path

-rob.

1 Like

That's contrary to my expectations given previous discussions here re AppleScript performance. Nice to know!

I was a bit surprised as well. Both incur the overhead of launching an engine, but it seems the AppleScript text parser is a bit quicker. I think this is probably due to the time required to run and grep through the diskutil output, which is substantial. I don't know of another spot to see the boot drive name, though.

-rob.

1 Like

Thanks much for the detailed info - very helpful!

This method depends on the text output of diskutil info being printed in a particular way in order for the correct portion of text to be captured. A safer way to process the output of diskutil info is to have the information provided as an XML-formatted property list:

diskutil info -plist /

This can be piped through to the plutil command, which is the macOS command-line utility for processing property list and JSON data. Among its other capabilities, it can parse the input as key-value entries, allowing values to be extracted by specifying its associated keypath. The VolumeName key is top-level, which makes this easy:

diskutil info -plist / |
plutil -extract VolumeName raw - -o -

I'd personally opt for the AppleScript method, for much the same reason as above: it retrieves the information stored in an intrinsically-valued AppleScript constant that will always correctly point to the boot volume, and the only text manipulation needed is to strip the trailing path delimiter that is firmly defined. It's therefore robust, and apparently more performant (possibly because the aforementioned constant gets created as part of the AppleScript environment upon instantiation, so its value is already available, and doesn't need grepping or cutting).

1 Like