On Fri, 22 Mar 2002, Cameron Simpson wrote:

> On 05:36 21 Mar 2002, David Kramer <[EMAIL PROTECTED]> wrote:
> | On Thu, 21 Mar 2002, Nick Wilson wrote:
> | > could someone please help me solve the following problem?
> | > I need to recursively find and replace a string in a whole bunch of dirs
> | > (a website). For example: 
> | > 
> | > change: http://my-testing-environment.com
> | > to:     http://www.the-real-website.com
> | > 
> | > I gues sed is the tool for this right?
> 
> Yes. Ignore the "perl is my only hammer" types.

 Ignore the "I don't know how to use perl properly" types :o)

> | Well, you can use sed, but using perl gives one big advantage; it lets you 
> | edit files in-place.
> 
> Yeah. Sort of. But actually a red herring.

 Not a red herring.  A very useful tool, and it also allows you to
supply real code as well as regular expressions ... which is more
often than you might think.  Also perl's regexps have a few wrinkles
beyond sed's regexps.

> Dude, fetch bsed:
> 
>       http://www.zip.com.au/~cs/scripts/bsed
> 
> and go:
> 
>       find dir -type f -print | xargs bsed 'sed-command'here'

 That's cool, I didn't know about that one.  I'll file that away for
the future.

> | Actually, it's making a copy first and then 
> | overwriting the original, but you don't have to deal with that anyway.  
> 
> Actually, no. This is the core reason I stay the hell away from perl's
> -i mode: it makes a fresh file with the modified output, then UNLINKS
> THE ORIGINAL AND MOVES THE NEW ONE IN ON TOP!

 Actually, it can make a copy first.  Supply a suffix after the -i
option, and it uses that (added to the original) to name the backup.

> The reasoning behind this is safety from "disc full" and avoiding the
> race if having an inconsistent file during the rewrite period). But the
> downside is that: it breaks any hard links you might have to the file and
> also it mangles the file ownerships and permissions, because what you end
> up with is a NEW file with default (umask) permissions and default owner
> (you).

 Yes, fair point, but the safety aspect is generally quite important
in some applications.

 I wonder if perl could be nade to do it differently ...

> Bsed doesn't do that. It makes a new, modified, copy and if that was
> ok, writes the copy back over the original. Preserving the file modes
> and links.

 And not giving you a backup ...

 I don't think for the application suggested (modifying a website) you
really want to risk not having a backup, and I can't think of many
people who would actually have a lot of hard linked copies in a web
site (cue a queue of people to tell me they do :o)

> Perl is overkill and cumbersome for a lot of simple edits that any sane
> person would normally use sed for. And thus bsed.

 For simple edits, yes.  Please let me assure you that when updating
several hundred or thousand files at once in circumstances that need
a bit more than a simple regexp (changing zone files on a nameserver
springs to mind, where you have to update serial numbers within the
files as you go) you really do need perl or its equivalent.

> Fetch, use, enjoy. Cheers,

 Will look at that ... sounds useful.  Please understand I'm not
against tools that do their job; I just think perl is the better
tool for this particular job.




_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to