Syntax Error on ssed for Regex Subroutine definitions

tl;dr: Forget about ssed. Use perl.

Here's why:

1. ssed is abandonware. It was last updated in Oct 2005. Its home page on sourceforge is gone (and I can't find any replacement on github or gitlab).

   Various distros have kept on packaging it and making minor patches (mostly packaging related or to ensure it actually compiles with modern libraries & tools), but the program itself hasn't been updated for 20 years.

2. ssed doesn't use perl regular expressions, it uses Perl Compatible Regular Expressions (PCRE) which are based on and very similar to perl REs but have some significant differences.

3. It doesn't even use a recent version of PCRE. The ssed source code bundles an ancient version of PCRE from August 2000. It can't use any perlre features implemented since around that time, so you'll have to find and install an ancient copy of the perlre and related man pages if you want documentation (but don't forget that ancient PCRE wasn't 100% compatible with ancient perlre either).

4. If you can install and use an ancient abandoned software package from 20 years ago to do perlish sed search & replace operations, there's no reason you can't use perl for the same tasks (but note that anything that uses other sed language features like branching, conditionals, hold space, append, insert, delete, etc will have to be re-written to use perl equivalents. This isn't terribly difficult. If all you use ssed for is s/// operations then they'll work without a problem).

   If you have lots of scripts which use ssed and don't want to have to edit them, write a wrapper script (e.g. /usr/local/bin/ssed) that first processes all options to:

   • Remove or replace any ssed options that are incompatible with perl (-l/--line-length, -r/--regexp-extended, -R/--regexp-perl, --posix, -s/--separate and -u/--unbuffered need attention).

     • -r, -R, and --posix aren't needed and can just be removed from the args

     • -l is incompatible with perl's -l option (which turns on automatic handling of line-endings, e.g. \n). Either remove it from the args or get used to it having the perl meaning. If you need to limit the line length, then pipe the output into fmt or fold or par to re-format it. Or add a rule like s/(^.{80}).*/$1/; or $_ = substr($_,0,79); to remove excess characters from each input line.

     • -u is unlikely to be needed. If you really need unbuffered output for some reason, add something like BEGIN { $| = 1 }; to the beginning of your ssed-but-really-perl script. See $| in perldoc perlvar

     • -s is the only ssed option that presents any difficulty. Perl's -n and -p options treat all input as a single continuous stream unless you're using -i (in which case, it edits each file individually).

       If you need to emulate --separate for other purposes, it's probably easiest to just write a perl one-liner without using either -n or -p but with its own while (<<>>) { ... } loop and a continue { if eof { do something here }; ... } block for that loop.

       There are many possible uses for and things you can do in a continue block, but the main reason I ever use one is to reset perl's input line counter variable ($. - see $. in perldoc perlvar) after each file by close-ing the current file when it reaches eof, e.g. while (<<>>) { ... } continue { close ARGV if eof };. See perldoc -f continue

   • Execute perl with either -n or -p depending on how ssed was called, and pass all other args on to perl.

I dont know a lot about ssed I would definitely use Perl if it were available. But it looks like ssed is having a problem with named capture groups. sed also does not support named capture groups and I cant find any documentation online for ssed. It looks like ssed might be going away unless you can find a used book or something.

I was able to get it working without capture groups by changing the parenthesis around a bit.

$ ssed -R 's/Angie ((Apple)|(Banana)|(Tomato)|(Peach))/deleted/g' angie.fruits.txt

deleted
deleted
deleted
deleted
Angie Onion

Maybe that can help. But the future might be a bit bleak for ssed. With no documentation online, you cant learn it if you wanted to. I dont even see any books on Amazon. It might be a good idea to start looking for replacements, of which I wholeheartedly recommend Perl. Regular sed is probably not going anywhere though.

If you have a problem you cant solve easily with sed or awk the next step is definitely Perl. IMO Perl is also superior to Python. Especially for these types of problems.