No. alister is creating a list of values which he supposes to correspond to directory- and filenames. This is because of the way you laid out the problem in your previous posts.

First off, how to find your listfile:

Code:

-bash: ./OTlistfile.txt: No such file or directory

The same way you searched for all the other files:

Code:

find ~ -type f -name "OTlistfile.txt" -print

I will not really matter where it is stored. You could use full paths:

Code:

rm resultfile ; while read num file ; do cat $file spacerfile >> resultfile ; done </full/path/to/where/you/found/listfile.sorted

Second, here are some general tips, some of them digressing from the problem at hand to some more generalized angle:

Present your problem as concisely as possible.

Your description of the problem (the directory layout, how the files are organised, etc.) changed somewhat over the course of the thread. You didn't contradict yourself directly, but you left out critical information in your first description(s) which you gave out one at a time in your later posts.

Problems in shell scripting - and what you are attempting is shell-scripting, despite your claims it is way above your capabilities - are like any other programming problem mostly depending on a clear and precise definition. Once you have precisely defined what you want to do and how you want it to be done the solution is in most cases obvious and easy to implement. Have a look in the "Shell Programming and Scripting" forum and compare threads with many answers with the ones with few answers. One would expect the threads with many answers to be more interesting, but the opposite is the case: the ones with many answers are the ones which usually go like this:

Q: i need to produce X
A: do THIS
Q: ah, yes, fine, but i need the Xs to be different, more like Ys
A: modify THIS to be THAT to produce Ys
Q: many thanks, but my Ys should have a special quality of Z
A: *sigh* do THAT, but modify the FOO part to BAR
... rinse and repeat ad nauseam

The fifth answer was not at all more "complex" or "hard" to give than the first - it was just the realization of having come up with 4 answers completely unnecessarily that caused the sigh.

So, analyze the problem you have as exactly and meticulously as possible and you will be on the fast lane to programmers ascension. What we do is not an arcane art, but just this skill of defining problems precisely and abstractly, mixed with some common sense - trust me, i'm bakunin! ;-))

Second, you sure might want to know how alisters script works (which is, btw., based on a better idea than my own solution, so you should go with it).

Here is the short version of "Introduction to programming logic 101:

The core part is a loop, into which a "here-document" is fed. "Here-documents" are shell-constructs, which are similar to files but have fixed contents, so that they are incorporated into scripts directly. Cosider the following line:

Code:

cat x > y

A file "x" is read by "cat" and its contents are dumped into file "y". What exactly ends up in "y" depends on what was in "x" in first place. But if you want "y" to have a fixed content you could create a here-document replacing the file:

Code:

cat <<EOF > y
foo
bar
foobar
EOF

This says: treat everything you read until a line that reads "EOF" as the content of a (virtual) file. We could have the three lines in file "x" and used the above command to the same effect.

So lets see the relevant part of alisters script:

Code:

while IFS= read -r b; do
     .....
done <<'END_OF_DAYS'
Genesis
Exodus
...
Zechariah
Malachi

Matthew
Mark
...
Jude
Revelation
END_OF_DAYS

The core part into which this here-document is fed is this:

Code:

while read b ; do
     .....
done

This takes one line at a time, fills it into a variable named "b" and does whatever is between "do" and "done". Because with every loop the variable content of "b" changes we can use it for out purposes. Let us say we want to surround the name with equal signs. We could do this:

Code:

while read b; do
     echo == $b ==
done <<'END_OF_DAYS'
Genesis
Exodus
...
Zechariah
Malachi

Matthew
Mark
...
Jude
Revelation
END_OF_DAYS

The command echo == $b == does nothing else than print "==", than the content of variable b (this is what "$b" stands for) and then "==" again. Now, alister does something more sophisticated with "$b", but basically this is it. Let us see what he does:

Code:

    [ -z "$b" ] && t=$nt && continue

He is abbreviating here, so it is not that obvious. Let us write it in the long form and it will become clearer:

Code:

    if [ -z "$b" ] ; then
                   t=$nt
                   continue
              fi

The -z "$b" means: if "$b" is empty. This is true exactly one time: when the loop reads in the empty line in the middle of the document. In this case the variable "t" is filled with "$nt" (the contents of variable "nt") and the enclosing while-loop is immediately started over again ("continue").

Now, take stock: what are the various variables filled with:

$ot=path to old testament books, probably "./01_Old Testament"
$nt=path to old testament books, probably "./01_New Testament"
$t=either $ot (at start) or $nt (after the blank line is processed)

OK, on we go. What else does the while-loop do:

Code:

    i=1
    while cat "$t/$b/$b$i.txt" 2>/dev/null; do
        i=$((i+1))
    done

First, a variable "i" is set to "1". Then, there is another loop:

Code:

    while cat "$t/$b/$b$i.txt" 2>/dev/null; do
        i=$((i+1))
    done

I have to explain something about while-loops here: the general form is

Code:

while <command> ; do
     ......
done

This loop will run "<command>" and if this returns 0 (=TRUE) it will run the body of the loop. The same was true when we used:

Code:

while read b ; do
    ....
done

"read" is a command and it returns TRUE when there is something to read and FALSE if not - this is why the loop stops at the end of the list we feed into.

Inside this loop there is nothing special done, except for incrementing "i" by 1. This is simply counting: 1, 2, 3, 4, 5, .... Every time the command

Code:

cat "$t/$b/$b$i.txt"

is issued. Replacing the various variables with their content (see the list above), this is:

Code:

cat "./01_Old Testament/Genesis/Genesis1.txt"

(after incrementing i by 1)

Code:

cat "./01_Old Testament/Genesis/Genesis2.txt"

etc. at some point, this will give us a filename which doesn't exist. If Genesis has 51 chapters (haven't bothered to look), this would be:

Code:

cat "./01_Old Testament/Genesis/Genesis52.txt"

This time, "cat" would return a non-zero return value, meaning "FALSE" and the loop would stop.

Now there is one last question left: without redirection "cat" will display the content of the file to the screen (try it!). We haven't used any redirection, so why does the output not land on the screen?

Code:

sh bible.sh ~/Desktop/Old\ Testament ~/Desktop/New\ Testament > bible.txt

This is why: it is not only possible to redirect individual commands but also whole scripts. Without the last "> bible.txt" the text would indeed land on the screen. You could replace the redirection with a pipeline:

Code:

sh bible.sh ~/Desktop/Old\ Testament ~/Desktop/New\ Testament | more

Will seend the output to "more", which will display it on screen, but pagewise (hit any key to display another page, CTRL-C to end) or

Code:

sh bible.sh ~/Desktop/Old\ Testament ~/Desktop/New\ Testament | grep someword

to filter only for lines with "someword" in them.

I hope this helps.

bakunin

/PS: i refrained from giving you any practical solution because i figured you are here to learn foremost and to solve your problem at hand second. I hope to have served your intentions best in enabling you to understand and write scripts yourself instead of just throwing something miraculously working at your feet.

Once you overcome your reservations i am sure you will find neverending joy in programming the shell. Don't be shy, there may be only a few chosen, but an awful lot are invited. ;-)