in reply to question on sed

Why, oh why are you calling sed? Perl has very good regular expression support of its own:

open(IN, '<', $File1) or die $!;
open(OUT, '>', $Replace_html) or die $!;

while(my $line = <IN>) {
    $line =~ s/$c/$b/g;
    print OUT $line;
}

close(IN);
close(OUT);

[download]

Might be a little longer, but it doesn't rely on an external program. Plus it uses Perl's regular expressions, which are far and away better than sed in almost any way you can think of.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: question on sed
by Anonymous Monk on May 15, 2003 at 16:20 UTC
    could if possible tell me why u are using < and > when defining the files, also i ran the code u gave me , i still am not getting output in the output file , could it be coz $c and $b both have "/" in them
[reply]

      The version above uses the three-element form of open() (available in perl 5.6.0 and later), which is a bit safer than the two-element form. open(FH, '<', $filename) is the same as open(FH, "<$filename"). The problem is that $filename could have a '<' at the beginning, thus changing the meaning of the open(). The three-element form avoids this problem.

      And yes, $c and $b need to have special regex characters escaped. (As broquaint said, variables like $c and $b have special meanings and should be avoided, but let's ignore that for the moment). If '/' is your only problem character, you can use the 'choose your own quotes' feature of Perl's regexen, such as s!$c!$b!g. In this case, the regex substitution will use '!' as a delimiter instead of '/'.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]

        Unless you're building the patterns in strings to be eval'd, you don't need to escape the slashes.

        In the original example, a sed command was being built, so $b and $c were interpolated by the shell or before the shell saw it, not by sed. Thus, the first thing sed sees has already been interpolated, which causes problems if the $b and $c had the separators in them.

        Your example in Perl should be fine, even if the $b and $c had slashes in them. The qq-like interpolations of the pattern and replacement arguments are done after the compiler has already parsed the s/// operator and gathered the arguments.

        It's still a good idea to escape things in the patterns, s/\Q$b/$c/ or $b = quotemeta $b, but that's to avoid problems with regex special characters, not the separators in the s/// operator. 

        % perl
$raw = 'this/is/a/test';
$b = 'is/a';
$c = 'was/a';
$raw =~ s/$b/$c/g;
print $raw, $/;        # this/was/a/test

        [download]

        --
        [ e d @ h a l l e y . c c ]

[reply]
[d/l]
[select]
[reply]

In Section Seekers of Perl Wisdom