Use warn()/err() instead of sed's homegrown warning()/error() for
things other than parser problems. The warning()/error() functions
display the file and line number in addition to the error message.
This also removes of the COMPILE/FATAL argument to error() since
now all calls to error() are for compilation/parsing issues.
OK op@ espie@
the "b" and "t" commands with a label, and for compatibility with
GNU sed, also accept ";" followed by another command after "b"
and "t" commands without a label: branch to the end of the script
instead of erroring out. Parsing is unchanged.
Missing feature reported by Lars dot Nooden at gmail dot com on bugs@.
OK martijn@ millert@
When the opening square bracket ('[') is abused as the delimiter, the regular
expression contains a bracket expression, and the bracket expression contains
another opening square bracket (sick! - i mean, sic!), then do not require
escaping that innermost bracket and treat a preceding backslash as a literal
backslash character, in accordance with POSIX:
$ printf 'x[x\\x\n' | sed 's[\[[][R[g'
xRx\x
$ printf 'x[x\\x\n' | sed 's[\[\[][R[g'
xRxRx
While here, also make the implementation more readable and insert
some comments.
Joint work with martijn@ (started during g2k18) and OK martijn@.
and then including '[' in the regular expression by prepending a backslash
to it, remove the backslash before feeding the RE to the RE engine, just
like we already do it for other special characters like .^$*+?{(|.
This makes sed 's[\[xy][...[' treat the xy thingy as a char class.
Joint work with martijn@, OK guenther@ martijn@
- When 'n' is used as a delimiter escaping 'n' will remain a newline
instead of becoming a 'n' character. This is how POSIX specifies how this
should work. Other implementations tested also do this wrong.
- '[' and maybe other characters are not special during the parsing of the
y command and don't need to be matched or treated special in any way.
- POSIX specifies that a backslash followed by anything other than the
delimiter, 'n', and another backslash, as well as repeating characters in
string1 are unspecified. Since the various implementations handle these
situations in opposing ways choose to error out on them to prevent people
falling into the pitfall of expecting identical behaviour on various
implementations.
Inspired by the sed.1 patch by kshe59 <at> zoho <dot> eu
Feedback and OK millert@
Manpage bits OK jmc@
do for several years.
While here make corresponding error message for missing read and write file
consistent between commands/flag, and shrink the the code of the w flag of
the s command by making it use the same code as the w command.
Prompted by a larger diff by kshe59 <at> zoho <dot> eu
OK millert@
the 'w' and 'r' functions and the 'w' flag to the 's' function.
If non of the above is used and input is being read from stdin, we drop
all the way down to stdio!
Original inspiration by benno@.
OK millert@
of the y (translate) command.
"If a backslash character is immediately followed by a backslash
character in string1 or string2, the two backslash characters shall
be counted as a single literal backslash character"
From FreeBSD; ok millert@ halex@
unmaintainable). these days, people use source. these id's do not provide
any benefit, and do hurt the small install media
(the 33,000 line diff is essentially mechanical)
ok with the idea millert, ok dms
syntax. The -E flag is compatible with the other BSDs and OSX. -r is
also provided as an alias for compatibility with GNU sed.
feedback from jmc@ and millert@
ok millert@ pyr@ henning@ marco@
apparently an extension, but without it you cannot express longer labelled
sed scripts as one-liners. noted by seb@todesplanet.de apr 2002. also
noted by cerille lefevre a bit later. fixed by otto and myself, tested
on tree builds to be careful
