LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   copying hidden files (http://www.linuxquestions.org/questions/linux-general-1/copying-hidden-files-221216/)

Frustin 08-23-2004 04:45 AM

copying hidden files
 
how do you copy hidden files from one directory to another?

b0uncer 08-23-2004 04:52 AM

if you mean the "hidden files" as the files that have dot in front of their filenames (like .xinitrc or .bash_profile), then their copying goes quite normally from the command line: (the first example means you're in the directory you copy the files from, and the second is with full paths)

Code:

cp ./.hiddenfile /path/to/another/place/
and the 2nd example:

Code:

cp /path/to/file/.hiddenfile /another/path/

Frustin 08-23-2004 04:57 AM

i know how to copy one hidden file. i mean to copy _all_ of them at the same time (there are loads).

whansard 08-23-2004 04:58 AM

cp .* otherplace

Frustin 08-23-2004 05:01 AM

ah yes, if you are in the directory you want to copy from it works, but if you are in the directory you want to copy to, it doesnt, it start copying everything up from that as well.

b0uncer 08-23-2004 03:43 PM

try:

Code:

cp /the/dir/where/you/copy/from/.* ./
the first dir comes with full path, and at the place of the filename is simply .* (dot and asterisk) which means "all files that begin with a dot". the second path is simply ./ (dot and slash), which represents the current directory - the one you're in at the moment. you could also specify the full path as the second directory and the files would be copied to there...

Frustin 08-24-2004 02:41 AM

thats the one that doesnt seem to work, or is it if you use the -a option with it perhaps? it seems to copy up from that directory as well.

Dark_Helmet 08-24-2004 03:23 AM

The problem is this:

when you use the full path with the .* wildcard, it matches two special entries:
"." - the current directory
".." - the parent directory

You can prevent that by changing your command to this:
cp /the/dir/where/you/copy/from/.[^\.]* ./

What that says is, "Copy everything that starts with a dot and does not have a dot as the second character". Since the current directory is a single dot, this won't match it, and since the parent directory is two dots, this won't match it either. However, if you have any files such as "..some_file", they won't be copied over either (very unlikely). If you do, though, then I would suggest using the find command or a simple shell script rather than cp.

Frustin 08-24-2004 03:52 AM

thanks all.

jonr 08-27-2004 12:20 AM

Quote:

Originally posted by Dark_Helmet
The problem is this:

when you use the full path with the .* wildcard, it matches two special entries:
"." - the current directory
".." - the parent directory

You can prevent that by changing your command to this:
cp /the/dir/where/you/copy/from/.[^\.]* ./

I was aware of the problem, but had not been able to find the answer. Now I know the answer! Thanks very much, Dark_Helmet.

I use cp to copy rapidly all my home directory files as often as I want to to another hard drive. It has been working fine, except for all the screensful of error messages relating to the dot representing the current directory! Now I will have a neater, and a little bit faster, routine.

I also use two other backup methods, which take a lot longer, to copy less often system files and home files, but for some reason they are neither one as foolproof as the plain cp command. They don't always capture all the files, while cp does.

I'm reluctant to use tar with gzip because I've read that gzipped files are useless past the point of one single error in the archive.

Dark_Helmet 08-27-2004 12:45 AM

Actually, the command I gave works, but the backslash is not needed. In other words, this will work also:
Code:

cp /the/dir/where/you/copy/from/.[^.]* ./
That backslash snuck in by dealing with application that have different rules for regular expressions... not that important though.

Yes, it is possible for a gzip archive to become corrupt, but you can always test it. Tar has a verify option (-W, --verify) to check an archive file once it's created. If it fails, you can try again. If it checks out, then you're good to go. The media you store it on might get corrupted at some point, but you run that risk with anything: hard drive failure, floppy disk going bad, CDR getting scratched, etc.

You don't have to use it if you're not comfortable with it. Just realize that lots of software projects provide their programs in a gzip'ed tar format. So, archive corruption can't be that big a problem. On a personal note, I've never come across a corrupt gzip archive.

jonr 08-27-2004 01:24 AM

Quote:

Originally posted by Dark_Helmet

That backslash snuck in by dealing with application that have different rules for regular expressions... not that important though. [...] On a personal note, I've never come across a corrupt gzip archive.

Well, I must admit I felt proud to recognize what the backslash did--I'm trying to learn regular expressions and simple scripting, but it's an uphill climb. I'll just leave it in there.

Good to know about the verifying process with tar and gzip, and that gzip may not be a problem after all. Tar is certainly a handy and relatively simple way to make very quick copies. I'll probably head back in that direction now! Thanks again.

Frustin 08-27-2004 02:12 AM

you mean an "uphill struggle", if your going uphill you are by default climbing. </pendent> ;)

whansard 08-27-2004 06:07 AM

you could use bzip2 with tar. it's safer.

Data recovery
bzip2 compresses blocks of data independent from each other. For each block, a checksum is created and stored. That's why all non-corrupted compressed data blocks can be easily detected and recovered. The tool bzip2recover which is available from the bzip2 homepage can do this.

Frustin 08-27-2004 06:32 AM

doesnt bzip2 compress better than gzip as well?


All times are GMT -5. The time now is 01:45 PM.