This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
It is often a good idea to break the script into smaller, more readable, chunks. It can then become easier to see what each part is doing, and it can also be easier to modify and enhance the script later. As an example, it is easy enough to fix the one-liner you have listed below, but breaking it out into multiple lines might make it easier to add to the script later to make it more generic.
First the one-liner fix:
Placing the code for getting the current timestamp inside the $() tells the shell to execute the commands within the brackets and then use the result inside the larger command.
If I were working on this, I would probably start by putting the current date and time into a field all of it's own:
You could then use this directly in the line you have:
However like I said, I would prefer to have a far more generic function:
Now it can be used for just about any config file you need to backup!
Personal preference - I find it a little hard to read the date-time string as 23_05_09_11_40. I would probably have it as 2009-05-23_1140. But this is purely a personal preference - you should do whatever makes the most sense to you when trying to read the file.
jignesh soni wrote:Can I place this batch file anywhere ? Or is there a particular location where this batch file need to be placed in order to run it ?
You can place this anywhere at all.
There are conventions for where most system administrators would go to look for it.
If this is being run from root's cron job, I would probably put it in /usr/local/sbin (or more accurately, I would probably put it in /usr/local/interwoven-scripts with a symbolic link to it in /usr/local/bin - that way I can put README files etc., with the real script, which the system administrator can find easily enough if they need to).
If this is being run from my own personal cron job, I might put it in ~/bin
If this were being run on-demand from within the TeamSite application I might put it in /usr/local/interwoven, possibly with a symbolic link in /usr/local/bin. That should keep it separate from the Interwoven application itself (so if you do an uninstall or an upgrade you don't have to worry about possibly loosing your personalized scripts), while still keeping it in a common area that all developers can get access to.