processing hidden files

[lothario]

Doing "ls -a" provides a listing of the hidden files.

To process all the .bak files you can do *.bak for:
that.bak
this.bak
....

But how do you process all the hidden files like:
.that.bak
.this.bak
....

What is the equivalent of *.bak for only the hidden files?

[PabloTwo]

ls -d .*.bak

Though the "-d" option to the "ls" command is for showing only directories, it seems to work quite differently when used with filenames that begin with a leading dot ".". I discovered this quite by accident by messing with the ls command on leading dot files.

BASH:~/-> ls -d .*.old
.xsession-errors.old

[lothario]

Ok.

But how do you process files when you are not using "ls" ?
For example, I have a unknown number of files:

.that1.dat
.this2.bak
.old4.sub
.done9.xup
.hold385.kio
.reck21mn.man
....

If I want to scp all these files that begin with a period "."
How do you pass that as an argument to scp (or whatever) ?

In other words, scp should NOT process files like:
report4.xls
ideas.ppt
Summary.doc

---------- Post added at 07:52 PM CDT ---------- Previous post was at 07:28 PM CDT ----------

Here is another example.

I need to do an md5sum with all these hidden files:
.sampling20100505.data
.variations20100508.globals
....

How do I make md5sum process only the files that begin with a period "." ?

[jpollard]

find is your friend -

find . -depth -name '.*' -type f -print

should list all hidden files that are regular files (not directories).

If you want to combine things you can pipe the output to a script that
processes each file separately:

find . -depth -name '.*' -type f -print | while read F
do
     md5sum $F
done

You can also prevent find from decending directories, but then you would not
need find.

[forkbomb]

Since the preceding dot is really part of the filename, it is processed by many apps as per any other file when it comes to regular expressions. The only complication is that . is also shorthand for $PWD. Considering files starting with . as "hidden" is a shell-ism rather than a filesystem feature -- the filesystem itself doesn't really treat files or directories starting with a period as "hidden."

Try for example

file .*

Or to more explicitly issue a command for dealing with the fact that . is also shorthand for $PWD

file ./.*

A quick way of doing the md5sum thing without recursion is this...

md5sum ./.* 2> /dev/null

That's almost cheating, though. (It's ugly because it will also pass directories starting with . to md5sum, which will cause md5sum to throw errors - hence the redirection of STDERR.)

[lothario]

Thank you for the responses.
That was helpful.

[jpollard]

Since the preceding dot is really part of the filename, it is processed by many apps as per any other file when it comes to regular expressions. The only complication is that . is also shorthand for $PWD. Considering files starting with . as "hidden" is a shell-ism rather than a filesystem feature -- the filesystem itself doesn't really treat files or directories starting with a period as "hidden."

No it isn't - the "." is interpreted by the kernel to mean "current working directory".
It is not handled directly by any application, or even the open system call - other
than that done inside the kernel.

The environment variable PWD doesn't even have to exist - This is an extension that
some shells have added as a convenience when writing shell scripts. It is directly
equivalent to

VAR=`pwd`

except that it doesn't require a new process (the `pwd`) to implement.

You can see this if you do:

[jesse@panther ~]$ echo $PWD
/home/jesse
[jesse@panther ~]$ PWD=xyz
[jesse@panther xyz]$ echo $PWD
xyz
[jesse@panther xyz]$

The current working directory is part of the process context - and is used to allow
applications to shorten file names. If a file is opened - as in open("name"...) - then
the system will concatenate the current working directory with "/" and "name" to
generate the full path to the file. If a file is opened - as in open("./name"...) - then
it means "look in the current directory", and the kernel opens the directory "." to
search for the name.

This works exactly the same way that open("../xyz"...) means "look in the current
directory for the directory named ".." and search for the file named "xyz".

I believe (haven't looked recently) this is being interpreted by the VFS (virtual file
system) layer in the "namei" (name to inode translation) function.

As a side note: the file "xyz/../abc" is handled the same way. The system opens
the directory xyz in the current directory, then opens the file .. (which is the parent
directory, or the current directory) to locate the file "abc". It just takes more
work. But handling of the ".." is not any different.