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.
> 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 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
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
escape seq. code from tr and echo into utility.c. Fix thanks to
Matt Kraai <kraai@alumni.carnegiemellon.edu>.
* This should close Bug #1015. Please test.
-Erik
utility.c and replaced them with get_line_from_file() from the new grep.c.
Also changed declaration in internal.h and replaced instances of
cstring_lineFromFile() in dc.c and sort.c with get_line_from_file(). Tested
them and they worked fine.
