Differences between sed on Mac OSX and other "standard" sed?

Question

I am having some issues in using an answer provided on this site for this question about a sed command to replace a blank line with two other lines of content, and it was brought up if the sed command on Mac OS (10.6.7 for me) is different. I don't think that it is, but was wondering if others on this site thought differently.

Answer 1

OS X currently comes with a FreeBSD sed from 2005. Most of the differences below also apply to other BSD sed versions.

OS X's sed uses -E for ERE and GNU sed uses -r. -E is an alias for -r in GNU sed (added in 4.2, not documented until 4.3). Newer versions of FreeBSD and NetBSD sed support both -E and -r. OpenBSD sed only supports -E.

-i '' works with OS X's sed but not GNU sed. -i works with GNU sed, recent versions of NetBSD, OpenBSD sed, but not OS X's sed. -i -e works with both but in the case of FreeBSD sed makes a backup of the original file with -e appended to the file name (and you need to pass no more than one expression to sed).

GNU sed interprets escape sequences like \s, \t, \n, \001, \x01, \w, and \b. OS X's sed and POSIX sed only interpret \n (but not in the replacement part of s).

GNU sed interprets \|, \+, and \? in BRE but OS X's sed and POSIX sed don't. \(, \), \{, and \} are POSIX BRE.

GNU sed allows omitting ; or a newline before } but OS X's sed doesn't.

i (insert), a (append), and c (change) have to be followed by a backslash and a newline in OS X's sed and POSIX sed but not in GNU sed. GNU sed adds a missing newline after the text inserted by i, a, or c but OS X's sed doesn't. For example sed 1ia is a GNU alternative to sed $'1i\\\na\n'.

For example printf a|sed -n p adds a newline in OS X's sed but not in GNU sed.

OS X's sed doesn't support the I (case-insensitive) or M (multi-line) modifiers. Newer versions of FreeBSD sed support I.

OS X's sed doesn't support -s (--separate), -u (--unbuffered), or -z (--null-data).

One BSD option that is not supported by GNU sed is -a, which makes w append to a file instead of truncating a file.

Examples of GNU sed commands that don't work with OS X's sed:

sed /pattern/,+2d # like `sed '/pattern/{N;N;d;}'`
sed -n 0~3p # like `awk NR%3==0`
sed /pattern/Q # like `awk '/pattern/{exit}1'` or `sed -n '/pattern/,$!p'`
sed 's/\b./\u&/g' # \u converts the next character to uppercase
sed 's/^./\l&/' # \l converts the next character to lowercase
sed -i '1ecat file_to_prepend' file # e executes a shell command
sed -n l0 # 0 disables wrapping

Answer 2

The behavior of shell utilities does differ in minor ways between unix variants. There are many unix variants, with a complex history. There are standardisation efforts such as the POSIX standard and its superset the Single UNIX specification. Most systems nowadays implement POSIX:2001, also known as the Single UNIX Specification version 3, with minor deviations and many extensions. The Single Unix specification is not a tutorial, but version 3 is readable if you already have an idea of what a command is doing. You can consult it to know if some feature is standard or an extension of a particular system.

A majority of unix users use Linux and haven't used any other variant. Linux comes with GNU utilities, which often have many extensions to the standard. So you'll find quite a lot of code out there that works on Linux but not on other unices, because it relies on those extensions.

Regarding sed, consult the sed Single Unix specification for the minimum that every system is supposed to support, the man page on your system for what your implementation supports, and the GNU sed manual for what most people out there use.

One of the nonstandard extensions in GNU sed is supporting multiple commands run together. For example, this GNU sed program prints all lines containing an a, but changes b into c first:

sed -ne '/a/ {s/b/c/g; p}'

{ and } are actually separate commands, so for full portability, you need to specify them either on separate lines (in a file) or in separate -e arguments (on the command line). The lack of a command separator after { and the use of ; as a command separator are common extensions. The lack of a command separator before } is a less common extension. This is standard-compliant:

sed -n -e '/a/ {' -e 's/b/c/g' -e p -e '}'

This is nonstandard but commonly accepted:

sed -ne '/a/ { s/b/c/g; p; }'

Another nonstandard but common extension is the use of \n to mean a newline in a s replacement text (the use in a regexp is standard). The portable method is to include backslash-newline in the sed script. Another common extension is \+, \? and \| in regexps to mean one or more, at most one and alternation; portable basic regular expressions have none of these. For example, the first command is a non-portable way of replacing contiguous sequences of whitespace by a newline; the second command is a standards-compliant equivalent.

sed -e 's/ \+/\n/'
sed -e 's/  */\
/'

Answer 3

The best way I have found to have the same script work on both Linux and Mac is to:

sed -i.bak -e 's/foo/bar/' -- "${TARGET}" &&
  rm -- "${TARGET}.bak"

Answer 4

This command

sed 's/123\(4\+\)5/\1/g'

that works on Linux, needs to be changed to

sed -E 's/123(4+)5/\1/g'

to work on my Mac.

So, on Mac you shouldn't escape brackets and star and plus signs. Also you need to add the -E flag.

Answer 5

Another difference is that with Mac/BSD sed, it can give an error: illegal byte sequence if you try to process a binary file with LANG or LC_CTYPE set to UTF-8. GNU sed won't give the error.

If you encounter that error on Mac/BSD, you can try one of the following:

LC_CTYPE=C sed ...
LC_ALL=C sed ...
LANG=C sed ...