making same change to *lots* of files, *without* date changed

[David Combs]

Alternatively, you can use the shell script provided by Tintin.
Personally, that's what I would have done, but you asked on a Perl
group.

Yeah, neat script!

I've tried it, and it seems to work just fine!

David

 

[David Combs]

What is your point?

Sinan

Good question -- turns out that stuffed a whole lot more
into that post than I intended to. WAY more.

Sorry for having you all look through all that stuff;
shouldn't have been there. :-(


David

 

[David Combs]

....

UNTESTED:

perl -MFile::Find -e'find sub {
my ( $atime, $mtime ) = ( stat )[ 8, 9 ];
local ( @ARGV, $^I ) = $_;
s!/home!/myhome!g while <>;
close ARGV;
utime $atime, $mtime, $_;
}, "."'

Thanks, John!

David

 

[David Combs]

One other minor point - if your filenames contain "goofy" characters it
can confuse the shell. Filenames can contain "&" and ">" and
whitespace and linefeeds (really!) and all sorts of other things that
are meaningful in shell commands.

It's a possible security risk also. If you have a file named "rm -rf
/&" (or a hax0r is able to create such a file) then you might regret
running this script.

I'm (perpetually) new at this stuff -- perhaps you could please
lay that out in a bit more detail?

Like, how does a filename get "executed" or "evaled" in that script?

(Looks like it's something much worth understanding!)

Thanks,

David

 

[David Combs]

Only a minor point - if you have a "gillion" files, you may find that
the "*.sh" overflows your shell's command buffer, especially if the
filenames are long (depending on your OS).

Well, my egrep found *lots* of *lines* -- but then when I
looked at just the file-*names*, it wasn't so bad.

(If it did turn out to be "a gillion", then I guess that
xargs would make it ok?)

David

 

[David Combs]

Not all combinations of OS/FS/mount options/phase of moon allow you to
back-date files. So test your program out on test files on the same
mount-point your real files, otherwise you may permently lose your date
information if something goes wrong. (Or backup your files in
data-preserving way before doing anything)


Xho

Thanks for the warning. Will try to be alert to it.

David

 

[Joe Smith]

One other minor point - if your filenames contain "goofy" characters it
can confuse the shell. Filenames can contain "&" and ">" and
whitespace and linefeeds (really!) and all sorts of other things that
are meaningful in shell commands.

It's a possible security risk also. If you have a file named "rm -rf
/&" (or a hax0r is able to create such a file) then you might regret
running this script.

If you modify the script so that it can handle file names with
embedded spaces, that will take care of most of the metacharacters.

#!/bin/sh
for file in *.sh; do
perl -pe 's:/home:/myhome:g' "$file" >"$file.new" && \
touch -r "$file" "$file.new" && mv "$file.new" "$file"
done

-Joe

 

[usenet]

I'm (perpetually) new at this stuff -- perhaps you could please
lay that out in a bit more detail?

There's a command that says:
$file.new && mv $file.new $file

Suppose you had a file on your system named "rm -rf /&". A copy of
that file gets created named "rm -rf /&.new" When you do the test, it
becomes:
rm -rf /&.new && mv rm -rf /&.new rm -rf /&

The "&" tells the shell to take the preceeding command and run it in
the background. So the shell sees up to the first "&" and runs
everything in front of it. oops. the part behind the first ampersand
is still a valid shell command, but won't execute unless you happen to
have a file named ".new"