packages in TeXShop (was: Re: [OS X TeX] question regarding spacing after a period)
Peter_Dyballa at Web.DE
Sat Mar 14 09:58:40 EDT 2009
Am 14.03.2009 um 01:04 schrieb cfrees at imapmail.org:
> echo /usr/libexec/locate.updatedb | nice -5 su -fm nobody 2>&1 |
> sed -e '/Permission denied/d'
thank you for being so insistent!
When I updated from Panther to Tiger Launch Service did not seem to
perform as documented (maybe I should have waited longer than a day
of eight or ten hours), so I let it coexist with anacron. Since I did
not understand what the cited line was doing, if it really performed
the update since the shell script is just an argument for echo, I
created my own addition. And then I saw the reports in the LOG files
about root permissions, so I added the /etc/locate.rc file with its
PRUNEPATHS setting. The reports persisted, but I could be sure that
security was saved.
This morning I experimented. I let the cited command (plus the ones
to set permissions for /var/db/locate.database) run in a shell owned
by root. Once *with* my /etc/locate.rc file, and a second time
without it. The command "apply 'locate /Users/%1/ | wc -l' Shared
admin arobert btest ctest x11 pete" revealed
with /etc/locate.rc without
1333 1343 (find ~admin | wc -l => 1353)
243121 243137 (find ~ | wc -l => 310664, so some
files aren't locatable)
The latter number come from "locate '*' | wc -l" – locate can handle
some regular expressions. So the /usr/libexec/locate.updatedb shell
script scans all user's home directories – and leaves out /var/root,
root's home directory (locate /var/root/ | wc -l => 0). Without /etc/
locate.rc the GnuPG directories *are* scanned: "locate '/Users/*' |
grep -i gnupg | wc -l" reports a number greater than zero (OK, I
could set permissions to 711 or less)! And of course a DVD, which I
exclude via PRUNEPATHS.
So I have to do two things: update PRUNEPATHS and comment the cited
line in /etc/periodic/weekly/500.weekly. Executing the shell script /
usr/libexec/locate.updatedb as nobody or as root makes no difference
– except: nobody *will* stumble over directories or files it can't
read – and this could lead to side effects. My own scheme relies on /
usr/libexec/locate.updatedb working correctly, as run by any account.
In *any* case /usr/libexec/locate.updatedb does *not* search *some*
sub-trees in a user's home directory. A rule cannot be deduced, at
least not by me ... (Maybe I should also, or better, check the
original GNU locate utilities!)
Hard Disk, n.:
A device that allows users to delete vast quantities
of data with simple mnemonic commands.
More information about the MacOSX-TeX