[scabbage]

Hey, guys,
I'm a Mac newbie. I've been using Linux for quite a while. One thing I like to do is to ssh in my computer and control it remotely. However I find it hard to do so on Mac OS. Now I have a powerMac G4 with Panther installed, which I can use from ssh. In this case, I'm trying to install xcode. I downloaded xcode_tools_1.5_cd.dmg.bin, however have no clue how to install it. I know this would be very easy if I'm sitting in front of the computer as I'll be able to use the GUI tools. Can anyone shed some light on how to install .dmg, .bin and .xit files in command line in general? And also, am I able to use some of the cool tools such as xmonitor on command line? I really wanna know how to manipulate this machine without GUI. Thanks.

[CharlesS]

For .dmg and .dmg.bin, just use hdiutil attach:

hdiutil attach <path to the .dmg file>

This will mount the image in /Volumes and give you back the /dev entry for the mounted disk image. You can then unmount the image by doing either of the following:

hdiutil detach /dev/diskXsY (replace X and Y with the appropriate numbers for the mounted disk image)

or:

diskutil eject /Volumes/<name of mounted disk image>

The hdiutil tool is able to read .dmg files encoded with .bin. However, if you want to actually decode the .bin files, I'm not sure if there's a way to do that at the command line (someone correct me if I'm wrong). Also, since .sit and .sitx are proprietary formats, basically the only thing that can decompress them is StuffIt Expander, which is GUI-only. One way around this would be to leave your computer logged in with the screensaver password on instead of leaving it at the login window. If this is the case, you can ssh in as the logged-in user, and launch GUI apps via the command line, like so:

open -a StuffIt\ Expander <path to .sit, .sitx, or .bin file>

This will only work if some user is logged in at the GUI, though. Otherwise, you'll get a window server error. If you're at the login window, you can launch GUI apps as root via sudo, but it's kind of risky to do that since having a GUI app running as root makes it really easy for evil people to do nasty things to your system as root. Therefore, if you launch a GUI app as root, you want to make sure you do not leave it running for long.

[scabbage]

Originally posted by CharlesS:
For .dmg and .dmg.bin, just use hdiutil attach:

hdiutil attach <path to the .dmg file>

This will mount the image in /Volumes and give you back the /dev entry for the mounted disk image. You can then unmount the image by doing either of the following:

hdiutil detach /dev/diskXsY (replace X and Y with the appropriate numbers for the mounted disk image)

or:

diskutil eject /Volumes/<name of mounted disk image>

The hdiutil tool is able to read .dmg files encoded with .bin. However, if you want to actually decode the .bin files, I'm not sure if there's a way to do that at the command line (someone correct me if I'm wrong). Also, since .sit and .sitx are proprietary formats, basically the only thing that can decompress them is StuffIt Expander, which is GUI-only. One way around this would be to leave your computer logged in with the screensaver password on instead of leaving it at the login window. If this is the case, you can ssh in as the logged-in user, and launch GUI apps via the command line, like so:

open -a StuffIt\ Expander <path to .sit, .sitx, or .bin file>

This will only work if some user is logged in at the GUI, though. Otherwise, you'll get a window server error. If you're at the login window, you can launch GUI apps as root via sudo, but it's kind of risky to do that since having a GUI app running as root makes it really easy for evil people to do nasty things to your system as root. Therefore, if you launch a GUI app as root, you want to make sure you do not leave it running for long.

Thanks. It works. However, I'm not sure exactly how to install the xcode_tools once mounted on /Volumes. Any ideas?

[piracy]

man installer

[Boochie]

You can control the GUI remotely if you activate Apple Remote Desktop from the Sharing Preferences Pane, configure it to allow VNC clients to connect, and then install a VNC viewer on any other machine you wish to use to access the Mac. Voila, virtual Mac GUI from anywhere!

[utidjian]

Originally posted by scabbage:
Hey, guys,
I'm a Mac newbie. I've been using Linux for quite a while. One thing I like to do is to ssh in my computer and control it remotely. However I find it hard to do so on Mac OS. Now I have a powerMac G4 with Panther installed, which I can use from ssh. In this case, I'm trying to install xcode. I downloaded xcode_tools_1.5_cd.dmg.bin, however have no clue how to install it. I know this would be very easy if I'm sitting in front of the computer as I'll be able to use the GUI tools. Can anyone shed some light on how to install .dmg, .bin and .xit files in command line in general? And also, am I able to use some of the cool tools such as xmonitor on command line? I really wanna know how to manipulate this machine without GUI. Thanks.

To install .dmg files from commandline:

1. Mount image on target machine:

sudo hdiutil mount /path/to/somedmg.dmg

which should unpack it to a .pkg file. Then...

2. Install .pkg file:

sudo installer -pkg /Volumes/path/to/somepackage.pkg -target /

3. Fix prebinding:

sudo update_prebinding -root /

Which is supposed to do all that "Optimizing disk" stuff or whatever it is that SoftwareUpdate.app says it is doing.

If you just want to do updates:

1. Check to see which are available:

sudo softwareupdate -l

Note: If one of the updates is Quicktime the next step will hang. It won't hang the system it will just hang the update. This is because even though you are doing this remotely Apple, for some reason, thinks the updater should put a popup screen for registration or something. The update will hang there until you click the [Quit] button (I think it was that). I really wish Apple would fix the this because it makes remote administration MUCH more difficult.

2. If there are no Quicktime updates... update:

sudo softwareupdate -a -i

This could ake a while depending on your connection, number and size of updates, and the "optimizing" part.

3. If the system says reboot:

sudo reboot

If there is a Quicktime update and/or you have a bunch of systems that need updating it can be more efficient to download the updates to a central file server and install them from there. To do this:

1. For example:

Code:
geewhiz:~ admin$ softwareupdate -l
Software Update Tool
Copyright 2002-2003 Apple Computer, Inc.

Software Update found the following new or updated software:
   ! QuickTime652-6.5.2
        QuickTime, 6.5.2, 19752K [required] [restart]
   * AirPortSW-4.1
        AirPort Software, 4.1, 13880K [restart]
geewhiz:~ admin$ sudo softwareupdate -a -d
Password:
Software Update Tool
Copyright 2002-2003 Apple Computer, Inc.


QuickTime: 0...10...20...30...40...
AirPort Software: 0...10...20...30...40...
QuickTime: 0...10...20...30...40...50Bus error
geewhiz:~ admin$

Don't worry about the "Bus error" (yet another thing for Apple to fix). The two packages in the example above have been downloaded to:
/tmp/0/TemporaryItems/com.apple.SoftwareUpdate

Code:
geewhiz:~ admin$ sudo ls /tmp/0/TemporaryItems/com.apple.SoftwareUpdate
AirPortSW.pkg           QuickTime652.pkg
geewhiz:~ admin$

So now you have the two packages as .pkg files (actually directories).

2. Now you can install them as outlined above:

Code:
geewhiz:~ admin$ sudo installer -pkg /tmp/0/TemporaryItems/com.apple.SoftwareUpdate/AirPortSW.pkg -target /
installer: Package name is AirPort
installer: Upgrading volume mounted at /.
installer: The upgrade was successful.
geewhiz:~ admin$ sudo installer -pkg /tmp/0/TemporaryItems/com.apple.SoftwareUpdate/QuickTime652.pkg -target /
installer: Package name is QuickTime 6.5.2
installer: Upgrading volume mounted at /.
installer: The upgrade was successful.
geewhiz:~ admin$

These may take a while and there is no progress bar or anything.

3. Now you need to "optimize" the disk:

Code:
geewhiz:~ admin$ sudo update_prebinding -root /
lotta junk streams by
ending with....
2004-11-20 22:21:47.718 update_prebinding[25180] Prebinding files (1940/1941 complete)
2004-11-20 22:21:48.143 update_prebinding[25180] Update_prebinding done.
2004-11-20 22:21:48.143 update_prebinding[25180] 29 files successfully prebound, 22 files unsuccessfully prebound.

geewhiz:~ admin$

4. Then reboot:

Code:
geewhiz:~ admin$ sudo reboot
Connection to geewhiz.winads.edu closed by remote host.
Connection to geewhiz.winads.edu closed.
[utidjian@whizbert ~]$

All of the above can be scripted in some fashion with some nice logging and verification. I have set up my lab to check for updates from Apple via a "master" machine. It will download but NOT install them to a central location. I then update the master.... and make sure stuff works as expected.... wait a few days and read the boards to see what problems early adopters may have had. If all looks OK I update a "trigger" file and later that night all the "slaves" will automagically update via a cronjob that checks for the trigger. All of this is logged and I get a nice summary email. If any client or update failed to upgrade for whatever reason I will know and can deal with it. Usually the only problems I have is if a machine has been turned off. It will be nice if Macs had WOL ;-) (at least I haven't been able to find that feature).

Some people will tell you that "Repair Permissions" should be done before, during, and after (or some combination of such) in order to keep things in good working order. I have no idea if it is really at all useful to do so. Of course if it is scripted it is hardly a waste of time. It should probably be done after any third-party installs or updates have been done at least as a prophylactic measure. I have found that permissions tend to "drift" for some reason even if no third-party apps have been installed and no updates from Apple have been done. I am not so sure if Apple even knows why this happens. As a Linux user you may find this periodic requirement to "Repair Permissions" somewhat ludicrous for a modern Unix-like operating system. (I do.) In any case... to "Repair Permissions"from the command line:

Code:
geewhiz:~ admin$ sudo diskutil repairPermissions /dev/disk0s9
Started verify/repair permissions on disk disk0s9 Macintosh HD
Determining correct file permissions.
can't compute checksum for ./Library/Printers/Lexmark/Lexmark Z55 Utility.app/Contents/Resources/lxakphal.out
We are using special permissions for the file or directory ./System/Library/Filesystems/cd9660.fs/cd9660.util.  New permissions are 33261
The privileges have been verified or repaired on the selected volume
Verify/repair finished permissions on disk disk0s9 Macintosh HD
[iwhiz:~] physicsa%

Dunno about the "can't compute checksum for ./Library/Printers/Lexmark/Lexmark Z55 Utility.app/Contents/Resources/lxakphal.out" bit but you will always see that part about cd9660.util.

[CharlesS]

I believe that the installer and softwareupdate tools automatically do the prebinding for you. Therefore, running update_prebinding manually shouldn't be necessary.

Also, I've never had that "Bus error" problem while running softwareupdate, and I've done it on quite a few machines now, so chances are that all you'll need to do is run the softwareupdate tool and be done with it.

[scabbage]

This is awesome. You guys are cool. Thanks tons.

[utidjian]

Originally posted by CharlesS:
I believe that the installer and softwareupdate tools automatically do the prebinding for you. Therefore, running update_prebinding manually shouldn't be necessary.

softwareupdate does the "optimizing" but AFAIK installer does not. Perhaps I should try it in verbose mode and see if it does. installer doesn't say if it has "optimized" or not (and tends to finish rather quickly) the way I was using it.

Also, I've never had that "Bus error" problem while running softwareupdate, and I've done it on quite a few machines now, so chances are that all you'll need to do is run the softwareupdate tool and be done with it.

You only get the "Bus error" message on the last package when using the -d option to softwareupdate. The -d option is for --download. It is not in the softwareupdate manpage. I discovered it one day by accident when fooling around with softwareupdate. You can see it if you use no arguments to softwareupdate or just the -h option. Took me a while to find out where it was downloading the files to! I could find nothing on where "to directory set in InternetConfig" meant. The -d option only downloads the files; it does not install them. I find this handier for lab update deployments than fishing around by hand on Apples website for the files.

Quicktime still hangs a commandline softwareupdate. This is really annoying in a lab setting and requires a physical visit to each machine to click on the dialog box before the update will continue. Sometimes if you wait long enough it seems that it will timeout and continue anyhow. Sometimes not. Apple should just fix their Quicktime update packages IMO.

I have read that 10.4 will have better update tools especially for lab type deployments. If they work well it will be very cool... then I can shelve my scripts.

[CharlesS]

Originally posted by utidjian:
softwareupdate does the "optimizing" but AFAIK installer does not. Perhaps I should try it in verbose mode and see if it does. installer doesn't say if it has "optimized" or not (and tends to finish rather quickly) the way I was using it.

You could also watch top and see if the update_prebinding process gets run.

You only get the "Bus error" message on the last package when using the -d option to softwareupdate. The -d option is for --download. It is not in the softwareupdate manpage. I discovered it one day by accident when fooling around with softwareupdate. You can see it if you use no arguments to softwareupdate or just the -h option. Took me a while to find out where it was downloading the files to! I could find nothing on where "to directory set in InternetConfig" meant. The -d option only downloads the files; it does not install them. I find this handier for lab update deployments than fishing around by hand on Apples website for the files.

Okay, makes sense, but why not just run softwareupdate without the -d option and have less hassle to deal with?

[utidjian]

Originally posted by CharlesS:
You could also watch top and see if the update_prebinding process gets run.

I just tried it on another system... the AirPortSW.pkg package did run update_prebinding, the iPod2004-11-15.pkg did not (or I could not see it in top). I started using update_prebinding over a year ago and either Apples installer has changed or I missed seeing the installer running the command back then on the packages I installed. Some people say it is a good idea to run it after installing third-party apps because they may not run it using their installer or Apples.

Okay, makes sense, but why not just run softwareupdate without the -d option and have less hassle to deal with?

There are several reasons why not:

1. In case you missed it... When there is an update to Quicktime, more often than not, 'softwareupdate -a -i' will hang on Quicktime. No biggy for a couple of local machines but expand that to a hundred Macs and it is a problem. Expand it to a hundred (or more) Macs distributed over a campus, some in labs, some in offices... then it is just not workable.

2. Some updates can be rather large... these last two (Airport and iPod) are 14M and 20M respectively. This makes for a tremendous amount of network traffic to the internet connection even in the wee hours if one uses softwareupdate on 100+ Macs. In fact I have seen softwareupdate fail to update due to timeouts when run en mass. I avoid this problem by downloading the updates first to a central server and then distributing them locally. It is reliable and efficient to do so.

3. softwareupdate only works for updates from Apple. The scripts I have work for any software that can distributed as a .pkg. I can install or update 100+ Macs automagically by merely placing the .pkg folder in the distributed update folder and setting the "trigger". The same set of scripts works for all .pkg packages.

I have tested many different scenarios and methods in an effort to make all the Macs on our campus more manageable. I have tried the plain 'softwareupdate -a -i' method and it just does not scale well. While there is certainly room for improvement of my current method... I am working on it... it has saved us a tremendous amount of time and aggravation in managing a lot of Macs. It has been worth the hassle. It will be nice if and when Apple comes out with better tools for this but I just don't have the time to wait for Apple when I have problems that I need to solve now. It would be nice for the Windows techs could do likewise. Linux distros have long had these capabilities built in.

[scabbage]

So is there a way to change preference settings of Panther using command line? For example, turn on/off the remote desk, firewall, etc. And what's the difference between OSXVnc and the remote desktop of Mac OS X itself? Can I use any of them when no user has logged in by using the login window?

[CharlesS]

Originally posted by utidjian:
1. In case you missed it... When there is an update to Quicktime, more often than not, 'softwareupdate -a -i' will hang on Quicktime. No biggy for a couple of local machines but expand that to a hundred Macs and it is a problem. Expand it to a hundred (or more) Macs distributed over a campus, some in labs, some in offices... then it is just not workable.

Yeah, that is annoying. Doesn't the QuickTime Pro screen still come up if you install the package manually, though? I'm genuinely curious how you deal with this since I occasionally have to deal with a similar issue. I've thought about using AppleScript GUI Scripting to dismiss the window...

[utidjian]

Originally posted by scabbage:
So is there a way to change preference settings of Panther using command line?

That depends. If they are GUI desktop and app preferences that is best left to using the GUI tool for that... unless you feel comfortable hand editing XML files.

For example, turn on/off the remote desk, firewall, etc.

Not sure about remote desk, I don't use it.
For firewall see 'man ipfw'. It is similar to 'iptables' in Linux.

And what's the difference between OSXVnc and the remote desktop of Mac OS X itself? Can I use any of them when no user has logged in by using the login window?

I am not sure about these either. I have played with them but I don't use them at all regularly.

[utidjian]

Originally posted by CharlesS:
Yeah, that is annoying. Doesn't the QuickTime Pro screen still come up if you install the package manually, though? I'm genuinely curious how you deal with this since I occasionally have to deal with a similar issue. I've thought about using AppleScript GUI Scripting to dismiss the window...

I am not sure if it still comes up... September 30 (or thereabouts) was the last Quicktime update. Will have to wait until the next one to try it out... unless I can find a machine that hasn't had it updated yet. From my logs all machines have had Quicktime updated.

It may be that it doesn't popup at all if no one is logged in at the console (the Mac is at the login screen) with either method. This would explain why I can sometimes just use 'softwareupdate -a -i' and it works and sometimes I can't. I don't remember. Next update to Quicktime I will check though.

None of the machines I maintain this way have the full Quicktime Pro app. IIRC if one does have the full app it is neccessary to enter the registration information (or whatever) each update. Again, I am not sure about that. If it is required then an AppleScript GUI thing might be neccessary in order for it to update properly. If you are running the full app perhaps you can try it yourself using either method and let us know? ('us' meaning anyone else who is interested, as am I).

[CharlesS]

Originally posted by utidjian:
I am not sure if it still comes up... September 30 (or thereabouts) was the last Quicktime update. Will have to wait until the next one to try it out... unless I can find a machine that hasn't had it updated yet. From my logs all machines have had Quicktime updated.

It may be that it doesn't popup at all if no one is logged in at the console (the Mac is at the login screen) with either method. This would explain why I can sometimes just use 'softwareupdate -a -i' and it works and sometimes I can't. I don't remember. Next update to Quicktime I will check though.

Nope, it pops up whether someone is logged in or not. The QuickTime updater is very stupid. I wish they wouldn't have the updater be so damn inconsiderate. It seems like they were considering removing it at some point, according to these comments in the preflight script:

Code:
# Marketing (aka Amy Fazio) sez we don't need to bring up the registration dialog anymore
# but let's just comment it out for now in case they change their minds. - duano! 3/16/04
# ... see, QT BRB did change their minds on this. Putting it back until Gibson - duano! 3/17/04
# Putting it back in again for Legal reasons (QT5Pro users need to know they're gonna lose functionality).

Of course, you'd think it wouldn't be that hard for them to find a way to detect if someone has QT5Pro installed and thus pop the dialog up ONLY IF THE USER WAS ACTUALLY GOING TO LOSE FUNCTIONALITY. But oh well.

In the setting I have to work in, it was just a single computer lab with about twenty-some computers in it, and it wasn't so bad to walk around the room and hit Enter just one time. In your case it will be more of a problem. The only solutions I see are:

- AppleScript GUI Scripting (would work fine just with softwareupdate -a -i)

- Downloading the package as you already do, then modify the preflight script to comment out the registration crap, then send the package out.

Since you're already downloading the package and installing it manually, the second option is probably best for you. I won't get to test the AppleScript GUI Scripting idea until the next QT update comes out, unless I decide to archive-install a machine just for the purposes of testing this, which I really am not determined enough to do.

None of the machines I maintain this way have the full Quicktime Pro app. IIRC if one does have the full app it is neccessary to enter the registration information (or whatever) each update. Again, I am not sure about that. If it is required then an AppleScript GUI thing might be neccessary in order for it to update properly. If you are running the full app perhaps you can try it yourself using either method and let us know? ('us' meaning anyone else who is interested, as am I).

Unfortunately, I don't have QT Pro either.

[waffffffle]

Originally posted by CharlesS:
Of course, you'd think it wouldn't be that hard for them to find a way to detect if someone has QT5Pro installed and thus pop the dialog up ONLY IF THE USER WAS ACTUALLY GOING TO LOSE FUNCTIONALITY. But oh well.

That's very interesting. I have also been frustrated by the annoying QT popup when trying to update a room of Macs. Apple really needs to fix this yesterday. I'm submitting this as a bug to Apple feedback and everyone else here should too.

[[APi]TheMan]

Originally posted by waffffffle:
That's very interesting. I have also been frustrated by the annoying QT popup when trying to update a room of Macs. Apple really needs to fix this yesterday. I'm submitting this as a bug to Apple feedback and everyone else here should too.

For awhile there was functionality included that would allow you to set the environment variable "COMMAND_LINE_INSTALL" to 1 before running the update. I have not tried it, but here it is in the bash shell:

usrv-osx:~ root# COMMAND_LINE_INSTALL=1

This yields a properly set environment variable:

usrv-osx:~ root# echo $COMMAND_LINE_INSTALL
1

I read this on the rather helpful, Macintosh lab-adminitration-centric, Mac Enterprise mailing list, though I hear the Quicktime updates stopped repsecting it (what a nightmare on a headless Xserve).

You can find the mailing list and archives of that list here: http://listserv.cuny.edu/archives/macenterprise.html

[CharlesS]

Originally posted by [APi]TheMan:
For awhile there was functionality included that would allow you to set the environment variable "COMMAND_LINE_INSTALL" to 1 before running the update.

I should have noticed that when I was looking at the shell script. Guess I only read the comments, got frustrated, and closed the file. D'oh!

The preflight script is a perl script, and the part that pops up the reg screen starts with this:

Code:
if ("$ENV{COMMAND_LINE_INSTALL}" ne "1") {

So, while I haven't tested this, it does appear that if COMMAND_LINE_INSTALL is set to 1, it should skip the annoying reg screen. So, this shell script should work:

Code:
#!/bin/bash

COMMAND_LINE_INSTALL=1
softwareupdate -i -a

Thanks for pointing that out!

[ReggieX]

This has to be one of the coolest threads I've read on MacNN!

[Chuckit]

Originally posted by utidjian:
That depends. If they are GUI desktop and app preferences that is best left to using the GUI tool for that... unless you feel comfortable hand editing XML files.

In many cases, it's just as easy to use the defaults command.

[Phil Sherry]

MacOSXhints has this article: Remotely kill the QuickTime pop-up registration window

[CharlesS]

Originally posted by Phil Sherry:
MacOSXhints has this article: Remotely kill the QuickTime pop-up registration window

Hmm, yes, just killing the process would be easier than using AppleScript GUI Scripting to kill it. Still, preventing it from appearing in the first place with the COMMAND_LINE_INSTALL flag should be the best solution...

[utidjian]

Originally posted by Chuckit:
In many cases, it's just as easy to use the defaults command.

Good tip. Thanks for that.

[Tyler McAdams]

Originally posted by piracy:
man installer

He's been using Linux for a while, I pretty sure he knew that.

[waffffffle]

I'm pretty sure that in the past when I would close the registration window (click the red X button or cmd-W) all of Software Update would die and I would have to run it again to get all the updates that never got installed (including QuickTime). Is this not the case if you kill the process? (I can't test this anymore now that all of my machines have been updated).

[scabbage]

Originally posted by Chuckit:
In many cases, it's just as easy to use the defaults command.

I guess this is what I'm looking for. Now I gotta understand how to use it. Thanks!

[CharlesS]

Originally posted by scabbage:
I guess this is what I'm looking for. Now I gotta understand how to use it. Thanks!

It's pretty easy to use; the man page for defaults lets you know everything you need to know.

[Angus_D]

And for services, etc, some of them can be turned on/off from /etc/hostconfig

[[APi]TheMan]

By the way, I just tried the COMMAND_LINE_INSTALL trick on a 10.2.8 box with the QuickTime 6.5.2 update and it worked. Sweet deal.

[utidjian]

Originally posted by [APi]TheMan:
By the way, I just tried the COMMAND_LINE_INSTALL trick on a 10.2.8 box with the QuickTime 6.5.2 update and it worked. Sweet deal.

Not sure it really makes a difference. I just popped a spare iMac FP out of the packaging to test some of these features we have been discussing. The iMac shipped with 10.2.7 and a set of upgrade CDs for Panther. Out of curiosity, before upgrading to Panther, I thought I would try commandline based upgrades in Jaguar before moving on to Panther. The softwareupdate program is relatively limited in Jaguar; no manpage, no usage help, you have to specify each package to be upgraded (no -a -i switches). After upgrading to 10.2.8 (via CLI) the QuickTime 6.5.2 update became available. I was logged in to the iMac via ssh as the admin user and no one was logged in on console. I set no switches or environment variables and just did a plain old 'sudo softwareupdate QuickTime652' thing. It installed just fine... no interruptions or hangs. So in this case, under the above conditions the 'COMMAND_LINE_INSTALL' trick was not required.

[CharlesS]

Originally posted by utidjian:
Not sure it really makes a difference. I just popped a spare iMac FP out of the packaging to test some of these features we have been discussing. The iMac shipped with 10.2.7 and a set of upgrade CDs for Panther. Out of curiosity, before upgrading to Panther, I thought I would try commandline based upgrades in Jaguar before moving on to Panther. The softwareupdate program is relatively limited in Jaguar; no manpage, no usage help, you have to specify each package to be upgraded (no -a -i switches). After upgrading to 10.2.8 (via CLI) the QuickTime 6.5.2 update became available. I was logged in to the iMac via ssh as the admin user and no one was logged in on console. I set no switches or environment variables and just did a plain old 'sudo softwareupdate QuickTime652' thing. It installed just fine... no interruptions or hangs. So in this case, under the above conditions the 'COMMAND_LINE_INSTALL' trick was not required.

I can tell you that the QuickTime updates just about always throw up a registration screen when you do it. I know this because I've had to walk around the lab hitting Enter on all the computers several times. It's there. Fortunately, by looking at the shell script, it looks like the COMMAND_LINE_INSTALL environment variable will bypass it.

[utidjian]

Originally posted by CharlesS:
I can tell you that the QuickTime updates just about always throw up a registration screen when you do it. I know this because I've had to walk around the lab hitting Enter on all the computers several times. It's there. Fortunately, by looking at the shell script, it looks like the COMMAND_LINE_INSTALL environment variable will bypass it.

OK. I was testing this on Jaguar though not Panther. Also I was not in the room with the iMac when I did the update so I don't know whether it threw up a registration screen or not. The key thing, in this case, the update proceeded regardless of whether there was any registration screen to click in or not.

[CharlesS]

Originally posted by utidjian:
OK. I was testing this on Jaguar though not Panther. Also I was not in the room with the iMac when I did the update so I don't know whether it threw up a registration screen or not. The key thing, in this case, the update proceeded regardless of whether there was any registration screen to click in or not.

I can tell you with absolute certainty that every time I have installed a QuickTime update, I have had to click away the reg screen before it would install.

Does your iMac have QT Pro installed on it?