Toybox with POSIX patches from E5ten https://git.carbslinux.org/forks/toybox/atom?h=0.8.5 2021-05-15T16:14:03+00:00 2021-05-15T16:14:03+00:00 Rob Landley rob@landley.net 2021-05-15T16:14:03+00:00 urn:sha1:d3025b14b9c13286b79f256d019a99da9425ea0e The maximum unicode code point is 0x10ffff which is 21 bits. 2021-05-15T15:48:44+00:00 Rob Landley rob@landley.net 2021-05-15T15:48:44+00:00 urn:sha1:08481ee37ad5070ff1033d57351c3fa456d0729d Fixes theoretical bug I haven't actually seen. 2021-05-02T09:48:46+00:00 Ella-0 23418164+Ella-0@users.noreply.github.com 2021-05-01T10:50:13+00:00 urn:sha1:76676d772db4b7878fc82a879c55e04f21cfbb1d 2021-04-20T08:36:20+00:00 Elliott Hughes enh@google.com 2021-04-19T20:57:10+00:00 urn:sha1:76479c3ed071f1e4d985694ad86a144e8a716f5c 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. 2021-04-08T16:28:13+00:00 Rob Landley rob@landley.net 2021-04-08T16:28:13+00:00 urn:sha1:4fe080d418333afeb486f478c332bbcdace37f1b 2021-04-05T12:30:07+00:00 Rob Landley rob@landley.net 2021-04-05T12:30:07+00:00 urn:sha1:cecc41a3c52519ac1d65989b266fec32a2bd6ff7 Note: toy_exec() does an exact name match so fails given a path anyway, it's just an optimization to avoid the binary search, but special casing absolute path while very cheap isn't _correct_... 2021-03-13T08:41:41+00:00 Rob Landley rob@landley.net 2021-03-13T08:41:41+00:00 urn:sha1:4ff131ff958e2bbe7f1cc8a3d0e0acdd4a48c7ee (I hit 0 paired with EAGAIN causing premature pipeline end many years ago when a pipeline was Ctrl-Z then fg, may not still be possible with modern kernels but I left that covered just in case.) 2021-02-24T01:46:52+00:00 Elliott Hughes enh@google.com 2021-02-23T22:24:19+00:00 urn:sha1:1ba53eead1ab9787e77dc43196b8402ec96e7fd4 Other dd implementations always show the status on exit, whether success or failure. Fix that by using xsigatexit() (and clarify the comment for that function a little, since it didn't previously address the "at exit" part of its behavior at all). This also fixes SIGUSR1 behavior so that we show the status immediately rather than on the next trip round the read/write loop. Tested with `dd of=/dev/full`, sending SIGUSR1 twice from another shell (to see the status immediately each time, without exiting), then hitting ^C (to see the status and then exiting), then restarting dd and hitting enter (to see a write error followed by the status before exiting). Bug: https://issuetracker.google.com/177017283 2021-02-23T01:48:49+00:00 Rob Landley rob@landley.net 2021-02-23T01:48:49+00:00 urn:sha1:1f9e37e36117c51a17f017143f1b68787d913979 2021-02-20T23:31:32+00:00 Elliott Hughes enh@google.com 2021-02-20T21:15:55+00:00 urn:sha1:47b9f6a12d471086ceb11c8e2893450074e50543 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.