Re: sed regexp help
On Fri, 22 Mar 2002, Cameron Simpson wrote: > On 01:44 22 Mar 2002, Bill Crawford <[EMAIL PROTECTED]> wrote: > | > | > 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) I really did mean the smiley. I do succumb to the "perl is my hammer and everything looks like a nail" quite regularly. I like the ability to do almost anything with it ... it's seductive. > I use a LOT of perl. But for simple tasks it is still overkill and cumbersome. Yes, but carpenters rarely carry toffee hammers :o) I'm not sure about the "cumbersome" part; it was designed for systems administration and I think it does that job well. However, I had never really given consideration to the "hard link" problem. We'll skip the argument about whether one should really be doing inplace edits on them :o) > Sure, but many jobs, like the source mail item's job, require NONE of that. > Many many jobs! OK, conceded. I'm not going to stop using perl, but I will watch out for hard links now (it's not usually a problem, but I really hadn't ever discovered that; if I'd thought about it, I probably would have assumed it did the right thing, so thanks for the heads-up). Anyway, time for this thread to die, I think ;o) ___ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
Re: sed regexp help
On 01:44 22 Mar 2002, Bill Crawford <[EMAIL PROTECTED]> wrote: | > | > 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) I think you might get a nasty shock if you run wc on the perl scripts in my scripts dir: http://www.zip.com.au/~cs/scripts and their supporting modules: http://www.zip.com.au/~cs/scripts/cs/ I use a LOT of perl. But for simple tasks it is still overkill and cumbersome. | > | 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. Sure, but many jobs, like the source mail item's job, require NONE of that. Many many jobs! | > Dude, fetch bsed: | > http://www.zip.com.au/~cs/scripts/bsed | > and go: | > find dir -type f -print | xargs bsed 'sed-command'here' Or for short lists of files: bsed 'sed-command-here' *.html which is my more common invocation. | That's cool, I didn't know about that one. I'll file that away for | the future. I use it much! And I've used it for exactly the job requested, as it happens. | > | 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. And _still_ buggers the original file. it's not a matter of having a backup or not. It's a matter of not damaging file attributes. It's a policy thing. My permissions and hard linkage expresses part of my file access and maintence policy. A tool to edit a file should NOT screw that up. And the widespread "copy+hack, rename copy-to-original" misimplementation of "edit in place" that perl and several other things use DOES screw policy over royally. It's more than merely rude. | > 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. For a lot of things it is enough to have a careful tool (like bsed) and some error messages. Bsed strives quite hard to avoid trouble, leaving original unchanged on things like disc full. There are safe ways to do all this. Example: - copy original (abort everything if copy fails) ok, now we have backup - rewrite original with mods - if rewrite fails, rewrite with copy - if that fails, report error and recite location of copy - if everything worked, discard copy (unless -ibak mode used) Very easy and doesn't presume the programs knows more than the author of the files. | I wonder if perl could be nade to do it differently ... Go hack it. See if they accept your patches. Remember that nobody managed to get them to turn off "magic open", even switchably, even after a huge flamewar. This change is of less benefit than that one. | > 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 ... Bsed will do backups too. | I don't think for the application suggested (modifying a website) you | really want to risk not having a backup, Anyone sane will have this stuff in CVS or some other revision control system anyway. Run converter. If no troubles, commit. (Of course, cvs screws your files over the same way as perl. Bad karma.) | 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) In a web site, maybe not. But I have (well, had - use of CVS has forced another, more cumbersome, approach on me for some things) plenty of uses for hard linked files. Typically scripts with switchable behaviour based on $0 (eg png2jpg, aka tif2jpg, aka ...). | > 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 mo
Re: sed regexp help
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
Re: sed regexp help
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. | > I've read the man page but I'm | > somewhat intimidated by it :-) | | 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. Dude, fetch bsed: http://www.zip.com.au/~cs/scripts/bsed and go: find dir -type f -print | xargs bsed 'sed-command'here' | 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! 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). 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. Perl is overkill and cumbersome for a lot of simple edits that any sane person would normally use sed for. And thus bsed. Fetch, use, enjoy. Cheers, -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ There are old climbers, and there are bold climbers; but there are no old bold climbers. ___ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
Re: sed regexp help
On Thu, 21 Mar 2002, Nick Wilson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everyone, > 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? I've read the man page but I'm > somewhat intimidated by it :-) No, for this perl is the "best" tool ... find . -type f | xargs perl -npi.orig -e 's#old#new#g;' It's a lot more efficient as it can process multiple files per forked process, and you actually put code in the expression there (the -e part) that is applied to every line as the file is read in, and then is written out again. ___ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
