Please cna you tell me if the following command entered in error would affect the crontab file
crontab -e | more
Thanks 
crontab -e is used to edit (modify) the crontab file. Piping it to more is no use. You may want to look at crontab -l. The crontab command also does error checking on the edited/modified file and will not update the actual crontab file unless the new file is error free.
Thanks blowtorch. But it was in error that I used the -e option and was worried the the command I used would affect the crontab file. The command I wanted to use was crontab -l | more . With crontab using the vi editor and then more for the display I was worried it would affect the file
Hi
- crontab -e
This command is used ONLY for editing/adding the crontabs in vi editor. - crontab -l
This command just dispalys all crontabs at once, the file is not affected - crontab -l | more
This command display the crontabs, incase you file happen to be large,
hit the spacebar to view more.
The file again is not affected.
P.S: Make sure you have spare copy of your crontab file somewhere 
Regards
Sumedha
Old admin point of vue:
using crontab -e : fine you modify etc... but many people do that without having a spare (copy somewhere), some admins when have to do strong maintenance e.g after a crash and under pression dont want things else disturbing then and simply delete the content of the cron spool.. else, if things dont work one day, how do you compare ? (noe previous copy...).
So if you are not too confident, a good way to do things is to have your cronfile somewhere where all cron users can read (so they have no excuse in overlapping schedules...) I usually put them in /sm/cron/ , suffixed by your account name e.g confile.blondie, if paranoid make a second copy ( I do...) cronfile.blondie.last, before any modification you can compare (no one else modified without you knowing of you modified without updating...) lets say you put the cronfiles in /sm/cron
cd /sm/cron
crontab -l >cronfile.blondie
diff blondie blondie.last
use vi to edit/modify
then load the new file:
vi cronfile.blondie
crontab cronfile.blondie
you can chack your update with crontab -l | more ...
I add in comment where the file should be and its name:
# =========================================================================
# /sm/cron/cronfile.prod prod's cronfile (crontab)
# =========================================================================
# F O R M A T
# =========================================================================
# Minute Hour Month_Day Month Weekday Command
# (0-59) (0-23) (1-31) (1-12) (0-6)*0=sun run-string
# =========================================================================
#
All the best
Also, it seems like you are using vi on your crontab. Don't. Use crontab -l or crontab -e
I always VI my crontabs 
crontab -e by default uses vi. The point here is avoiding corrupting or deleting content in an important file like /etc/crontab just because you want to look at it. Obviously vi works. crontab -l is safe. view is safe. vi is not a safe tool to piddle around with the /etc/crontab file.
Safe habits include using crontab, not vi.
I agree with Jim, that using -e just to view can be unsafe... I always vi a freshly generated file... or crontab -l|more ...( some of our DBAs used to till they lost their file and realised they had no spare...It so easy to not know what you are doing with people entering in your office and distract you while the phone starts ringing...)
I agree with vbe. I copy the crontab twice (both with and without a date suffix) to backed-up workspace. Edit with vi and then publish the crontab with "crontab <filename>". This means you have a safe copy of the current crontab, and a copy of all previous crontabs. If you want to check your changes you can run "diff".
Hi, a new question about crontab.
I have some machine in cluster to avoid interuption in manufacturing process. When one is alive the other one is sleep.
Some time happens to switch between them. So i stop the crontab in one and start it in other one. The question is how can i ensure that the two cron are the same? I made a shell to check the difference in the two /var/spool/cron/crontabs directory and it work fine. When an alarm arrive i manualy align the user crontab file in the sleeping machine using crontab -e. My boss ask to me to do this action automaticaly. Do u think that is correct to align the crontab using the remote copy of the users crontab file? I'm not sure, for instance if i make the user crontab using the vi the shell doesn't start. For the same reason i prefer align the crontab manualy beaside with a shell that make a rcp. That's is correct or do u think that i could be use the rcp between the /var/spool/cron/crontabs files?
Best Regards,
Andrea.
Ive seen people spend weeks building up a (redoutable...) cron file after it was lost after a crash and needed to reinstall to OS ( for many sites DONT backup /var in root vg (vg00) eg /var/opt here is another file system as is /var/opt/oracle also and are backed up...)
if you had a copy of you cronfile elsewhere (home directory of that cron user or dedicated directory e.g. /sm/cron) you would always use vi to edit/save followed by a crontab cronfile, you could then compare the file with what is in /var/spool and also rdist it to the other box without using crontab -e, starting the alternate box would be to do just the same with the difference of a first crontab cronfile Im sure it could be automated if needed
This is a timely topic for me. I was looking into just such a problem since I have a two node Service Guard cluster, in use. We have an applications volume group active on only one server at a time. Depending upon which server it is active on, the crontab file has extra jobs to run.
So I thought of having a dedicated and separate area for the local crontab file, and one on the application volume group for the crontab file specific to it.
Then a script could be made to merge the local cron job file with the cron file from the application volume group (if it's mounted) and then submit the merged crontab file to cron. This script would run with the startup of the cluster package for the application volume group.
The local crontab file would look something like this
#<header info>
# LOCAL start
<cron job>
<another cron job>
<etc>
# LOCAL end
And the app volume group crontab file
# APP start
<cron job>
<another cron job>
<etc>
# APP end
A script could easily cat those two files, together into a new crontab file keeping the application specific information last in the file. The process can be "reversed" by resubmitting just the local file when the app volume group is switched back to its primary node. If changes were made in the meantime, to the local portion, no problem, as a simple:
crontab -l | sed -n -e '1,/\# LOCAL end/ p' > newlocal.cron
should give me the most current local listing that can be submitted to eliminate the application volume group entries (of course the changes should have been made to a separate file first, and then submitted so I already have a record of them).
I haven't put this together, yet, it's just been rattling around in my brain at this point, but that's the gist of it. Seems so easy, I must be missing something! :o