Of course there is nothing wrong with using "find" - but there are a few points I'd like to highlight. (Just between us experts - there are more ways to skin a cat, isn't it? ;-))

Code:

if [[ ! -d ~/$dir ]]
then
	print "Directory does not yet exist. I will make it so..."
	mkdir ~/$dir
	find ~/$dir -type d -print
else
	print "That directory does exist, as well it should."
	ls ~/$dir
	find ~/$dir -type d -print
fi

The first thing is a general observation: when you write some "if..else..fi" and you end up with commands in both the "if"- and the "else"-branches - they could be placed outside the "if" too, no?

Code:

if [[ ! -d ~/$dir ]] ; then
	print "Directory does not yet exist. I will make it so..."
	mkdir ~/$dir
else
	print "That directory does exist, as well it should."
	ls ~/$dir
fi
find ~/$dir -type d -print

The next thing is a minor detail, which will get more and more importance once you move from pet projects to doing real work: quoting. The shell uses blank characters to separate fields in the input. You implicitly rely on this when you write:

Code:

command arg1 arg2

and expect the shell to call "command" with two arguments, "arg1" and "arg2". You don't expect the shell to call "command arg1" (which would be a perfectly fine command name) with one argument "arg2" or something such. Now suppose the directory name you use contains a blank. It is perfectly legal for a unix file to have blanks in the name. The shell would take what you wrote and replace "$dir" with its contents and then try to digest what comes out (suppose the name to be "dir name"):

Code:

find ~/$dir -type d -print
find /home/sudont/dir name -type d -print

First off, "find" would now search for the wrong directory ("dir" instead of "dir name") and then it would be presented an argument "name", which it cannot identify - a syntax error would occur. This is why quoting is recommended always when you deal with values you don't create inside your script, like filenames. Write it like this:

Code:

find ~/"$dir" -type d -print

Even if "$dir" contains a blank the shell will be told to treat it as a single word - this is exactly what double quotes are for. If you ever come across the term "word splitting" - this is what the shell does per default and what double quotes switch off for their inside part.


Next detail: "mkdir" intrinsics.
You write:

Code:

mkdir ~/$dir

and this might well work - as long as you only enter ONE directory level to create. You can enter "super/duper/pooper" and as long as "super/duper" already exists it will create "pooper" as a subdirectory to "duper". But if "super/duper" (or parts of this hierarchy) will not exist the command will fail. This is why "mkdir" has the "-p" switch and experienced script programmers like you should take no unnecessary risk: either you WANT mkdir to fail in this case (then you should create the proper error handling logic like you did with the non-existing directory) or you should routinely use the "-p" switch:

Code:

mkdir -p ~/"$dir"

This will create "~/super/duper/pooper" by first creating "~/super" if it doesn't exist, then creating "~/super/duper" if this doesn't exist and finally "~/super/duper/pooper".

Last thing: "find" is not necessary in this case.
You were already on the right track with "ls", but "ls" per default shows nothing in an empty directory - which is why it looked to you like it failed. But fortunately there is always something in a directory, even a newly created one: the "current directory" entry named "." and the "parent directory" entry named "..". You shure have typed "cd .." to move "higher up" - this is the entry for that. Alas both these entries begin with "." and per default files starting with "." are excluded from display by ls. This is as close to "hidden files" known from DOS/Windows as Unix files get.

Usually this used for configuration files like "~/.profile" or "~/.bashrc". You probably do not want to see them when you do an "ls -l" but only the real files you have, so this is a sensible default. But any default can be overridden and this one can be too - with the "-a" switch of "ls". Therefore, if you want to use "ls" as originally intended, use:

Code:

ls -a ~/"$dir"

instead of "find".

I hope this helps.

bakunin