We just had a user where the --- APP_FOLDER="\$HOME/.thunderbird" find "\$APP_FOLDER" -noleaf -type d -maxdepth 1 -mindepth 1 | while read i; do --- section didn't work. The problem was that their thunderbird directory was at $HOME/.thunderbird/default/<random>/ I hadn't had a problem on firefox or thunderbird with the original check which was ---- APP_FOLDER="\$HOME/.thunderbird" for i in $(grep Path= $APP_FOLDER/profiles.ini | sed s/Path=//); do ---- So I'm going to go back to that one for thunderbird and firefox, but leave seamonkey the way it is. Troy Troy Dawson wrote: > Stephan Wiesand wrote: >> Hi Troy, >> >> On Tue, 19 Sep 2006, Troy Dawson wrote: >> >>> Stephan Wiesand wrote: >>>> Hi Troy, >>>> >>>> there were still a couple of minor problems. For example, it's >>>> broken on 64bit. And I really didn't understand the [ ! -a >>>> <filename> ] tests. >>>> >>> >>> Thanks for the 64bit solution, I had forgotten about that. >>> >>> About the test >>> >>> [ ! -a $line/<filename> ] >>> >>> It is just checking to see if the file is there. If there is a file >>> there, I am assuming that we don't want to mess with it. I also >>> figure that if the file is there, then the directory is there. >> >> But shouldn't that be "[ ! -e" instead? The above seems to always >> evaluate to true. Maybe it's some black magic I don't get yet? >> > > Ah ... it's from my "unix in a nutshell" book, the test conditions page. > But now that I double check, it says the this is a Korn shell option. > But it is the check for "file exists". > Of course when I look through the man page, -e is for "file exists" and > -a is for comparing two values. Hmmm ... maybe when there isn't > anything infront of the -a, it defaults back to checking if the file > exists. It works, but yes, I think sticking with the man page would be > best. > >>> [ -d "$line" -a ! -e "$line/%{cleanscript}" ] >>> >>> Although your solution is more thorough, it just seems redundant, >>> doing two checks instead of one (unless I'm reading it wrong). >> >> I agree it's a bit paranoid, but then this runs with root privileges, >> and I wouldn't swear that the glob above will never ever return >> anything weird, no matter under what circumstances. Also, I think >> [ ! -e "$line/%{cleanscript}" ] is not a guarantee that $line exists >> and is a directory, is it? >> > > I think your right. Let's go with your rpm as it stands. > I'm going to recompile and resign it, so that it's consistant with the > same key and build machine as the rest of the errata. > > Troy > >> Cheers, >> Stephan >> >>>> I've put up a a slightly hacked version here: >>>> http://www-zeuthen.desy.de/~wiesand/parentlock/ >>>> >>>> Cheers, >>>> Stephan >>>> >>>> On Mon, 18 Sep 2006, Troy Dawson wrote: >>>> >>>>> Hello, >>>>> This rpm is designed to fix the "Home Area in AFS" parentlock fix. >>>>> >>>>> The problem is triggered when your home area is in AFS, and you use >>>>> firefox, thunderbird, and/or seamonkey. Not always, but often, >>>>> when you stop and restart firefox (or thunderbird, or seamonkey) >>>>> the lock file, called parentlock, is not removed. This makes it >>>>> hard to start up your browser again. >>>>> >>>>> Ftp: >>>>> ftp://ftp.scientificlinux.org/linux/scientific/30rolling/testing/i386/RPMS/browsers/SL_firefox_parentlock_fix-1.0-3.noarch.rpm >>>>> ftp://ftp.scientificlinux.org/linux/scientific/40rolling/testing/i386/RPMS/browsers/SL_firefox_parentlock_fix-1.0-3.noarch.rpm >>>>> >>>>> Yum - S.L. 4.x >>>>> yum --enablerepo=sl-testing install SL_firefox_parentlock_fix >>>>> >>>>> The rpm has already been tested on several computers, and we >>>>> believe it works well. But we would like others to test it more >>>>> before it goes out. >>>>> >>>>> Thanks >>>>> Troy -- __________________________________________________ Troy Dawson [log in to unmask] (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________