If you want a sed with perl-style regular expressions, it seems that there are two ways to do it:

ssed -R
perl -pe

Is there any reason to prefer one tool over the other for this purpose? They both support the -i flag. I assume they use the same perl regular expression library, and would therefore probably have similar performance and identical features and bugs. It seems pretty uncommon for perl not to be installed on a modern unix machine.

  • 3
    ssed threw me off-guard, first time I'm hearing of it. It's not installed by default in common Linux distro, whereas perl often is. And ssed uses PCRE, not Perl's regex engine, so they may have some differences. – muru Nov 10 '15 at 20:12
  • related: unix.stackexchange.com/questions/110875/… So maybe you can use perl's modifiers if you use perl, but not if you use ssed. – Ben Crowell Nov 11 '15 at 20:44

ssed is much smaller binary than perl. /usr/bin/ssed is 123K with PCRE linked statically. /usr/bin/perl is 1.7M, and that's not including any of the standard modules that get installed with it.

ssed could fit on a tiny distro, or a rescue / installer ISO, whereas perl might not. It's hard to see the point, though, because PCRE is mostly just a convenience - without too much extra work, basic or extended regex in ordinary sed can do most of what PCRE does....and that would save another 123K of space.

Of lesser importance, ssed is also probably faster than perl, at least in startup overhead. Compiling a perl script isn't exactly fast. This is probably only significant in shell scripts with for/while loops that repeatedly call ssed or perl.

| improve this answer | |
  • hmmm... your priorities are different than mine. i dont personally much mind the 1.5mb of space nearly as much as i do the few nanoseconds of additional exec time per call. but, for that matter, scripts that exec other programs in the body of a loop are almost always awful anyway: every program has a builtin loop all its own, and a shell script which prefers its own loop to a child process's loop is not using that child process effectively. but the answer is valid and good all the same. – mikeserv Nov 10 '15 at 21:24
  • They're not my priorities, i don't care much about either issue. but space may be very important for a tiny distro or installer cd. i have both ssed and perl (and lots of perl modules) installed on my systems. A few nanoseconds or even micro or milliseconds are irrelevant in a shell script except in a loop....and shells scripts execing other programs in a loop is 100% perfectly normal, not inherently 'awful'. not all programs called by shell scripts have loops - basename, for example doesn't have a loop. – cas Nov 10 '15 at 21:30
  • basename doesn't make any sense in a shell script, but it is a valid point. i disagree about time - concurrent processes chained together in a shell pipeline all working a single stream is almost always the correct way to do a thing. execing other programs in a shell loop when the other thing might be done - which is usually how that works out - makes a shell script awful. – mikeserv Nov 10 '15 at 21:31
  • huh? basename is often used in shell scripts and in shell loops. Have you never done something like: for f in * ; do bn=$(basename "$f" .txt) ; sed -e '...' "$f" > "$bn.out" ; done ? there are better ways of doing that in bash or ksh or zsh, but they aren't sh. anyway, basename was merely an example. there are many other programs called from shell loops that don't have loops themselves. – cas Nov 10 '15 at 21:39
  • different problems require different solutions/tools. you can't just use a hammer for everything. – cas Nov 10 '15 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.