Toybox with POSIX patches from E5ten https://git.carbslinux.org/forks/toybox/atom?h=master 2021-07-08T09:30:00+00:00 2021-07-08T09:30:00+00:00 Rob Landley rob@landley.net 2021-07-08T09:30:00+00:00 urn:sha1:127cff38809ea6c3a37ed3ce7f428cafdc38e2e1 Posix says you removing a non-empty directory "shall fail" in both: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/unlinkat.html https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/rmdir.html So toybox mv went ahead and unlinked the directory even if the contents hadn't all been deleted because posix guarantees it to be harmless. But cgroups (https://lwn.net/Articles/679786/) deletes the non-empty directory, thus the Linux Test Project's cgroups_fj_function test6 was failing with toybox mv because they depend on not triggering the posix violating behavior. Work around it by having mv DIRTREE_SAVE failing nodes and then check for a non-empty ->child in the COMEAGAIN as a signal not to unlink the dir. While I'm there do some code cleanup, add a cp -i test... 2021-07-04T16:57:40+00:00 Rob Landley rob@landley.net 2021-07-04T16:57:40+00:00 urn:sha1:ba242e08ee83910596420f42830fd3d6fc1868d0 new lib/ flag), allow -s to be fraction of a second, inline (anonymous) struct so globals.h isn't using an incomplete type, blank line in GLOBALS() between option args and other variables, collate tail_continue() to one function, add test. 2021-07-01T15:45:56+00:00 Elliott Hughes enh@google.com 2021-06-30T23:38:42+00:00 urn:sha1:933f238bd1dfd8931fa3cc60f61aea19802daefd (Based on someone else's patch.) Implementing -F with inotify is a lot more work (including more portability shims for macOS), so this is a simpler polling implementation. Also fix my earlier mistake where xnotify_add() wasn't actually an 'x' function that exits on failure. 2021-06-18T13:57:07+00:00 Rob Landley rob@landley.net 2021-06-18T13:57:07+00:00 urn:sha1:29e7ed94a1fe2836d38960b9b3ab3e3b7e61c791 2021-05-28T11:21:56+00:00 Rob Landley rob@landley.net 2021-05-28T11:21:56+00:00 urn:sha1:657cc63108993c8b5a8eb69ebba5a708022a786a 2021-05-28T11:17:12+00:00 Rob Landley rob@landley.net 2021-05-28T11:17:12+00:00 urn:sha1:54788b5670b1914061763b60a91d0842983ab428 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.