| Age | Commit message (Collapse) | Author |
|---|
|
9ca15f063b am: b6ece7f09c
Original change: undetermined
Change-Id: I27f8d8a09d0064141406ad0df5e15739da021819
|
|
9ca15f063b
Original change: undetermined
Change-Id: I7006965da127beb7fd4cef3467756a178753c25b
|
|
Original change: undetermined
Change-Id: Ib6a5e5e665dea1d1dacdbb81e5d902ed6e4a4418
|
|
Change-Id: I273fcdf4aab46a5cdd803de661b80aa7c5b01dbb
|
|
|
|
|
|
|
|
I don't see the need for the separate buffer, and just using dprintf()
directly is less code. The only downside really is having to get the
right number of `%c`s in your format string.
|
|
|
|
1ee3b5cac0 am: de1cff1a5c
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1690088
Change-Id: Ie0ca28e8c897792eae60fb707fcdfde75be8da1e
|
|
1ee3b5cac0
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1690088
Change-Id: Ie8c8c57abe94f8172928d07cd77487b957a7ff1b
|
|
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1690088
Change-Id: Ifc95e0a5fa6d65f79ee93a3b19b13704628e3ccd
|
|
Change-Id: I99d6055803bd26e01e224e7957182fabc587d6e6
|
|
|
|
|
|
|
|
|
|
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.)
|
|
mostly only safe to use behind a firewall or through a VPN these days.
|
|
799cfb69ce am: 3e8f4a4284
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1686746
Change-Id: I39e5e4a6d33bb97e3e18d9dcafd9d67e57f35200
|
|
799cfb69ce
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1686746
Change-Id: Ic6e20c3746198dd19e0b5113868aeb9e3d14ce8d
|
|
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1686746
Change-Id: I8365ed6e93bc92c53832eb33aaa504149b81a9c4
|
|
Change-Id: I753dc7af3a4f370c9894ac0302648b82fa3e4631
|
|
Of course "x() { echo hello; } | tr e f; x" allows the pipe but not the call.
Ok, take out the union so you can && after a function declaration.
|
|
|
|
|
|
This got a bit out of hand. All I wanted to fix was the CR conversion to
get this part of https://tools.ietf.org/html/rfc854 right:
Therefore, the sequence "CR LF" must be treated as a single "new
line" character and used whenever their combined action is
intended; the sequence "CR NUL" must be used where a carriage
return alone is actually desired; and the CR character must be
avoided in other contexts. This rule gives assurance to systems
which must decide whether to perform a "new line" function or a
multiple-backspace that the TELNET stream contains a character
following a CR that will allow a rational decision.
But to understand the code well enough to do that, and to fix it so that
it works when IAC or CR sequences are split across multiple reads, I
ended up rewriting a lot:
* Add punctuation in help.
* Remove duplicated #include.
* Remove some unnecessary globals, enlarge the global buffers, and keep
state for correct IAC sequence processing across reads.
* Reduce code duplication and rewrite bits that made no sense.
* Handle entering/exiting raw mode more uniformly.
* Fix the prompt (the character count was wrong).
* Allow ^]^D (like BSD telnet) as well as ^]e to exit, and look less
like we crashed when doing so.
* Simplify the IAC sequence handling, but more importantly work
correctly when a sequence is split across multiple reads.
* Use more of the existing "x" functions from lib. (And remove code that
was duplicating what the "x" functions they'd just called had already
done.)
* Show "Connected to".
* Better signal handling.
I'm still not happy with TELOPT_ECHO and TELOPT_SGA in handle_wwdd(),
but don't (yet) understand them well enough to simplify them further. On
the bright side, I think TELOPT_NAWS is a lot clearer now.
It also occurs to me now I'm looking at the diff that although the IAC
output code is now better than it was, it probably still isn't pulling
its weight and might better be replaced by printf().
...but this patch has already gotten way out of hand!
|
|
After a network outage, a long-running telnetd was spinning trying to
read from a socket that was in TIME_WAIT. It's easy to reproduce this by
using the regular telnet client and typing ^]^D to exit abruptly.
I don't think these sockets should ever have been non-blocking, and we
want to give up on the client if we hit EOF. All of this needs
rewriting to be less complicated (and not use select(2)), but this seems
to be a minimal fix for the spin without harming normal usage (where by
"usage" I mean "testing the telnet client").
|
|
Handling utmp is login's job: telnetd should just pass the appropriate
option to login.
(I was investigating a different bug that caused telnetd to take 100%
CPU after a network outage and noticed an unexpected utmp fd. It turned
out to not be relevant to my actual problem, but it did remind me that
this utmp code isn't right in small details like that, but also in the
bigger picture: it's writing the wrong information, and only on logout,
not login. But rather than try to fix it, let's just let login do its
job.)
|
|
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.
|
|
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1685505
Change-Id: Ida557fc85fbd91b7fb3231d8323c574cddcfdb6a
|
|
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1685505
Change-Id: Ied95b519168dbe305ad05a622907ee98639818b4
|
|
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1685505
Change-Id: If145021ca48cce0cbcfc3fc4ddcda73b0e9e6196
|
|
After adding "toybox" to cvd-host_package.tar.gz,
aosp_cf_arm64_phone-userdebug failed to build with error:
In file included from external/toybox/lib/args.c:10:
external/toybox/toys.h:8:10: fatal error: 'generated/config.h' file
not found
#include "generated/config.h"
^~~~~~~~~~~~~~~~~~~~
1 error generated.
This is because toybox is not configured to be built on linux_bionic
host, and aosp_cf_arm64_phone is trying to build the HOST_CROSS variant
of toybox, which is arm64 linux_bionic.
Bug: 185883642
Test: lunch aosp_cf_arm64_phone-userdebug && m
Change-Id: I64418fb5f88f8a8b8b7e6905b58cc1f7e68ab2e8
|
|
c6b77729c2 am: 1fdc74db49
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1680490
Change-Id: If44f52f3a063a18b784385af1d70835a76c43512
|
|
c6b77729c2
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1680490
Change-Id: I8430faf05545529bf3883281ddb5ff9b49018b13
|
|
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1680490
Change-Id: I4a6c750805b7e1290f9643aba413e2944d1e8df9
|
|
Change-Id: I1bedc3801a9e95a1471610870eb367ae4af13a3b
|
|
legacy cpio think it's reading from 1970's era reel-to-reel magnetic tape.
|
|
I've been using hexedit quite a lot, mainly for _corrupting_ files, and
have been meaning to send this collection of changes for far too long
now. I saw a bug requesting editing in the ASCII pane (which this patch
_doesn't_ add), and wanted to get this sent in before it has to undergo
the third massive merge conflict of its existence...
The main "TODO" in this is that I never got round to implementing
searching for an arbitrary byte sequence. It seems like we ought to have
that feature, but personally I'm far more likely to jump to an offset or
to search for some ASCII. I haven't needed to search for arbitrary byte
sequences in all this time, so I'll fix this if/when I actually need
it...
* Enter (new) read-only mode rather than refusing to open read-only
files.
* More keys: page up/page down, home/end, and ctrl-home/ctrl-end for
beginning/end of file.
* Jump with ^J (or vi-like :). Enter absolute address or +12 or -40 for
relative jumps.
* Find with ^F (or vi-like /). No support for bytes, but useful for
finding text. (^G or n for next match, ^D or p for previous match.)
* Support all the usual suspects for "quit": vi-like q, desktop-like ^Q,
panic ^C, or even plain old Esc.
* The ASCII pane is made more readable by (hopefully) reasonable use of
color. Regular control characters are shown in red using the
appropriate letter (so a red A is 0x01, etc), printable characters are
shown normally, and top-bit set characters are just shown as a purple
question mark (since I couldn't come up with a better representation
that had any obvious value --- in my experience top-bit set characters
are either meaningless in ASCII, part of a UTF-8 sequence in modern
files, or in some random code page in ancient files). The choice of
red and purple was to deliberately make these not-actually-ASCII
characters slide into the background; before this patch they have so
many bright pixels (especially with the use of reverse video) that I
couldn't clearly see the *actual* ASCII content in the ASCII pane.
* Addresses are now shown in yellow. No real justification other than "it
looks nice".
* NUL bytes in the hex pane are shown dimmed. I find this helpful
especially when there's a lot of padding, and it can actually be a
useful clue when reverse engineering (you can "see" repeated patterns
more easily), but I can understand if this one's controversial.
* Errors are shown "vim style" in bold white text on a red background,
waiting briefly to ensure they're seen.
* The status bar shows the filename, whether the file is opened
read-only, the current offset into the file, and the total
length of the file.
* SIGWINCH handling has been added.
|
|
The new cpio test that uses setsid fails if you're using the toybox
setsid. Move the setpgrp() call before the vfork() but after the
setsid().
|
|
|
|
|
|
|
|
b9bece4ecd am: 1fa0602e27
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1673746
Change-Id: I176bc14d65da18a7c7d04eb000720dab46abe12b
|
|
b9bece4ecd
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1673746
Change-Id: I1e9cf524bd444c80fc8200ef7d414fa0820ca53f
|
|
Original change: https://android-review.googlesource.com/c/platform/external/toybox/+/1673746
Change-Id: I97986c577a47640bb701f813a76aad3fe022f728
|
|
Change-Id: I44f673f63bd7c9528935d7923221c7f69882a6df
|
|
|
|
|
