| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The maximum unicode code point is 0x10ffff which is 21 bits.
|
|
|
|
|
|
This patch does two things:
1. Enable line buffering for echo and yes. I found this through test
flakiness from the toybox xargs tests running in CI on devices where
"echo" is provided by toybox. For `echo y`, GNU echo does one write
of "y\n" but toybox echo was doing two writes, which makes it more
likely (4% on the heavily-loaded CI machines) for writes from the two
processes to be interleaved.
2. Fix line buffering on glibc if you're calling `toybox foo` rather
than `foo`. Otherwise we come through once and switch to unbuffered
mode, then again and switch to line buffered mode --- which doesn't
seem to actually work in glibc unless you specify a buffer (so
passing toybuf and sizeof(toybuf) works, but NULL and 0 doesn't).
I hit the second issue trying to reproduce the first issue on the desktop
rather than on Android.
(If you're scratching your head wondering "why yes(1) too, not just
echo(1)?", that represents a blind alley I went down when I mistook
which tool was in use. It seemed like the same principle should apply,
and it matches what other implementations do.)
|
|
|
|
When using -t to inspect an archive, cpio would try to set the owner of
any symlink in the archive, even though the symlink wasn't created by
the command previously.
This would lead to two results, either the command fails with a "No such
file or directory" message when trying to lchown() the symlink path, or
an existing file, with the name of the symlink, is lchown()-ed.
Guard the lchown() function call with a "if (!FLAG(t))" block, and add
regression test for this.
|
|
|
|
|
|
|
|
|
|
|
|
I broke this when I added the masking out of the S_IFMT bits for macOS,
because string_to_mode needs the full mode with those extra bits,
specifically so that it can recognize directories for +X to work.
I've duplicated chtest rather than change chtest to explicitly set the
modes to 000 before running the given chmod command because I didn't
want to touch *all* the tests and obscure the addition of just one.
|
|
across one of the issues I forgot to fix. Added a couple comments and
renamed a variable to try to clarify the code while I was there.
|
|
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.)
|
|
|
