Script to tar/rsync/rm multiple folder names

when you say the current iteration of the loop, do you mean any if/else statements inbetween the do and done commands?

---------- Post updated at 05:14 AM ---------- Previous update was at 04:35 AM ----------

i will make it neater near when im nearly done finalizing it but its looking good

#!/bin/bash
cd /to_be_archived/
for DIR in * ; do
fSaveDir="${DIR##*/}"
tar -cf "${fSaveDir}".tar "${fSaveDir}"
if [ $? -ne 0 ]
then
mail -s "${fSaveDir}" robertw@molinare.co.uk <<< "creating of tar "${fSaveDir}" failed due to error"
rm -f "${fSaveDir}".tar
continue
fi
rsync -a "${fSaveDir}".tar /archived_projects/
if [ $? -ne 0 ]
then
mail -s "${fSaveDir}" robertw@molinare.co.uk <<< "rsync of "${fSaveDir}" failed due to error"
continue
fi
rm -f "${fSaveDir}".tar
if [ $? -ne 0 ]
then
mail -s "${fSaveDir}" robertw@molinare.co.uk <<< "removing of tar "${fSaveDir}" failed due to error"
continue
fi
rm -rf "${fSaveDir}"
if [ $? -ne 0 ]
then
mail -s "${fSaveDir}" robertw@molinare.co.uk <<< "removing of "${fSaveDir}" failed due to error"
continue
else
mail -s "${fSaveDir}" robertw@molinare.co.uk <<< "successfully completed archiving "${fSaveDir}""
fi
done

basically what ive done is if fails on the tarring process i want it to delete the tar file straight away

Yes. "loop" means the for-loop and whatever is between "do" and "done" constitutes the loops "body" - the part which is executed once for each iteration.

You would actually be able to see what this loop body is, given you'd stop on ignoring the numerous suggestions to indent your code! This is not about some idle "make it nicer" suggestion. In fact this is a technique developed in decades by generations of programmers writing code proven to work in giving more oversight about the structure of ones program. And before you ask: of course it possible not to do it and still end up with working code. It is also possible to turn left with your car without blinking. But like turning without blinking will increase the chance of having an accident this increases the chance of you losing oversight.

No! you should start writing your code in a neat form, not write it in bad/unreadable form first and make it neat in the end. You need every help to organize your code while you are writing it, not after writing.

Btw., as Don Cragun has mentioned he uses a different indenting style than me. Which one (his, mine or your genuine one) doesn't matter - as long as you use one! I can read Don Craguns code as well as my own (with a possible minimal understanding speed penalty so small i do not even notice) and it is probably the same the other way round. But your code is really hard to read simply because the eye has no "holding point". It is like removing all paragraphs from a text: yes, it is still readable, but perhaps more hard to read.

Finally there is another point: you use a lot of repeating text in your script:

[...]
mail -s "${fSaveDir}" robertw@molinare.co.uk <<< "creating of tar 
[...]
mail -s "${fSaveDir}" robertw@molinare.co.uk <<< "rsync of "${fSaveDir}" failed due to error"
[...]
mail -s "${fSaveDir}" robertw@molinare.co.uk <<< "removing of tar "${fSaveDir}" failed due to error"
[...]

Suppose you want to change the email-address to something else. You would have to go through your code and change every instance of it, right?

For such repeating patterns you might consider using a variable. Look at the following example script:

#! /bin/bash

chMailAddress="robertw@molinare.co.uk"

mail -s "subject 1" "$chMailAddress" <<< "first message"
mail -s "subject 2" "$chMailAddress" <<< "second message" 
mail -s "subject 3" "$chMailAddress" <<< "third message" 

exit 0

If you would want to change the recipients mail address you'd simply change the value of "chMailAddress" at the top - less work and you will be sure to have it changed everywhere and not forgotten one line, no?

So, as a rule of thumb, you look for such repeating patterns (in this case "text constants") and strive to put them into variables ("constants" are simply variables which never change their value).

I hope this helps.

bakunin

#!/bin/bash
cd /to_be_archived/
for DIR in * ;

do
SaveDir="${DIR##*/}"
MailAddress="robertw@molinare.co.uk"

tar -cf "$SaveDir".tar "$SaveDir"

if [ $? -ne 0 ]
then
mail -s "failed "$SaveDir" " $MailAddress <<< "creating of tar "$SaveDir" failed due to error, removing "$SaveDir".tar"
rm -f "$SaveDir".tar
continue
fi

rsync -a "$SaveDir".tar /archived_projects/

if [ $? -ne 0 ]
then
mail -s "failed "$SaveDir" " $MailAddress <<< "rsync of "$SaveDir" failed due to error"
continue
fi

rm -f "$SaveDir".tar

if [ $? -ne 0 ]
then
mail -s "failed "$SaveDir" " $MailAddress <<< "removing of tar "$SaveDir" failed due to error"
continue
fi

rm -rf "$SaveDir"

if [ $? -ne 0 ]
then
mail -s "failed "$SaveDir" " $MailAddress <<< "removing of "$SaveDir" failed due to error"
continue
else
mail -s "success "$SaveDir" " $MailAddress <<< "successfully completed archiving "$SaveDir" "
fi

done

Please indent your code to show its structure! Adding blank lines (instead of indenting) still hides the fact that all of your if statements, tar commands, rsync commands, rm commands, and variable assignments are inside a loop and that your mailx commands and continue statements are conditional in your if then or else clauses. And, it hides the fact that you set MailAddress every time you go through your loop when it just needs to be set once before your loop starts. And separating commands like tar into a different "paragraph" than the code that tests its return value gives a visual cue that it is OK to add other code between them. (But, if you do add any code there the following "paragraph" testing the return code of your tar . rsync , and rm commands will NOT work as desired and there will be no indication that a logic error in your code has been introduced!)

I still question why you want one e-mail per directory processed instead of one e-mail containing the status of all of the directories you are processing, but that it is up to. (Note also that the way I suggested doing it, any status or diagnostic messages from tar , rsync , and rm would have appeared in you e-mail as a permanent record of what happened. The way you are doing it, any output from those commands will appear on your terminal, but will not be part of your permanent record in the archival status stored in you mailbox.)

I repeat that, the way your loop is written, the DIR and SaveDir variables will ALWAYS have the same value. Why use two variables when they can never hold different values? (It forces me to look at your entire script to try to find where you set one of them to have a different value.)

And, as stated before, even though you name your variables DIR and SaveDir , your code creates regular files that are sometimes left lying around that later runs of your script should ignore (or write a diagnostic message telling you that they should be removed). (For example, if the tar succeeds and the rsync fails, a .tar file will be left around. And, you are already noting that rm can fail leaving a .tar lying around. With your code, in these cases, the next time you run your code you'll create a directory.tar.tar file and try to rsync it to your archive area.)

Note that variables are expanded inside double-quoted strings. The command:

mail -s "failed "$SaveDir" " $MailAddress <<< "... "$SaveDir" failed due to error"

should be written as:

mail -s "failed $SaveDir" $MailAddress <<< "... $SaveDir failed due to error"

to protect yourself from serious side effects that will jump up and bite you if one of your directory names ends up containing a whitespace character at some point in the future.

I absolutely, wholeheartedly, fully, completely concur! *)

But probably we can't drive home the fact of just how important indentation is because the script is still in a stage where the structure is very very basic. So, in a last-ditch effort, before i am out of here, here is an excerpt of a real production-level script i use, first without indentation:

while [ -n "$1" ] ; do
chAttr="${1%%=*}"
chValue="${1#*=}"
shift
case "$chAttr" in
"name") # user name
chRemUser="$chValue";;
"hostname") # host name
(( iRemHostPtr += 1 )) # add new element to array
typeset achRemHost[$iRemHostPtr]="$chValue";;
*) (( iAttr = 1 ))
(( lFoundAttr = 0 ))
while [ $iAttr -le ${#achAttr[*]} -a $lFoundAttr -eq 0 ] ; do
if [ "${achAttr[$iAttr]}" == "$chAttr" ] ; then
# protect values with blanks
if [ "$chValue" == "${chValue% *}" ] ; then
achValue[$iAttr]="$chValue"
else
achValue[$iAttr]="'$chValue'"
fi
(( lFoundAttr = 1 ))
fi
(( iAttr += 1 ))
done
if (( lFoundAttr == 0 )) ; then
if (( lStrictChecking == 1 )) ; then
f_CmdError "Unknown Attribute $chAttr ($chValue) found. Aborting:"
f_die 1
else
f_CmdWarning "Ignoring unknown Attribute $chAttr ($chValue)"
fi
fi
;;
esac
done

You might want to compare that drivel to the original:

while [ -n "$1" ] ; do
     chAttr="${1%%=*}"
     chValue="${1#*=}"
     shift

     case "$chAttr" in
          "name")                                # user name
               chRemUser="$chValue"
               ;;

          "hostname")                            # host name
               (( iRemHostPtr += 1 ))            # add new element to array
               typeset achRemHost[$iRemHostPtr]="$chValue"
               ;;

          *)
               (( iAttr = 1 ))
               (( lFoundAttr = 0 ))
               while [ $iAttr -le ${#achAttr[*]} -a $lFoundAttr -eq 0 ] ; do
                    if [ "${achAttr[$iAttr]}" == "$chAttr" ] ; then
                                                 # protect values with blanks
                         if [ "$chValue" == "${chValue% *}" ] ; then
                              achValue[$iAttr]="$chValue"
                         else
                              achValue[$iAttr]="'$chValue'"
                         fi
                         (( lFoundAttr = 1 ))
                    fi
                    (( iAttr += 1 ))
               done
               if (( lFoundAttr == 0 )) ; then
                    if (( lStrictChecking == 1 )) ; then
                         f_CmdError "Unknown Attribute $chAttr ($chValue) found. Aborting:"
                         f_die 1
                    else
                         f_CmdWarning "Ignoring unknown Attribute $chAttr ($chValue)"
                    fi
               fi

               ;;

     esac
done

And if this won't let you see the light perhaps nothing will.

I hope this helps.

bakunin
____________________
*) And that i stopped agreeing here was only because i ran out of pleonasms. :wink:

because i want to be notified straight after the command the return code, if its 0 continue if its not 0 email me straight away, i dont want to print the values and right at the end get an email with any command its failed i want to know straight away

do you think this isnt good practice then?

and sorry what do you mean by dir and savedir are the same, as i cant see any dir name

#!/bin/bash
cd /to_be_archived/
for DIR in * ;

    do
    SaveDir="${DIR##*/}"
    MailAddress="robertw@molinare.co.uk"

tar -cf "$SaveDir".tar "$SaveDir"

    if [ $? -ne 0 ]
    then
    mail -s "failed $SaveDir" $MailAddress <<< "creating of tar $SaveDir failed due to error, removing $SaveDir.tar"
rm -f "$SaveDir".tar
    continue
    fi

rsync -a "$SaveDir".tar /archived_projects/

    if [ $? -ne 0 ]
    then
    mail -s "failed $SaveDir" $MailAddress <<< "rsync of $SaveDir failed due to error, removing $SaveDir.tar"
rm -f "$SaveDir".tar
    continue
    fi

rm -f "$SaveDir".tar

    if [ $? -ne 0 ]
    then
    mail -s "failed $SaveDir" $MailAddress <<< "removing of tar $SaveDir failed due to error"
    continue
    fi

rm -rf "$SaveDir"

    if [ $? -ne 0 ]
    then
    mail -s "failed $SaveDir" $MailAddress <<< "removing of $SaveDir failed due to error"
    continue
        else
        mail -s "success $SaveDir" $MailAddress <<< "successfully completed archiving $SaveDir"
    fi

    done

---------- Post updated at 10:07 AM ---------- Previous update was at 08:04 AM ----------

yeah your right, i didnt need that variable, so i deleted it

SaveDir="${DIR##*/}"

and changed all the

$SaveDir

to

$DIR

also the last if/else statement under the else im going to print/echo the values to a file so i have a hard copy aswell as email

i will let you guys know

thank you for your on going help, much appreciated

cheers

rob

Instead of

command
if [ $? -eq 0 ] ; then
     do_something_success
else
     do_something_failed
fi

as you do you can simply write:

if command ; then
     do_something_success
else
     do_something_failed
fi

which does absolutely the same, just without the risk of putting some other command in between and changing "$?" from the return of one command to the return code of another,as Don Cragun mentioned earlier. Personally i find that style to be easier to follow.

I hope this helps.

bakunin

If you want to know right away that an error occurred while running your script, watch your script run. Using e-mail to be notified of time-critical events is strange. (There is no guarantee that an e-mail message will be delivered in any particular bounded time.) And the messages you're sending indicate that something went wrong, but you don't include the exit code and you don't include any diagnostic messages produced by any failing commands; so you know something went wrong, but you have no idea what the failing command told you when it failed. So, if anything goes wrong, you are throwing away most of the information that would help you figure out what needs to be fixed unless you are watching the script run (in which case, the e-mail gives you late notice of what you already know). And, assuming that most of your archiving activities complete successfully, you also get an urgent e-mail saying that each archival succeeded. After you've run this a few times, will you really notice an e-mail saying a project archival failed when you're used to seeing an e-mail saying a project archival succeeded?

With all of the things a sys admin has to do every day, is failing to archive a completed project high on the list of things that have to be addressed immediately?

The code I suggested gave you a single e-mail with all of the diagnostics produced by any failing commands as well as your failure and success notes. Your code gives you one e-mail containing a single line failure or success note for each attempted archival (throwing away any diagnostics produced by failing commands).

Obviously, you can do what you want to do here. If I were administering attempts to archive projects, I know which I would prefer.

  • Don

PS You might also consider consolidating your remove commands:

rm -f "$SaveDir".tar
     and
rm -rf "$SaveDir"

into the single command:

rm -rf "$DIR" "$DIR.tar"

If you successfully tar a project's files and successfully rsync that archive to your archive server, is there any reason not to try to remove the project's files even if the attempt to remove the tar archive failed?

sorry for the late reply, just been busy work and all

i have added to my script if the tar file already exists in the "archived_projects" folder do not over write and also the size and file count

#!/bin/bash
cd /to_be_archived/
for DIR in * ;

    do
    MailAddress="robertw@molinare.co.uk"

tar -cf "$DIR".tar "$DIR"

    if [ $? -ne 0 ]
    then
    mail -s "tar failed $DIR" $MailAddress <<< "creating of tar $DIR failed due to error, removing $DIR.tar"
    rm -f "$DIR".tar
    continue
    fi

    if [ -f /archived_projects/"$DIR".tar ]; then
      mail -s "duplicate exists $DIR" $MailAddress <<< "$DIR.tar already exists"
    rm -f "$DIR".tar
    continue
    fi

rsync -a "$DIR".tar /archived_projects/

    if [ $? -ne 0 ]
    then
    mail -s "rsync failed $DIR" $MailAddress <<< "rsync of $DIR failed due to error, removing $DIR.tar"
    rm -f "$DIR".tar
    continue
    fi

rm -f "$DIR".tar

    if [ $? -ne 0 ]
    then
    mail -s "remove tar failed $DIR" $MailAddress <<< "removing of tar $DIR failed due to error"
    continue
    fi

du -h "$DIR" >> /archive_details
ls -1 /to_be_archived/"$DIR" | wc -l >> /archive_details

rm -rf "$DIR"

    if [ $? -ne 0 ]
    then
    mail -s "remove folder failed $DIR" $MailAddress <<< "removing of $DIR failed due to error"
    continue
        else
        mail -s "success $DIR" $MailAddress <<< "successfully completed archiving $DIR"
    fi

    done

---------- Post updated at 08:27 AM ---------- Previous update was at 06:10 AM ----------

i think thats a good idea condensing the remove commands to one, i will do that in my next revision, but what bakunin said about you dont need to add the return code to the if statement, i dont seem to get it as for every command you type if it returns 0 (success) or 1-255 (failed) it will either do then or the else statement

but you havnt put in any return code so how does it know whether the command before has succeeded or failed?

OK, short introduction to the intractes of "if":

"if" is followed by a (any) command and it executes first this command, then the "then...."-part if the command returns RC 0 or the "else..."-part, if not. This is always the case. For instance:

if some_command ; then
     echo "some_command returned 0"
else
     echo "some_command returned something else"
fi

Here, the command "some_command" is executed. If it returns 0 the then-part is executed, if it returns something else the "else"-part is executed.

You may ask yourself where this:

if [ $? -eq 0 ] ; then

now comes from because there seems no command to be involved: wrong. In fact there is a command involved and it is called "test". "test" does all kinds of tests: integer comparisons, string comparisons and tests for the existence (or certain attributes) of files and it returns a RC of 0 for the comparisons being (logically) true and an RC <> 0 for comparisons being logically false.

Historically, in the first UNIX versions the construct looked like this (and you may see this still in some very old scripts):

if test $? -eq 0 ; then

or maybe:

if /usr/bin/test $? -eq 0 ; then

You see, the expression to be evaluated consists just of arguments to "test". "test", is still there, i suggest to read the man page of it.

But because this didn't look like the programming languages the inventors of UNIX knew (they were all programmers, after all), they created a device which made it look more like what they were accustomed to: they created a symbolic link from /usr/bin/test to /usr/bin/[ - in fact "[" is a possible filename - and the line now looked like this:

if [ $? -eq 0 ; then

In some variants of UNIX (HP-Ux, if i remember right) this link still exists.

That was actually better but it looked like a bracket was opened and never closed. So the final change to /usr/bin/test was that it expected a "]" as the last argument if it was called as "[" - and this created the look we know today:

if [ $? -eq 0 ] ; then

Notice, that for this reason the following won't work:

if [ $? -eq 0] ; then

because the last parameter now would be "0]", and the expected final "]" would be missing. Try it, you will see that it leads to a syntax error - for the reasons stated above. The following weird-looking construct, though, works perfectly:

if [ "$?" "-eq" "0" "]" ; then

The last step in the development was that programmers of UNIX shells (and i think David Korn with his Korn shell was the first) noticed that "test" and its equivalent was called so often that they made it a shell built-in. This will prevent the necessity of loading and starting an external executable (time-consuming activities) and is a speed optimisation. Still, the buil-in "[" works the same as the external /usr/bin/test (again, with the exception of expecting "]" as the last argument) as the man page for the shell will tell you.

I hope this helps.

bakunin

The POSIX standards require that both test and [ (and all other standard utilities except special built-ins) exist as stand-alone utilities (not just as shell built-ins). This allows them to be used as command arguments to the env , find -exec , nice , nohup , time , and xargs utilities.

The [ expression ] form of the test utility was actually added to UNIX systems before symlinks. On many UNIX and UNIX-like systems, the test and [ utilities are hard links to the same executable file instead of one of them being a symlink or both of them being separate executables.

so am i right in thinking -

tar -cf "$DIR".tar "$DIR"
if [ $? -ne 0 ]
then
mail -s "tar failed $DIR" $MailAddress <<< "creating of tar $DIR failed due to error, removing $DIR.tar"
rm -f "$DIR".tar
continue
fi

is the same as this -

if tar -cf "$DIR".tar "$DIR" ; else
mail -s "tar failed $DIR" $MailAddress <<< "creating of tar $DIR failed due to error, removing $DIR.tar"
rm -f "$DIR".tar
continue
fi

as you said then is equal to 0 and else is not equal to 0?

many thanks

rob

No! You can't have an if statement without a then clause. But, you can do it as I suggested back in post #16 in this thread:

	if ! tar cf "${DIR}".tar "${DIR}"
	then	mail -s "tar failed $DIR" $MailAddress <<< "creating of tar $DIR failed due to error, removing $DIR.tar"
		rm -f "$DIR".tar
		continue
	fi

Note the exclamation point in red in the if statement. That reverses the exit status of the given command ( tar in this case) so that if the command fails (exits with a non-zero exit status) it will execute the then clause and if the command succeeds (i.e., exits with zero exit status) it will execute the else clause if there is one.

Ohh so an ! Means not equal to 0

No. The ! keyword in the shell doesn't MEAN anything. It DOES something. As I said before, it "reverses the exit status of the given command ( tar in this case) so that if the command fails (exits with a non-zero exit status) it will execute the then clause and if the command succeeds (i.e., exits with zero exit status) it will execute the else clause if there is one.

Look at each of the following if statements and try to determine what the output will be. Then run the command and see if it did what you expected:

if true; then echo then; else echo else; fi

if ! true; then echo then; else echo else; fi

if ! ! true; then echo then; else echo else; fi

if false; then echo then; else echo else; fi  
 
if ! false; then echo then; else echo else; fi

if ! ! false; then echo then; else echo else; fi

so its this

if ! tar cf "${DIR}".tar "${DIR}"
then    mail -s "tar failed $DIR" $MailAddress <<< "creating of tar $DIR failed due to error, removing $DIR.tar"
rm -f "$DIR".tar
continue
fi

We realize that the tab key is broken on your keyboard and you don't care about being able to see the structure of your code by properly indenting it. So, yes, the above code will be accepted by your shell.

But, some day, perhaps years from now when you have to look at your code again when something needs to be changed, you'll realize that programming style does make a difference and if statements should be indented when they appear inside a loop and statements in then and else clauses in if statements should be indented further.

	if ! tar cf "${DIR}".tar "${DIR}"
	then	mail -s "tar failed $DIR" $MailAddress <<< "creating of tar $DIR failed due to error, removing $DIR.tar"
		rm -f "$DIR".tar
		continue
	fi

ok so the ! (explanation mark) means if the command doesnt return a 0 or if it fails

sorry to bang on about this just learning so excuse me if i am annoying you guys

---------- Post updated at 08:43 AM ---------- Previous update was at 07:39 AM ----------

also i want to add to my script that if the directory stays the same size then it is safe to start of the script but if the directory changes size ie someones is still moving the directory in "to_be_archived" dont do it and wait till the directoey doesnt increase in size and then it can start off the script

Yes. Whenever the tar-command returns a non-zero value the part between "then" and "fi" (or, in case an else-branch is there, the "then and the "else") is executed. In your case, since there is a "mail"-command and an "rm"-command it will do exactly that.

You are not annoying us because of your questions. What is really annoying is the way you constantly ignore what we say about indenting. Believe me, i have written several hundred thousands lines of code in my life (and Don, i believe, something in the same order of magnitude) and i can tell you that it is absolutely necessary! I wrote programs in Assembler, C, FORTRAN, Clipper, and some interpreted languages (mostly shells) and this was constant in all of them!

If you do not understand how to indent properly: say so. We will explain it to you. But to simply ignore our many suggestions, THAT is really annoying - because it creates a feeling that what we do is in vain.

Here is a simple procedure how to indent properly (in every language):

Indentation is for making stand out two sorts of statements: conditionally executed ones and loop contents. Here is how a loop should look like:

loop-command (while, for, until, repeat, ....)
     command to execute every iteration of the loop 1
     command to execute every iteration of the loop 2
     command to execute every iteration of the loop 3
     [...]
end-loop command

What you see instantly is: 1) where the loop starts and 2) where it ends and 3) what it consists of (the "loops body").

Here is a real-world example in shell:

(( i = 1 ))
while [ $i -le 100 ] ; do
     echo "i is now: $1"
     (( i = i + 1 ))
done

Now, this is my style of doing it, Don Cragun does it a bit different (but equally correct - that is a matter of personal taste):

(( i = 1 ))
while [ $i -le 100 ]
do
     echo "i is now: $1"
     (( i = i + 1 ))
done

Now the conditionals: the same principle applies. Whatever is causing the condition (the "if"-part) is put into a line, then everything between that and the else-line is indented, the "else" itself is at the same level as the "if" and then everything else is indented again until the end of the "if":

if <some-condition>
     command executed if condition is true 1
     command executed if condition is true 2
     command executed if condition is true 3
     [...]
else
     command executed if condition is false 1
     command executed if condition is false 2
     command executed if condition is false 3
     [...]
end-if

Here is a real-world example, this time not in shell but in C:

if (a < b ) {
     printf( "a is smaller than b\n" );
     a += 1;
} else {
     printf( "a is NOT smaller than b\n" );
     b += 1;
}

Notice again how the important parts - which condition everything is based upon ("a < b"), which part is executed when and where each part begins and ends - stand out.
Most programming languages allow to "chain" if-statements. Altough it is not necessary i always align the various conditions horizontally so that they start at the same column. I find that easier to keep track of:

if   [ $x -eq 1 ] ; then
     echo "x is 1"
elif [ $x -eq 2 ] ; then
     echo "x is 2"
else
     echo "x is neither 1 nor 2"
fi

Finally there is another conditional in most programming languages: "case" (or, in C, "switch"). It allows for several branches depending on various values of a single variable or expression. The syntax differs from language to language, but the sctructure is always the same:

case <expression>
     first-possible-value)
          command 1 to execute if expression is "first-possible-value"
          command 2 to execute if expression is "first-possible-value"
          command 3 to execute if expression is "first-possible-value"
          [...]

     second-possible-value)
          command 1 to execute if expression is "second-possible-value"
          command 2 to execute if expression is "second-possible-value"
          command 3 to execute if expression is "second-possible-value"
          [...]

     third-possible-value)
          [...]

end-of-case

Here is the chained if-else-construct from above, this time with a "case":

case $x in
     1)
          echo "x has the value 1"
          ;;

     2)
          echo "x has the value 2"
          ;;

     *)
          echo "x has neither the value 1 nor 2"
          ;;

esac

Notice how the important parts spring right into your eyes: the beginning and end of the construct, the various possible values (1, 2, *) and what part of the code is to be executed if these were to be the case (again, with the beginning and the ending of each).

Finally: you define some "indenting step" for yourself. Pick anything you are comfortable with. I prefer 5 spaces because i like the clear picture it gives. On the other hand you start pretty soon to get far right if you have many indentation steps. Some prefer only 3 spaces, some even two. One can nest more levels with less indentation but at the same time different parts of the code are not separated as clearly as with more indentation. Find your own optimum but FIND one. Do NOT write code the way you do because you will hate yourself once you have to correct or change your own programs after a while.

I hope this helps.

bakunin

3 Likes

It isn't that you're annoying us. We know you're learning. As bakunin said, what bothers us is that you ask questions, we make suggestions, and you ignore our suggestions. (Did you try the script I suggested in post #16 in this thread to see what it would do? Did you even read that post?)

The size of a directory tells you very little about whether or not files in that directory are growing, and (if any files have ever been removed from a directory) even if a new file is created in a directory, its size might not change.

It would be much better if you would create a hidden directory under /to_be_archived (such as /to_be_archived/.in_progress/project ), move everything into that directory, and then after that project directory contains everything you want to archive, issue the command:

mv /to_be_archived/.in_progress/project /to_be_archived/project

which will be an atomic operation. Your existing script won't see the hidden directory so it won't see .in_progress/project until it is ready to process after it has been moved up.