The dscl stuff can be omitted and handled more simply this way (using id):

DSCL is used to tell if the user is an admin, not root. if they're not an admin (which root incidently is) they can't use sudo so there's no point in asking for their password.


But those lines also raise a question: is this script intended for the public at large... or just for your personal usage?

Most of what I write I write in a way that can be used by others, even if I only intend to use it myself. Months or even years later I can encounter a need to give code to someone else or to reuse it myself, and this makes it ready-to-go. As of late it's also frighteningly common for me to encounter code in my toolkit that I go to use, and look at it and think "well that's a really good idea, whoever wrote that was really clever!" and then I realize it was my code. Such is my memory. So good comments and clear layout / ease of reuse is very important to me even on a personal level. It's a good thing in that it forces me to code this way, which really everyone should.


I totally get what you're doing there, but i've never seen it done anywhere else before. Maybe it's kosher, but my gut tells me there must be some reason why that might be regarded as slightly more than unorthodox.

I'm sure I'm not the first one to think of it but I did think it up independently. It neatly provides the prompt for the user and authexec's the code. Sometimes I also place a "sudo -k" in front of it to insure it asks for the password in the event they have recently auth'd, for consistency's sake. My service drives boot up as root, which just skates right through that code like it wasn't even there, so all-around it's a very elegant solution. Feel free to criticize that too, but even if you work in a prison you don't have to use a key on every single door you go through during the day, such would be excessive even in that setting.

Since this modified script doesn't actually DO the diskutil command it doesn't even need it though. But I was hoping to fix that wink


Or was your use of the $pl array done so that this version could be quickly adapted for fewer partitions by simply commenting out a few lines?

Correct. I like to make my code as general and easily maintained as possible. Heck, the whole thing could be boiled down to one line of diskutil that has the partition names hardcoded inside quotes if I didn't care about maintainability or readability. But I try to be consistent on both counts.


OTOH, using 2 simpler arrays (each 1 dimensional) might be even better, because their index value can "tie" them together

considered it, may modify it for that later. No point in wasting time on it if it can be made to work automatically anyway. The only reason there's so much already fleshed out here is because I wasn't expecting this problem. Talk of code-reuse, this was actually copied almost verbatim from another script that partitions out about 25 partitions on a usb flash drive for service diagnostic images that Apple requires me to use. (beats lugging around 25 CDs!) That code needs to be modified once or twice a month. But in that case all the partitions were named without spaces in them so I didn't encounter this problem until I got sick of manually repartitioning all the service drives around here every time there was something to add, and lifted the code from there to here, only to find my using spaces in my partition names blew it up. I suppose I could rename the partitions, but y'know, I'm stubborn that way. I'd rather win than concede, even when there's no added practical value in winning. wink


i am embroiled in other "projects" so give me a week or so

Thank you for your time, insight, and patience. Reply at your convenience, I'm not in a big hurry.


I work for the Department of Redundancy Department