sed strangeness

[Jon McDermott]

I have a series of sed commands embedded deep in a shell script that is giving me fits. When the sed command runs, I get the following:

xena:/home/mcdermot/71ora> sed -f sed_script_bad tt.tmp
sed: Function 3982s/.*/ STORAGE ( INITIAL 1424 K NEXT 285 K PCTINCREASE 20 )/ cannot be parsed.

In this example, the sed command it is choking on is:

3982s/.*/ STORAGE ( INITIAL 1424 K NEXT 285 K PCTINCREASE 20 )/


To me this appears to be a valid sed command. Even more fun, this "spot" at which sed says it cannot parse a command line varies depending on the specific data in the sed command script.

In this case, sed chokes on the 44th line of a 57 line command file. But I can edit the command script and by playing around with the spaces in any of the preceeding command lines, the sed command runs just fine.

It doesn't matter what the input file is; I've tried a very short input file (as opposed to the long input file that is expected) and I get the same results.

One more variable - I've tried the same sed command on an HP-UX 10.20 machine and an HP-UX 11.0 machine - the commands fails on only the HP-UX 11.0 machine.

Any ideas? I'll post the input command file if anyone requests it.

Thanks,
Jon

[Rick Garland]

I have encountered multiple "strangeness" as well in using sed. I have the issues to disappear in using GNU sed. There is a difference except I have not researched it fully enough to list those differences.

[Jon McDermott]

Thanks for the response. I'm hoping I don't have to go the route to gnu sed, only because the software I'm working on is what we send (actually, sell) to our customers, and if the problem is solved with gsed, I'll have to require they install gsed. I'd rather not add anyother required software package for customers if I don't have to.

We're going to apply the latest sed cumulative patch and libc cumulative patch tonight and see if that fixes the problem.

Any other ideas would be welcome too.

[Bruce Regittko_1]

Hi,

If you can't get sed to act right, you may have to consider using perl or awk.

--Bruce

[Dan Hetzel · Accepted solution]

Hi Jon,

As you said that 'sed' was behaving differently on 10.20 and 11.0, this points me to patch PHCO_22760 [sed(1) cumulative patch].
It's only been posted on 4th december 2000.

here is the link:
http://europe-support.external.hp.com/wpsl/bin/doc.pl/sid=5a5df3e70446f9258a/screen=wpslCandidateList

Best regards,

Dan

[Kevin Ernst]

Did you try separating the address/pattern from the command (in this case 's///') by a space? That doesn't seem to make a difference on a 10.20 system, but we don't have an 11.x system I could test on.

Maybe it's being picky about having a space between the pattern and command? You might also try addressing the line as '3982,3982' just for variety

[Jon McDermott]

Thanks for all your responses. We applied PHCO_22800 (sed cumulative patch) and PHCO_22760 (libc cumulative patch) and I re-tested the problematic sed command and it now works.

I will do a little more testing but I think we can consider this problem solved.

Regards,
Jon