the -V (version) flag from busybox sed. It is unnecessary because sed is not a
standalone and should therefore be independently reporting a version number.
Moreover, it is extra code that we just don't need.
extraneous logic loop that existed only for the purpose of the special case of
only one file. I replaced it with a variable to keep track of the number of
files read.
(\1, \2...\9). This touched a lot of places in this file and I added a new
function 'print_subst_w_backrefs' in order to keep 'do_subst_command' a
little more tidy.
* I tested this good 'n hard, but will always appreciate more testing from
other, willing folks.
- Noticed that the index_of_next_unescaped_slash was subtly wrong so I
changed both the functionality and behavior (it used to skip over the first
char in the string you passed it, assuming it was a leading '/'--this
assumption is no longer made) this necessitated changing the lines that
call this function just slightly.
now implemented... So now busybox shell can do cool stuff like:
/home/andersen/CVS/busybox # echo foo `wc README` bar
foo 71 422 2951 README bar
I love writing cool new features.... Muhahahaha... (I think this is
leaking a little bit of memory every time it expands a backtick process,
so I still needs to do a bit of cleanup...)
-Erik
- add_cmd_str: segv's were being generated if there was a '# comment' line
(and probably other kinds of lines, too) that was not followed by a
semi-colon or whitespace
- parse_edit_cmd: was returning a wrong number (too low) for the index; it
was not accounting for backslashes eaten, for the fact that we start at the
3rd index in the string, or for the fact that we add an extra newline.
- parse_cmd_str: was returning a wrong number (again, too low) for the index
in the case of single-letter commands (p,d). There was some
over-compensation for this in the 'return' stmt at the end which also
needed some help.
- load_cmd_file: was not eating trailing newlines off the line read from the
command file. This had the deleterious effect of printing an extra newlines
after text displayed from edit (i,a,c) commands.
- Obsoleted the trim_str function (#if 0'ed out -- maybedelete later) in
favor of strrspn.
- Obsoleted the strrspn function (#if 0'ed out as well) as soon as I
discovered that it wasn't needed either.
- Fixed a subtle bug in parse_subst_cmd where it would choke with an error if
there was any trailing space after the s/match/replace/ expression.
to accomodate a trailing '\n'ewline that I append to it later one. This is
only necessary for the case of one inserted, appended, or changed line, but
it's still necessary.
