Hello all: How can I use md5sum program recursively both for creating md5 cheksums and for checking? Thanks, IG ____________________________________________________________________ 12 új Dal Pressertől! http://zenearuhaz.t-online.hu/index.php?m=info&albumid=24377&sty=3
On Wednesday 27 September 2006 14:33, Istvan Gabor wrote:
How can I use md5sum program recursively both for creating md5 cheksums and for checking?
example: stephan@owl:~/include> find . -type f | xargs md5sum > ~/tmp/foo.md5 stephan@owl:~/include> md5sum -c ~/tmp/foo.md5 -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
How can I use md5sum program recursively both for creating md5 cheksums and for checking?
example:
stephan@owl:~/include> find . -type f | xargs md5sum > ~/ tmp/foo.md5
stephan@owl:~/include> md5sum -c ~/tmp/foo.md5
Thanks stephan! I tried it and work but only partially. I get error messages when the file/directory names contain white spaces. How can I make it work with these files too? Thanks, IG ____________________________________________________________________ 12 új Dal Pressertől! http://zenearuhaz.t-online.hu/index.php?m=info&albumid=24377&sty=3
On Wednesday 27 September 2006 18:09, suseuser04@freemail.hu wrote:
I tried it and work but only partially. I get error messages when the file/directory names contain white spaces. How can I make it work with these files too?
a) Whitespace in filenames is evil. It causes all sorts of problems. b) find . -type f -print0 | xargs -0 md5sum -print0 uses a NULL character to separate filenames, intead of a newline, and -0 tells xargs to expect that as input. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
I tried it and work but only partially. I get error messages when the file/directory names contain white spaces. How can I make it work with these files too?
a) Whitespace in filenames is evil. It causes all sorts of problems.
It's not. You just don't know how to handle it correctly. :)
b) find . -type f -print0 | xargs -0 md5sum
-print0 uses a NULL character to separate filenames, intead of a newline, and -0 tells xargs to expect that as input.
To be exact, the thing is called NUL ('\0'), not NULL ((void *)0). Jan Engelhardt --
On Wednesday 27 September 2006 18:30, Jan Engelhardt wrote:
I tried it and work but only partially. I get error messages when the file/directory names contain white spaces. How can I make it work with these files too?
a) Whitespace in filenames is evil. It causes all sorts of problems.
It's not. You just don't know how to handle it correctly. :)
Obviously i do or i wouldn't have written the line below:
b) find . -type f -print0 | xargs -0 md5sum
-print0 uses a NULL character to separate filenames, intead of a newline, and -0 tells xargs to expect that as input.
To be exact, the thing is called NUL ('\0'), not NULL ((void *)0).
We're not talking C, we're talking GNU Find. So... to be EXACT, RTFM: -print0 True; print the full file name on the standard output, followed by a null character (instead of the newline character that `-print' uses).... PS: in C++, NULL is guaranteed by the ISO standard to be 0, not ((void *)0). -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
On Wednesday 27 September 2006 19:06, stephan beal wrote:
On Wednesday 27 September 2006 18:30, Jan Engelhardt wrote:
I tried it and work but only partially. I get error messages when the file/directory names contain white spaces. How can I make it work with these files too?
a) Whitespace in filenames is evil. It causes all sorts of problems.
It's not. You just don't know how to handle it correctly. :)
Obviously i do or i wouldn't have written the line below:
b) find . -type f -print0 | xargs -0 md5sum
-print0 uses a NULL character to separate filenames, intead of a newline, and -0 tells xargs to expect that as input.
To be exact, the thing is called NUL ('\0'), not NULL ((void *)0).
We're not talking C, we're talking GNU Find. So... to be EXACT, RTFM:
-print0 True; print the full file name on the standard output, followed by a null character (instead of the newline character that `-print' uses)....
PS: in C++, NULL is guaranteed by the ISO standard to be 0, not ((void *)0).
Jan & Stephan: According to http://en.wikipedia.org/wiki/ASCII seems you're both right: null-character or NUL-character. Cheers, Leen
a) Whitespace in filenames is evil. It causes all sorts of problems.
It's not. You just don't know how to handle it correctly. :)
Obviously i do or i wouldn't have written the line below:
b) find . -type f -print0 | xargs -0 md5sum
If people would always use -print0 the first time, or when filenames with spaces are expected, the world would not break as much. Of course I have to agree that not all tools have a -0 option (like xargs) or otherwise support parsing '\0'-terminated filenames, but the most important do (find, xargs/grep, tar,..). bash of course does not have one (or I do not know of any), but bash can handle newline terminators well enough that find's -print works as intended in for loops.
-print0 uses a NULL character to separate filenames, intead of a newline, and -0 tells xargs to expect that as input.
To be exact, the thing is called NUL ('\0'), not NULL ((void *)0).
We're not talking C, we're talking GNU Find. So... to be EXACT, RTFM:
-print0 True; print the full file name on the standard output, followed by a null character (instead of the newline character that `-print' uses)....
Bug.
PS: in C++, NULL is guaranteed by the ISO standard to be 0, not ((void *)0).
It actually evaluates to the special symbol __null in g++, which seems to be ((anytype *)0) for C++ most of the time. Jan Engelhardt --
On Thursday 28 September 2006 10:22, Jan Engelhardt wrote:
If people would always use -print0 the first time, or when filenames with spaces are expected, the world would not break as much. Of
If people use -print0 then they're writing unportable scripts. If you ever administer, e.g., a Solaris machine, you'll find out that all of the niceties of the GNU tools don't exist in non-GNU versions of those tools. e.g., -print0 and -0. Yes, there are companies at which you can't simply install GNU versions of the tools to replace the brain-deaded system-supplied ones. (Try working in the IT department of a bank and you'll see what i mean.) Conventionally speaking, whitespace in filenames causes all sorts of problems with command-line tools. Not just with find/xargs, but all sorts of tools. In some complex cases, like embedding shell code within makefiles which themselves generate more shell code, properly quoting whitespace-containing strings is problematic. When a long-time Solaris user moves to Linux, his world opens up (in more ways than one) because the tools he's used to are [almost] all there but they get more powerful. When a long-time Linux user moves to non-Linux, Unix-like OSes, the world gets a lot smaller (and a lot of his shell scripts break). As some anonymous person once put it so well: "They say that moving from Windows to Unix is difficult. Sure, but moving from Unix to Windows is impossible!" -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
If people would always use -print0 the first time, or when filenames with spaces are expected, the world would not break as much. Of
If people use -print0 then they're writing unportable scripts. If you ever administer, e.g., a Solaris machine, you'll find out that all of the niceties of the GNU tools don't exist in non-GNU versions of those tools. e.g., -print0 and -0. Yes, there are companies at which you can't simply install GNU versions of the tools to replace the brain-deaded system-supplied ones. (Try working in the IT department of a bank and you'll see what i mean.)
Explains why Linux gets more important. All those unixes and BSDs look like they have not been updated in 10 years, some programs still don't have proper ANSI C, not to mention C99.
Conventionally speaking, whitespace in filenames causes all sorts of problems with command-line tools. Not just with find/xargs, but all sorts of tools. In some complex cases, like embedding shell code within makefiles which themselves generate more shell code, properly quoting whitespace-containing strings is problematic.
Which one looks better: Some funky artist - Some funky song.mp3 or Some_funky_artist_-_Some_funky_song.mp3 plus the former can properly be wordwrapped in graphical file managers if needed.
When a long-time Solaris user moves to Linux, his world opens up (in more ways than one) because the tools he's used to are [almost] all there but they get more powerful. When a long-time Linux user moves to non-Linux, Unix-like OSes, the world gets a lot smaller (and a lot of his shell scripts break). As some anonymous person once put it so well:
So what do we learn? Solaris is old and will eventually end up like all the other unixes. Jan Engelhardt --
On Thursday 28 September 2006 04:38, stephan beal wrote:
...
"They say that moving from Windows to Unix is difficult. Sure, but moving from Unix to Windows is impossible!"
True, but for the life-saving virtues of Cygwin: http://cygwin.com/ RRS
I tried it and work but only partially. I get error messages when the file/directory names contain white spaces. How can I make it work with these files too?
b) find . -type f -print0 | xargs -0 md5sum
-print0 uses a NULL character to separate filenames, intead of a newline, and -0 tells xargs to expect that as input.
Thanks again, it works now. IG ____________________________________________________________________________ MINTEGY 4.000 DB ÚJ, ÉPÜLŐ LAKÁS KÍNÁLATÁBÓL TÁJÉKOZÓDHAT! - Reális Ingatlaniroda http://www.realis.hu
On Wednesday 27 September 2006 08:33, Istvan Gabor wrote:
Hello all:
How can I use md5sum program recursively both for creating md5 cheksums and for checking?
md5deep http://md5deep.sourceforge.net/ http://md5deep.sourceforge.net/usage.html There's an rpm for md5deep as well, though I don't recall who packaged it. -- Christopher Shanahan
participants (7)
-
Christopher Shanahan -
Istvan Gabor -
Jan Engelhardt -
Leendert Meyer -
Randall R Schulz -
stephan beal -
suseuser04＠freemail.hu