Getting the current Home directory in PackageMaker

Question

Hi all,
My package works fine to install a folder in /Library and then set two keys in Loginwindow's defaults file. Even internet-enabled disk image works great.
My problem is, and I've tried now for 2 days to read everything on this, is that I want my install to place an "uninstaller" script on the user's Desktop so the user can easily reverse what the installer did (remove 2 keys and remove the folder in /Library). No problem, this script works fine when run by itself.
But I can't figure out for the life of me how to specify to PackageMaker "home directory of the current user/Desktop" as the install location of this "uninstaller" file. I tried "~/Desktop" and "$HOME/Desktop" in the PackageMaker "destination" field, and also tried making a hierarchy of "~" and "Desktop" folders, and also tried setting the destination to "." and blank. All of these resulted in the Installer making a new directory called "~" at the root of the volume, or one named "$HOME", or just placing the script on the root of the volume. I want it on the user's Desktop, so they will see it. (NOTE: when trying these Unix terms, I was making a separate .pkg for the uninstaller; I know you can't have 2 different install locations in the same package.)
Is this (getting the path to the user's Desktop) possible with PackageMaker, or do I have to have my "postinstall" script for the main install literally create the uninstall script at the user's Desktop (because the "~" notation should be recognized in a shell script)?
I can't figure out why PackageMaker does not recognize the "~" as being the user's home directory - it uses "/" and ".." as defaults sometimes, so it is using the Unix notation.
Also, since the uninstall script is a shell script, if the user double-clicks it, it opens Terminal, which is un-elegant to say the least. Is there a flag that can be set in a shell script which tells it NOT to open Terminal, just to run? I know this is what happens if I wrap it in AppleScript, but I hate using kludges like that.
Thanks in advance to anyone who can help! Happy Holidays
Johnny
Dual 2.0 rev A G5   Mac OS X (10.4.3)  

Answer 1

I have a tech support incident ongoing with ADC about this. People are away for the holidays, but so far I have been able to confirm that PackageMaker itself can't do this, as the name of the current user isn't available, nor do paths to the current Home directory work.
The only way is to have PackageMaker launch a preinstall shell or Applescript that does the "mv <item1> <item2>" or similar (the argument $1 that gets passed to these preinstall scripts IS the name of the user doing the install, so you can get the path to his home directory).
The problem THEN becomes, PackageMaker will not build a package that contains only scripts - it HAS to have some "payload" or you will get a build error. So the ultimate kludge would be to have it run the preinstall script, give it a bogus payload (empty file, etc) to install in e.g., /Library or /Applications, then have the postinstall script delete that bogus payload. I have not tried this so I do not know if it would work.
I am thinking now, with the extremely confusing and apparently contradictory rules that PackageMaker has, that the best way to install software is just to wrap a shell script in an Applescript Application Bundle wrapper (because you can't double-click a shell script without launching Terminal, so to have the user run a shell script you need to wrap it in Automator or AppleScript or a Cocoa app wrapper) and have the shell script do the copying of the files that you need. This still might result in the shell script trying to get some sort of permission (either sudo or that "Override user/group for xxx?" message).
I have read the rules on permissions for Packages about 1,017 times and they still make absolutely no sense to me, and I understand Unix permissions completely. All they would have to do is give some examples, but they don't.