> First (of many more) patch of cp_mv to getopt use. I'm using the most
> simplistic approach, just get getopt used, then worry about a cleaner
> option parsing style using getopt later.
>
> Marc
> Here is a patch so that tr can handle NULL characters as well. Give it
> a shot and let me know what you think. It is against the latest CVS
> version.
>
> In my tests, the following now works as expected.
>
> tr '\0' '\n'
>
> Later,
> Matt
>The attached patch adds the ability to parse the actual mode specifier in
>fbset. So now
>
> fbset -n 640x480-72
>
>Will actually work. I don't know if I've reinvented the wheel though...
-Erik
>
> The following patch allows ln -n to function like GNU. It also fixes a
> typo with my previous patch to add support for ln FILE DIRECTORY. And
> it removes some code that checks the maximum length of the filenames. I
> can't figure out why that code is necessary. Anyone know?
>
> Matt
- adds case-insensitive matching in sed s/// epxressions
- consolodates common regcomp code in grep & sed into bb_regcomp and put in
utility.c
- cleans up a bunch of cruft
There is some common code used by both sed & grep that should be put into
utility.c as per Mat Kraai's suggestions/patch on the mailing list.
Specifically, a common regex_compile() and a regex_subst() function need to be
made.
Howdy,
Bug #1006 reports that
ln -s /tmp/foo .
does not work correctly. In fact, it appears that any instantiation of
ln -s FILE... DIRECTORY
does not work. The following patch adds support for this form, which
then fixes the particular instance noted in the bug report.
In the process, I needed the basename function. This appears in the
string.h provided by glibc, but not uC-libc. So I wrote my own to go in
utility.c, called get_last_path_component. I also modified the basename
utility to use this function.
At some point it might be desirous to use the basename from the library
if it exists, and otherwise compile our own. But I don't know how to do
this.
Matt
GNU tr complains on the following:
$ tr a ''
tr: when not truncating set1, string2 must be non-empty
BusyBox tr does not complain:
$ tr a ''
a
^D
0
It should result in an error, not in some spurious output. The attached
patch generates an error.
Matt
However, the case of
grep foo$ file
didn't work, due to a problem with the flags used in regular expression
compilation. The attached patch fixes this problem.
---patch-------
Index: grep.c
===================================================================
RCS file: /var/cvs/busybox/grep.c,v
retrieving revision 1.30
diff -u -r1.30 grep.c
--- grep.c 2000/07/04 22:17:01 1.30
+++ grep.c 2000/07/10 08:57:04
@@ -141,8 +141,10 @@
if (argv[optind] == NULL)
usage(grep_usage);
- /* compile the regular expression */
- reflags = REG_NOSUB; /* we're not going to mess with sub-expressions
*/
+ /* compile the regular expression
+ * we're not going to mess with sub-expressions, and we need to
+ * treat newlines right. */
+ reflags = REG_NOSUB | REG_NEWLINE;
if (ignore_case)
reflags |= REG_ICASE;
if ((ret = regcomp(®ex, argv[optind], reflags)) != 0) {
---patch-------
Thanks, Matt, it works great.
