There are two dir/ls functions which I can't get to work the
way I want :

First is a listing of just the sub-directories in the current directory.
The description of "-d" would seem to be what I want but
all this does is to list the dot dir "." and " dir -d * " lists
all files.

Second is a recursive search of all sub-directories beneath the current location for a filename.
Using "-R" lists all files in all sub-directories but doesn't
seem to accept a specific filename.
I've been using kfind but I prefer the keyboard.

Thanks in advance.

Maybe you are trying to make these utilities do find's job?

find . -type d -maxdepth 1
find . -name file

ls */ -d will list just the subdirectories and not the files. To list the hidden directories use:
ls .*/ -d.

ls */ .*/ -d will list both.

You might want to look at the output of: echo */ and echo .*/ to see what is actually happening. It will explain why ls -a */ doesn't list hidden directories.

Thanks to both of you. That info is exactly what I'm
looking for.


To jschiwal :
The use of echo is intriguing. The man pages don't show the
*/ param.

Thanks again.
Austin

There's an even easier way to accomplish that.

ls -ad *

The idea with the '-a' is that it will list all file, including hidden ones (.files). Of course, either of the methods will work. More than not, there is usually many ways to accomplish the same thing in Linux.

To original poster:
reference the manual page for ls ('man ls') for an even larger listing of options and flags for the ls command.

No, ls -ad * will also list files, and the original posting asked about directories. The -d option will cause ls to not list the contents of the directories and instead list the directories themselves.
ls -ad * also will not list hidden files or directories. Try "ls -ad * | grep kde" vs "ls -ad .*". Repeat my experiment without the trailing slash to see why. ( echo * and echo .* )

The slash at the end of a filename explitely refers to a directory.
For example, "mv ab de" will rename a file to "de" unless de is a directory that exists. However the command "mv ab de/" is unambiguous. If the directory "de" doesn't exist, the command will fail instead of doing the wrong thing.

Jschiwal, you are hiding the truth.

Mcamember, if you looked at 'man echo', you didn't guess. Unlike DOS, where each command had to expand wildcards on its own, shells used in GNU/Linux (or *BSD, or QNX) are expanding wildcards - so the right manual page to read is man bash. And then echo just gets as parameters a list of file names. Surely, it successfully outputs it. Caveat: if you have really lots of files in one dir, shell expansions will stop working, as shell allocates only limited amount of memory for arguments for each command run. But you can still use commands I suggested (and pipe them to xargs to, say, remove files; to move some files you will have to compose a group - read in man bash about {} and ()).

By the way,
ls -d "*/"
works better than
ls -d */
when you have directory name with space in it.

No, ls -d "*d" will try to list a file by the literal name '*d'.
If you use find instead then if the filename pattern contains any wildcards, you need to put them into double quotes to prevent the shell from expanding it itself. Single quotes would cause find to search for a file with a literal name of '*d'.


And, yes, The use of: echo */ shows that the shell is expanding the wildcard and filling the filenames into the argument list. That's what my experiment points out.
You type in the command: ls -d .*/
and the command ls will run with an argument list like
./kde/ ./gnome/ ./ssh/
So it is the same as if you had typed in: ls -d ./kde ./gnome ./ssh
The ls command itself will print the same results regardless. Using 'echo .*/' you can see that the arguments will be.

About listing a file in a subdirectory tree, it is better to use the find command for that.
This might work:
if you know how the depth of the search but that is useless practically.
You could do: ls * -R | grep '/README$'
To list all the files in all the subdirectories but filter out all but README files. This will be very inefficient.