[SOLVED] I had the same problem (June 2022). I'm using Garageband 10.4.6 under mac os Big Sur 11.6.5 (on an old macBook Pro late 2013). When dragging a ".mp3" file (generated with Audacity), the music can be more or less recognised, but the speed is at least twice faster than the original, with kind of distorsion/saturation. When dragging a ".aiff" or a ".wav" file (generated with Audacity), the waiting wheel does not stop turning. Garageband does not respond anymore and I have to kill the process. Like paulowinner suggested, I put "Garageband.app" into the trash, launched "App Store...", clicked menu "Store" > "See my account", entered my apple id and password, scrolled down to find "Garageband" (oct 2014), clicked once to display the page about "Garageband", clicked the "cloud/download" button, waited a few minutes (~800Mb), opened "Garageband" (still 10.4.6) and voilà ! The problem is solved: I can now drag any file type (.mp3 .wav .aiff). They are correctly imported and played as expected. Many thanks, paulowinner. You saved my day !

The find command can do this: % find '/Applications/3DMark Wild Life Extreme.app' -name 'Info.plist' -print will output the full path for each Info.plist file inside the application, like: /Applications/3DMark Wild Life Extreme.app/Wrapper/AttanExtreme.app/Info.plist If you're sure there is only one such file, you can use the defaults read on it: % defaults read "$(find '/Applications/3DMark Wild Life Extreme.app' -name 'Info.plist' -print)" CFBundleExecutable but, if there are several such files, you'd better loop on them: % while read file; do echo "$file"; defaults read "$file" CFBundleExecutable; done < <(find '/Applications/3DMark Wild Life Extreme.app' -name 'Info.plist' -print) If you want to do this for every application in the /Application folder (or in the /System/Applications folder), you can even do: % while read file; do echo "$file"; defaults read "$file" CFBundleExecutable; done < <(find '/Applications' -name 'Info.plist' -print) Is it what you are looking for ?

The g character in 's/^/o/g' means "replace each occurrence in the current line". Otherwise it would replace only the first occurrence of each line. In the particular case where the regexp begins with the caret ^, which means "the regexp should match the beginning of the line", it makes no sense to use the g option. On my mac, I get the following: % echo 'ø\nø' | sed -e 's/^/o/g' sed: RE error: illegal byte sequence % echo 'ø\nø' | sed -e 's/^/o/'  oø oø