Age | Commit message (Collapse) | Author |
|
It's legal for a system call to set non-zero errno and return a good
status. The caller (grep) should check return status first.
Test: 2000 loops of greping 1000+ lines each loop
Signed-off-by: Robin Hsu <robinhsu@google.com>
Change-Id: I55f7cd5d8a6289c5e8a21ed3057e995a75b9b4fa
|
|
|
|
|
|
A tar file created by toybox tar with values large enough to need
base-256 rather than ASCII octal caused a tar reader to crash, and
caused GNU tar to complain.
I note from the docs at
https://github.com/libarchive/libarchive/blob/master/libarchive/tar.5#L326
that they imply that only the top *bit* should be set to indicate this
format, not the whole top byte, to give a 95-bit or 63-bit field. But I
don't think we can hit that in practice?
Bug: http://issuetracker.google.com/181683612
|
|
|
|
|
|
|
|
And fix one test for NUL that should be a length test for -z support
|
|
On Linux, struct statvfs' f_bsize and f_frsize seem to be
interchangeable. On macOS, they're wildly different. f_bsize is the
"preferred length of I/O requests for files on this file system"
(corresponding to statfs::f_iosize), and f_frsize is the "size in
bytes of the minimum unit of allocation on this file system"
(corresponding to statfs::f_bsize. POSIX appears to say nothing
about the interpretation of these fields, but man7.org's statvfs(2)
page is quite clear that statvfs::f_blocks, for example, is in units
of f_frsize, not f_bsize.
This is the only place in the tree where we use statvfs::f_bsize
(other than the stat(1) output that's supposed to be f_bsize and
that has a corresponding f_frsize dual anyway.
I've removed the Apple-specific #define f_frsize in portability.h
because that seems to have been from my previous attempt to understand
what was going on here. The output of the relevant stat(1) fields
on macOS are the same before/after this patch.
This makes toybox df's output match the system's df on a MacBook
Pro running macOS 11.2.1.
Tested on a Raspberry Pi 400 running Linux too, where I see no
change in the output before/after this patch.
|
|
|
|
|
|
more recently than the resulting mount point.
|
|
|
|
|
|
|
|
|
|
Requested by aheirman on github: uses access(X_OK) which checks access
control lists as well as permissions, and that _we_ can access them
(u+x could be owned by a different user)...
|
|
|
|
|
|
|
|
Also reorder the --help output to separate the "whats" from the "hows",
as with other commands that have lots of options, and add units to the
help too.
|
|
by not writing as much payload as the header promised.
|
|
|
|
Ethan Sommer noticed that chown is using chgrp_main() due to OLDTOY, so
the wrapper function isn't needed.
|
|
|
|
|
|
Instead of unlink() && check errno, call lstat() explicitly to check
file existence if "-f" is specified.
There is a regression when if the path to be removed is nonexistence
and within a readonly filesystem, then unlink() could set the EROFS
errno instead of ENOENT, thus screwing up the output of `rm`.
|
|
or else singlemake enables it for all commands. (I was trying to
move it out of the command namespace, but it's not a global config
option either...)
|
|
|
|
|
|
and address TODO where -z was still splitting patterns on \n
|
|
no argument returns NULL same as --opt without =
|
|
The kernel will do this for us on both Linux and macOS, but error
messages are a bit misleading if we don't do it ourselves --- it
can look as if the failure is because of the type bits.
|
|
configurable.
|
|
The GNU tar manual, when talking about the `tar --transform` option that I
need to implement, describes the 'x' flag by saying "regexp is an extended
regular expression (see section 'Extended regular expressions' in GNU sed)".
Only it turns out that even the latest GNU sed doesn't actually have
that flag. It's unique to `tar --transform`. That link is just telling
you that the sed manual will explain extended regular expressions, not
that GNU sed also supports the 'x' flag.
So I don't know whether we want this in toybox sed after all. (It made
sense that sed would have such a flag, but no sed that I know of
actually does.)
|
|
|
|
|
|
tests to catch this. While there add -k to test sticky bit.
|
|
|
|
|
|
|
|
I didn't know until implementing this that --iso is actually called
--iso-8601 and that GNU date will actually accept any prefix. --iso-8
works fine too. I've assumed that --iso (that I always used) and
--iso-8601 (as given in the documentation) are the only two that matter.
|
|
|
|
I promised months ago I'd fix this, and there was a (not visible to the
public but filed by a member of the public) bug filed against Android in
the meantime, but judged No Security Impact because "toybox is not a
security boundary". Anyway, it seemed high time I learned about fuzzing
command-line tools with AFL++, so here we are.
With these patches (and starting from the ELF files in test/files/elf),
toybox file survived ~24hours against AFL++. Amusingly it corrupted the
ELF files hard enough that it also managed to find a bug in the code
for MS-DOS executables, which is the motivation for the final hunk in
this patch.
Bug: http://b/159065007
Test: ~/AFLplusplus/afl-fuzz -i tests/files/elf -o fuzz-out -- ./file @@
|
|
|
|
Android is introducing a new binary XML format that is a drop-in
replacement for many existing .xml files written by system_server.
Since engineers may be surprised when encountering this new format,
add it to the "file" tool to aid identification in the field.
|
|
One reason to use toybox on the host is to get the same behavior across
Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one
area where that doesn't quite work is that toybox uses the libc regular
expression implementation. That's fine, and mostly what users want, but
those folks trying to get the exact same behavior everywhere might want
to switch in a known regex implementation (bionic's NetBSD regex
implementation, say) for increased consistency.
That actually works pretty well, but portability.h has an #ifndef test
for REG_STARTEND before including <regex.h> that gets in the way. To
make up for that, this patch removes the unnecessary #include <regex.h>
from grep.c itself.
|
|
|
|
The comma thing turned into an internationalization can of worms,
don't go there. Keep the "show megabytes on systems with >10G"
logic which includes not showing 0.0 for single digit values.
|
|
|