Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Easy fix (unverified)' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Easy fix (unverified)
Authored by: enkidu on Nov 04, '01 12:30:52AM
I can't be sure since I didn't have a chance to download the iTunes2 upgrade but by looking at the shell script code, I think that changing the line:
rm -rf $2/Applications/ 2< /dev/null
rm -rf "$2/Applications/" 2< /dev/null
should eliminate the danger of mis-tokenizing the rm -rf line.
As a part-time 'nix hacker (Linux, SunOS, OSF and now OSX), I find the use of spaces in directory/file names a "bad thing" and something that should be avoided, particularly in volume names since many basic system scripts don't properly quote their arguments. Because of the way that sh works, spaces in names just doesn't work unless you're totally anal about quoting everything. This rule also helps reduce confusion (for example doing an ls in a directory with three files named "Enkidu Pictures", "Pictures" and "Enkidu"). This is also why I don't run shell scripts in my wife's user area.
$1 and $2 are the shell variables and represent the first and second arguments to a script.

[ Reply to This | # ]
Authored by: robg on Nov 04, '01 12:38:45AM

That's what Apple changed ... by the way, what does the "2 > /dev/null" part do? I know "> /dev/null" is redirect to null, but what's the "2" for?


[ Reply to This | # ]
Authored by: Brad Puett on Nov 04, '01 02:04:54AM

That's what Apple changed ... by the way, what does the "2 > /dev/null" part do? I know "> /dev/null" is redirect to null, but what's the "2" for?


" 2> " refers to Standard Error, just as " > " refers to Standard Output. So the statement " 2> /dev/null " means that any "leftover" error messages will be "trashed" (i.e. discarded, thrown away).

Hope that was clear!

[ Reply to This | # ]
2 /dev/null
Authored by: reverie on Nov 04, '01 02:07:01AM

2> /dev/null
will consolidate the standard output (stdout) and diagnostic output (stderr) of the preceding command and then send it to /dev/null (i.e., a black hole). Basically, it's making sure the script stays quiet. It's a feature of sh, the Bourne shell, and you can read more about it if you 'man sh'.

[ Reply to This | # ]
And so the deMacification continues...
Authored by: name99 on Nov 05, '01 02:44:30AM

Am I the only one who is horrified, not just by the fact that these bugs occur, but by the response to them?
Here we have Apple screwing up BIG TIME, and the general public response in this forum is basically "Tough---you shouldn't have used spaces in any item on your file system".

Once upon a time Apple and the Mac was about computers adapting to human habits. Now that the UNIX crowd are firmly in charge of Apple, not only are they shoving stupidities like file-name extensions down our throats, or file-case-sensitivity on UFS, but they are now slowly working on making the user , in self censorship, ensure that every file name they use meets UNIX standards.

What happened to
When people trying out Win XP say that it looks better than MacOS X and is easier to use (something I have seen in more than one place, including in the press) it is time for Apple to think seriously about what they are doing.
And it does not help the process when the UNIX heads on the net act as apologists for Apple's user hostility, on the grounds that "well we should all learn the UNIX way of doing things anyway".

[ Reply to This | # ]
And so the deMacification continues...
Authored by: ashill on Nov 05, '01 10:46:39AM

Apple made a major mistake. It was completely their fault, which they publicly acknowledged very quickly. They released a fix very quickly.

This is in no way an apology for an egregious and one might even say negligent mistake on their part, but bugs do happen in programs, particularly in installers. Bugs like this can happen in OS 9 installers; the difference is that we can read the shell scripts for this particular OS X installer and figure out exactly what went wrong. I personally find it interesting to investigate the cause of the bug, but I do not believe that it is the end user's responsibility to know what bit them.

I use spaces in my volume names and in my file names. It is rare that Mac OS X causes problems because of spaces in file names; when it does, it's a bug that needs to be corrected, and has been corrected promptly by Apple.

If you do stuff in a shell on a regular basis, it can be a pain to have files with spaces in them. Therefore, I try to avoid using spaces in files that I regularly access from the terminal. However, if you don't use the terminal (much), there should be no need to worry about spaces, and usually, there is no need to worry about spaces.

I don't speak for this forum, but I am sympathetic to anyone who was bitten by this bug, and I am impressed by Apple's response (although I am not impressed by their testing prior to release). I wish I could be helpful, rather than simply understand what went wrong, but I can't.

Regarding file-case sensitivity on UFS: HFS+ is the default file system, and it behaves exactly like OS 9 with regards to file-case sensitivity: it is case-preserving, but not case-sensitive. File name extensions are not a Unix concept, they're a dumb Windows concept that Apple is sorely mistaken in adopting (IMHO).

No one is saying that we should all learn the Unix way. I am learning the Unix way because I think it's fun, and because I use Solaris (Sun's version of Unix) boxes in the astronomy lab in which I work. It is Apple's publicly stated position that any problem in OS X that requires Unix knowledge to fix is an unresolved bug; for the most part, they have lived up to that promise (including with this iTunes debacle; it could just have well have been a bug in compiled code, as far as Apple's fix is concerned). Sometimes, those of us with Unix knowledge can fix a problem before Apple releases a fix, but that doesn't mean that Apple is forcing users to learn the Unix way; non-Unix-saavy users will have to wait as long (and no longer) than they did for a fix for a similar problem in OS 9.

-Alex Hill

[ Reply to This | # ]
And so the deMacification continues...
Authored by: Brad Puett on Nov 05, '01 01:56:13PM

The main problem I have with this whole "mistake" is that, for at least some of us, it' not fixed!! if I try to install iTunes 2.01 now, as soon as it reboots fromthe installation, I'm left with the "smiley mac face" starign at me from the screen, NO cursor at all, and a freeze that lasts until I force a hardware reset, and then force a PRAM reset, just to get back into 9.2.1!! I'm sorry, but this unacceptable!!

Especially since I'm getting a LOT more errors (roughly 10x) in my log files, plus 2 kernel panics (of which I have never had before this "installation"), which I can never get out of unless I force a hardware reset!!

In order to recover from the "installation", I had to:
a) Hardware reset (i.e. "paperclip")
b) PRAM reset (in order to allow me to boot into 9.2.1)
c) Delete everythig related to "iTune" on the "X" partition ...
d) Reinstall 10.1, using the 10.1 update CD
e) Boot (finally!) into 10.1, go to System Preferences, go to Login, and delete off the iTuneHelper program that was still selected (even though it didn't exist!)

Here's just 2 examples of the messages I'm now still getting:

Nov 5 12:34:02 localhost kextd[41]: loading module:
Nov 5 12:34:03 localhost kextd[41]: loading module:
Nov 5 12:34:04 localhost mach_kernel: USB: 3669.929: [0x16F7600] USB Generic Mouse @ 4 (0x14130000)

Nov 5 12:39:15 localhost mach_kernel: USB: 3980.904: AppleUSBHub[0x16B7A00]::stop - trying command sleep (0/1).
Nov 5 12:39:15 localhost mach_kernel: USB: 3980.960: [0x16F7600] USB Generic Hub @ 3 (0x14100000)
Nov 5 12:39:15 localhost kextd[41]: loading module:
Nov 5 12:39:15 localhost kextd[41]: loading module:
Nov 5 12:39:16 localhost mach_kernel: USB: 3982.276: [0x206CC00] USB Generic Mouse @ 5 (0x14130000)
Nov 5 12:39:16 localhost mach_kernel: USB: 3982.277: [0x16D1000] USB Generic Keyboard @ 4 (0x14110000)
Nov 5 12:39:25 localhost mach_kernel: USB: 3990.751: AppleUSBHub[0x16B7A00]::CheckForDeadHub - calling commandWakeup
Nov 5 12:39:25 localhost mach_kernel: USB: 3990.752: AppleUSBHub[0x16B7A00]::stop - returned from command sleep (0,0)!!

I realize that more than a few people lost data, but what has me temporarily upset is that I've been given the impression by the major Mac Sites that the iTunes 2.01 package *fixed* all the problems, and Apple is no longer working on a solution! It's not fixed for some of us!!

(Sorry, but it's been a *very* frustrating weekend ...)

[ Reply to This | # ]