A Really Dumb Linux Question

Factual Questions
1

OK, I’ve been screwing around with a search engine CGI script for my web page, tinkering with it all day to get it just right. A normal person would’ve just put uploaded the darn thing at the default settings, only making the necessary file location changes to the scripts themselves. But not me. I’m a freak. I have to tinker with damn near every little option to see what it does. Of course, in the end, the script is pretty close to its default settings. Dumb, dumb, dumb.

However, that leads to this really dumb Linux question. Let me start by saying I knew nothing about using Linux two days ago, and in the interim I’ve only learned what I’ve needed to get from point A to point B (the web host company I’m using is running Linux). I’ve been winging it, but so far so good. Now I’ve got the nifty little search engine running. Trouble is, I need to schedule the indexer to run periodicially so the search index doesn’t get out of date. I’d like to use crontab to do it. So my question is about crontab syntax.

I understand the first five fields (minute, hour, day, etc). What I need to know is how to enter the path to the script. Do I do it all the way from root, or just from my entry point?

To illustrate:

From root, the script is at:
/home/username/www/cgi-bin/script/

But when I log in from telnet to run the indexer, I start in the username directory. So to get to the script, I only need to type:

cd www/cgi-bin/script/

So, when I set up the crontab, does it need to be:

0 0 * * * /home/username/www/cgi-bin/script/perl indexer.pl

or

0 0 * * * /www/cgi-bin/script/perl indexer.pl ?

Also, is it necessary to call perl from the crontab? e.g., is the command “perl indexer.pl” (as it is from the telnet prompt) or just plain “indexer.pl” (as it is when a web browser runs a script)?

So, can anyone help me out here? Bonus points for making me see the rhyme and reason behind all this.

2

Put the full path in the crontab file, for both the perl executable and the perl script. You can use ~ for your home directory if you like, although it certainly won’t hurt to type it out.

e.g. 0 0 * * * /usr/bin/perl ~/www/cgi-bin/script/indexer.pl
0 0 * * * /usr/bin/perl /home/username/www/cgi-bin/script/indexer.pl

You can eliminate the need to run the perl command by making the first line of your script something like:

#!/usr/bin/perl

You’ll then need to make the script executable. Type
chmod u+x indexer.pl
in the directory with the script. You should now be able to run it by just typing indexer.pl.

So your crontab command will now just be:
0 0 * * * ~/www/cgi-bin/script/indexer.pl

3

Doesn’t the character that denotes home directory change with command shell? I know ~ is bash (actually all shells descended from the Bourne shell, sh). Does it change in csh (the C shell)?

(Just feeling left out because I didn’t get to flaunt my Linux skills. :))

4

Oh, and as for the rhyme and reason:

When you type “cd www” after logging in, you are saying “change to the subdirectory www from the current directory”. Because you logged in interactively, you are automatically in your home directory.

Doing the same thing in scripts is bad form, because the script only works if started by a certain person in a certain place, that may be forgotten later. Always put absolute directories in scripts, be they Perl scripts or .cshrc scripts.

It’s the difference between giving someone directions from their house to yours by saying “ok, now turn left, drive for three blocks, turn right, drive for one block…” and telling them you live at 123 Horseapple Way.

5

Derleth, I’ve only ever used tcsh, by virtue of its unbelievable superiority over all other command shells, present or future. Both tcsh and csh recognize ~ as home.

I think it is, as you say, an sh thing.

If you want, we could fight about vi vs. emacs, in order to give us both a chance to flex our Linux muscles. Unless of course you are evolved enough to recognize emacs as the only reasonable text editor… :wink:

6

Thanks all…

7

Come on, we all know that joe is the only text editor for real men. :wink:

To continue with the rhyme and reason, that #!/usr/bin/perl can be used for all kinds of scripts… most commonly shell scripts (which are equivalent to batch files). When you run an executable program from the command prompt, the system looks at the beginning of the file, and if it sees #! it decides the file is a script. Then it starts the program you name on the rest of the line to run the script.

If you find yourself doing certain tasks over and over, you can write shell scripts to automate them. For example, if you use a telnet program like CRT that supports zmodem, this script will automatically back up your www directory and send it to you:

#!/bin/sh

go to your home directory

cd

create the backup file

today=date +%Y%m%d
tar cvfz www-backup-$today.tar.gz www

send it via zmodem

sz www-backup-$today.tar.gz

You can save that to a file called ‘backup’ in your home directory, make it executable with ‘chmod u+x backup’, then run it with ‘~/backup’.

8

Mr2001, I’m gonna read that last post a few dozen times and see if I can understand it…

Actually, I do have a followup question. How do I know if cron runs the script? I want to be sure I haven’t screwed anything up…is there any way the server will communicate an error to me, or that I can check on the script’s having been run?

9

And also, for the record, the awesome shell is zsh, which is a virtual superset of both tcsh and bash. :slight_smile:

Yes, the server does have a somewhat annoying way of letting people know when a script is run from cron. :slight_smile:

As a default, if the script sends anything to standard output (stdout) or standard error output (stderr), you will get an email with that output. For that reason, if a script is designed to run from cron, it often will not output anything, or it will output to a logfile. You might want to see if the script has some sort of logfile config for the status of the run. If the script is broken, you will get email every time it tries to run, unless you specifically catch stderr.

10

And about the ~ thing, that doesn’t work under Bourne shell, and so under most unixy systems, that won’t work in cron. However in RHL (possibly under many other dists too, I’m not really sure), you don’t get a true Bourne shell. sh is really bash. Because of that it happens to work. :slight_smile:

11

The good news is, the script worked – I got the email confirming thus. Now, what I need to figure out is how to prevent that email from being sent. I don’t see anything in the script that looks like “stdout” or “stderr;” can anyone help me out?

12

DCU, I am not a unix freak, but , I’d basically try this (without the quotes):
‘your command’ >>‘some file’ 2>&1

Which AFAI understand means pipe (in append mode) standard output into some file, and while you’re at it pipe standard error into standard output.

Also check out http://unix.about.com A great site for these kind of questions.

13

I’m glad that you got your present problem fixed, but this will probably come back to bite you later. Whenever a path starts with ‘/’ , that means to go back to the top level, so /www means “the subdirectory called www in the root directory”. You might not even have a subdirectroy called www in your root directory, in which case you’ll get an error message, or if you do, it’s almost certainly not the same www directory as is in your home directory, in which case God only knows what might happen. By comparison, if you leave off the slash, then it looks for the www directory in whatever directory you happen to be in at the time.

14

Better, change that to this:
0 0 * * * /home/username/www/cgi-bin/script/perl indexer.pl > /dev/null 2>&1

cron automatically e-mails output of a job to the job’s owner. So what you want to do is redirect any output to “nowhere”, which in linux is represented by the device /dev/null. the 2>&1 part means that stream 2 (stderr, the error output stream) gets redirected to stream 1 (stdout, the standard output stream), which is already being redirected to the trash. That way you won’t get any e-mails.

Alternatively, you may want to receive an e-mail when an error occurs. if that’s so, then leave off the 2>&1.

15

Yeah, what micilin said is probably exactly what you want, if this script is just sending normal output rather than having a logfile setup.

Just append that
>>yourfilename 2>&1

part to the line in your crontab.

So mebbe something like this:
0 0 * * * /home/username/www/cgi-bin/script/indexer.pl >>/home/username/indexerlog >2&1

(that might have wrapped, but it should be all one line)

That should stop the dreaded cron email.

The double >> means “append”, so this file should just keep growing and growing unless you trim or delete it

16

If you specify a file (rather than /dev/null), you still won’t get any email, and you will get feedback about what the script did. :slight_smile:

17

Oh, you mean Eagerly Munches All Core Swiftly? EMACS Makes A Computer Slow?

:smiley:


                  Double Bucky

  Double bucky, you're the one!
  You make my keyboard lots of fun.
      Double bucky, an additional bit or two:
  (Vo-vo-de-o!)
  Control and meta, side by side,
  Augmented ASCII, nine bits wide!
      Double bucky!  Half a thousand glyphs, plus a few!
          Oh,
          I sure wish that I
          Had a couple of
              Bits more!
          Perhaps a
          Set of pedals to
          Make the number of
              Bits four:
          Double double bucky!
  Double bucky, left and right
  OR'd together, outta sight!
      Double bucky, I'd like a whole word of
      Double bucky, I'm happy I heard of
      Double bucky, I'd like a whole word of you!

  - The Great Quux

ed, man! ed! The only editor that doesn’t corrupt your precious bodily fluids!

:smiley:

(Rantings and ravings of a Vim freak and a Wordstar tinkerer. :))

18

You fellas sure know how to pick some nits!

Re-reading my post, I’m sure someone will come along shortly and explain (at length) the diffrerence between redirection and a pipe.

Also, isn’t Word the best editor? :smiley:

19

Thanks, guys, I’ve got it redirected into a logfile now, per Undead Dude’s syntax.

20

Derleth, I should clarify that by emacs, I mean GNU emacs. (Never crashes, lightening fast.) The abomination that is xemacs should be shunned by all reasonable people, and your comments very reasonably apply to it.

But really, vim? Good lord. (shudder)