auto-disconnect "server" after copying files

[chris_johnsen]

(As before, I don't have any AFP volumes to test this with, but I did test the "space, single-quotes, and/or parentheses in the volume name" aspect with disk images.)

Originally Posted by afragen

Though as I've just discovered all this code doesn't work if any of the mounts has a space in the name like "Macintosh HD". :-(

Andy

Yes, that's one of the problems with parsing the under-specified and largely undelimited output that the bare mount command produces (it is normally fine for human consumption, but not great for programs that want to do something with the data).

I worked up this hack to handle volume names with spaces (and single quotes, too):

mount | grep ^afp_ \
| sed -E -e 's/^.* on //;s/( \([^()]*\))?$//;'"s/'/'\\\\''/g;s/^/'/;s/\$/'/" \
| xargs umount -f

It could all be done in awk, but it looked ugly, so I reverted back to grep and sed. The idea is that the mount point probably directly follows " on " in the output from the mount command, and that the mount point name extends to the end of the line or to just before a space and a parenthesized string at the end of the line. By extracting the volume name using only what comes before and after it, we avoid getting tangled up with the spaces. There still some pitfalls:

• if the volume name contains the string " on "
• if the parenthesized expression that the OS adds contains parenthesis itself

If either of these come to pass, this code will fail to correctly extract the volume mount point. The first problem could be mostly alleviated if Perl-compatible regular expressions were available. The rest of the sed commands are difficult to read because of all the contortions required by the shell to get a couple of backslashes to sed. The end result is to put the entire line in single quotes (the last two commands), and escape any previously existing single quotes. This is done so that xargs will treat the volume name as one argument, whether it has spaces, single quotes, or anything else.

OK, here it is with Perl, to better handle the problem with " on " in volume names:

mount | grep ^afp_ \
| perl -pe 's/.*? on //;s/( \([^)]*\))?$//;'"s/'/'\\\\''/;s/^/'/;s/\$/'/" \
| xargs umount -f

The difference is the extra question mark before " on ". That modifies the star to do a non-greedy match. Don't expect all sed scripts to transfer that easily to Perl, but it was greatly influenced by sed, awk, and other tools, so I often jump into Perl when the job is just a bit too tough for grep, sed, awk, et al. That non-greedy match was the only thing I needed in this instance, though the functionality of the whole script (running mount, selecting and extracting the mount points, running umount) could be done in Perl if too many other tools also started falling short.

This Perl version still has the problem with parentheses in the parenthesized expression that follows the volume name. Is it safer to assume that users won't put parentheses in their volume names, or that Apple won't put them in the mount options list? If both are possible (and they definitely and probably are, respectively) then I don't see a clear way to distinguish between the volume name and the mount options (unless you assume the mount options will always have balanced parentheses, which can't be matched by regular expressions, so it would take a fancier approach anyway).

Oh, and both of these scripts still have a problem if the string " on " appears in the device part of the mount command's output. I haven't seen that happen, but I wouldn't rule it out (maybe AFP or NFS mounts already do that, I don't have anything to test with, but I'd guess AFP uses a URI-like device name and NFS uses the traditional machine:export device name). This is another intractable problem that stems from trying to parse the undelimited format of the output from the mount command. There has to be a better way to get at all this information (either through some delimited output, or an API: mount does it, Disk Utility does it, something else should be able to also), but it may be beyond what is reasonable in a simple little script.