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 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.
Of course. But that's a more sophisticated job.
This is a batch string replacement!
| > 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.
For this job? A simple s/old.domain/new.domain/? You _are_ joking, yes?
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
Disclaimer: Opinions expressed here are CORRECT, mine, and not PSLs or NMSUs..
- Larry Cunningham <[EMAIL PROTECTED]>
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
