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


Click here to return to the 'This "hint" is ludicrous' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
This "hint" is ludicrous
Authored by: gatorparrots on Sep 22, '03 11:49:54AM
I would caution others against following this hint's advice.

Firstly, the author gives inaccurate information: the locate database is updated (as Rob G. thought) once per week via the weekly periodic script. By default, it is scheduled to run at 4:30 a.m. on Saturday. Therefore, it should not interfere with one's work or be very noticeable to a user.

Secondly, it's very inconsiderate and dangerous to go around indiscriminately nuking system-level process in the midst of operation. If anything, one could pause the task (with a -STOP command and resume it at a more convenient time.

Thirdly, the author shows bad scripting style by invoking perl within a Bourne shell script. The script should be written entirely within perl or else the following Bourne one-liner should suffice:
sudo kill `ps axww | awk '/updatedb/ {print $1}'` > /dev/null 2>&1

[ Reply to This | # ]

This "hint" is ludicrous
Authored by: dajwhite on Sep 23, '03 02:33:49PM

Pardon my ignorance, but why is it bad form to call perl from within a shell script? I've never heard of this being discouraged before.

Just curious...



[ Reply to This | # ]
This "hint" is ludicrous
Authored by: babbage on Sep 23, '03 02:59:55PM

Because Perl is *huge*. It's like writing a shell script to manipulate the data in a file, and using AppleScript (osascript) to pull in Microsoft Excel to do the work halfway through.

Excel can be a very useful tool, but there's so much overhead in calling it that for the most part you're better off by [a] going all out & using the heavyweight tool for everything you're trying to do (i.e. do it all in Perl, or Excel), or by [b] finding a way to solve the whole problem with lightweight tools.

By way of another analogy, loading Perl is like taking an airplane ticket somewhere. Sometimes, you want to go somewhere far, so traveling by air is the way to go. In other cases, the distance is short and there's no reason to get in a plane. Mixing Perl & shell code is often like travelling for many hundreds of miles by car, only to get in a plane for the last hundred.

There may be a good reason to do this, but usually it would be more efficient to just take the plane [Perl] the whole way, or find a route that doesn't involve pulling in such an expensive component for such a small portion of the task.

Make sense?


---
--
DO NOT LEAVE IT IS NOT REAL



[ Reply to This | # ]
This "hint" is ludicrous
Authored by: dajwhite on Sep 24, '03 11:19:24AM

Yep. It's always interesting to learn new coding viewpoints. I'm just glad to hear that your objection wasn't based on a technical problem since I've seen it done before and didn't want something biting us at a later date.



[ Reply to This | # ]
This "hint" is ludicrous
Authored by: readparse on Sep 25, '03 12:08:40PM

Thanks for the constructive criticism (well, at least inflammatory criticism). I'm the author of the hint, and you might have noticed my disclaimers about how there was probably a better way to do this. I think I specifically mentioned that calling perl from a shell pipeline wasn't the greatest way to go about it. I think I also mentioned the danger of killing "find" processes on a multi-user machine. I disclaimed and disclaimed some more.

I think I also asked for improvements. The first comment I saw in response was exactly that... "killall updatedb", which made me smile because I figured it probably worked and I was again guilty of overkill and embarassment. However, it happens to be 12:03, so updatedb is running right this second, and I just tried "sudo killall updatedb" and it didn't work. This makes me think that perhaps I had tried that approach earlier and it was one of many that did not work.

I also tried the renice approach, which was also suggested. I tried all of these things long before I finally wrote this script, which does exactly what I need. Yes, Perl is huge, and yet, this is not what I would call a "best practice". But this is something that just takes a moment to run, and it does exactly what I need. After having used it for many weeks with great success, I decided to share it with other users, that they might have similar success. Responses like yours are what keep people from sharing their ideas. It's not "ludicrous". It's "improvable".

Thanks anyway,
ReadParse



[ Reply to This | # ]