Script Review

Hi, I recently started at this company and I don't know a whole lot about writing scripts. I was wondering if someone could review the script below and let me know if i could make any changes on it.

Thanks,

-Ryan

#!/bin/bash
#Copying files to Temporary Daily Log File
$ cp /audit /audit/dailylogs

# Emailing logs to network administrator.
$ cat crontab
MAILTO=rbrimmer@coadmin.net
00 00 1 * * /audit/dailylogs
End

Hi, and welcome to LQ!

If this is your script

#!/bin/bash
#Copying files to Temporary Daily Log File
$ cp /audit /audit/dailylogs

# Emailing logs to network administrator.
$ cat crontab
MAILTO=rbrimmer@coadmin.net
00 00 1 * * /audit/dailylogs
End

pretty much everything but the first two lines is wrong.
$ is not part of a command, it's part of an interactive
prompt.

cron entries don't belong into shell scripts.

End is not a bash keyword.



Cheers,
Tink

It's time for some books....

Bash Guide for Beginners, by Machtelt Garrels (at tldp.org)

Classic Shell Scripting from O'Reilly

Like I said I am new at this. All I have done is research, and apparently by your disheartening reply it's not helping. In any case my deadline for the script is Monday. Any other ideas?

-Ryan

Well ... if you told us what your objectives are, maybe?


Cheers,
Tink

Sorry about that. I need to write the script to email me the auditlogs file every morning for reveiw.

Thanks,

-Ryan

At a given time, or do you want to kick that off manually?

Seeing the cron entry I'll assume that you want it timed.
The stuff below is untested and probably won't work for
you - but it may give you a hint in the right direction.

Give your script a sensible name, and put it in a place
that cron knows about (or specify the full path in cron).

If the file gets rotated each night you can use something like

#!/bin/sh
cat `find /audit -ctime -1 -type f`| mail -s "audit log" rbrimmer@coadmin.net

And in crontab (crontab -e username)

1 0 1 * * /path/to/script

Note: on some systems this will send an email to root or the
process owner informing them about the status of the script run.



Cheers,
Tink

I actually want the script automated, not manual. How did you learn this stuff? Just experience? I have had my head in books and online tutorials for weeks now, and it just won't click.

Experience, reading man-pages, and trying to understand how
Slackware works ;} ... which is quite easy because of its
KISS approach to everything.

Hope it helps a bit?


Cheers,
Tink

That just cut my work load in half. I still have to prepare the presentation for my executive staff. I do want to learn writing scripts and understand Linux more. I just get so frustrated in books, and the tutorials. I read them so much my eyes cross . I'll just keep reading and maybe one day it will click for me.

It help immensly, thanks again.

-Ryan

Originally Posted by ryanbrimmer I actually want the script automated, not manual. How did you learn this stuff? Just experience? I have had my head in books and online tutorials for weeks now, and it just won't click.

Cool to hear Tink's helped you out - I'm not remotely a whiz myself but maybe something in all this will also help.

In the simplest sense, a shell script just a file that's been chmod'ed executable, has '#!/bin/sh' as its preamble, and is just a list of commands after that - a 'batch file' of commands that can be just as you'd type them in at the command line, only wrapped up in a single simple invocation. Then you can get a lot more elaborate from there.

To take my usual shell, the bash manual page lists about half a dozen metacharacters, about a half-dozen more control operators, and a few reserved words. (! case do done elif else esac fi for function if in select then until while { } time [[ ]])

It then describes simple commands, pipelines, lists, and compound commands, which include many of the reserved words and control flow constructs (if, for, while, case).

You learn about these and quoting and the various expansions and substitutions (brace, tilde, parameter, command, arithmetic, process, pathname) and learn about redirection, functions, conditional expressions, and signals and you've basically got it covered.

The real trick is learning the shell builtins and standard external *nix commands to actually harness all their power. The shell scripting framework itself is not too bad. As an infodump, it sounds like a lot, but it's not too terribly many pieces (maybe a dozen or two from a certain way of counting) and if you just break it down to those pieces and take things a step at a time, you'll get it.

So I recommend using the command line as your standard interface (excluding web browsing and image editing and the like, of course - though a lot can be done with that there, too) so you get familiar with all the tools at your disposal (by using them and reading their manual pages). If you don't tend to use the CLI utilities regularly it's going to be like a strange incomprehensible universe but, if you're familiar with them, it's just a case of getting your familiar troops lined up and making them march. And then reading some scripting book straight through just to get a lay of the land and sort of break the ice on what can be a somewhat cryptic manual page at first, and then tear into your shell's manual page, itself. And practice. And re-read the manual page. But everybody has their own learning methods, so just keep experimenting until you find something that works for you. Maybe you're actually reading dry abstractions too much and need to do more of the hands-on practice. Either way - good luck.

That was a much more broken down explanation. I think I was trying to just take it all in one big chunk and read all the dry material on it. You're also absolutely correct about actually getting into the command line and reading the man pages. Getting hands on experience is probably the best way for me to learn at this point.

Thanks,

-Ryan