Re: [Toybox] [PATCH] microcom, stty: Use TCSADRAIN to set tty device attribute

On 5/20/24 23:43, Yi-Yo Chiang via Toybox wrote: > > Don't flush the tty device input queue when setting device attribute. > > > > Rationale: > > * microcom: The tty device might already have a _good enough_ termios > > to read data from. Flushing the input queue ju

Re: [Toybox] microcom.c discarding data due to TCSAFLUSH

On Fri, May 24, 2024 at 12:11 AM Rob Landley wrote: > On 5/20/24 09:42, Yi-Yo Chiang via Toybox wrote: > > Is there any particular reason to use TCSAFLUSH here? > > Partly because it's what strace said busybox and minicom were doing, and > partly > because I've had serial h

[Toybox] [PATCH] microcom, stty: Use TCSADRAIN to set tty device attribute

Don't flush the tty device input queue when setting device attribute. Rationale: * microcom: The tty device might already have a _good enough_ termios to read data from. Flushing the input queue just to set the terminal attribute would result in data loss in this case. * stty: This

[Toybox] microcom.c discarding data due to TCSAFLUSH

Found this out today when comparing captured logs. Every time I connect to a pty the first few hundreds of bytes seem to always be missing. I then traced to this line https://github.com/landley/toybox/blob/master/toys/net/microcom.c#L103 and it's the tcsetattr(TCSAFLUSH) that is discarding

[Toybox] [PATCH] microcom: Don't crash if failed to open paste file

* When running the "paste" command and failed to open the paste file (such as file not found or permission error), don't crash the entire microcom program. Instead print the error message and give the user a chance to fix the problem. * If "paste" command is cancelled by "ESC" or an empty

Re: [Toybox] [PATCH] xputs: Do flush

Thanks! Adding TOYFLAG_NOBUF worked. I feel the same way about "manual flushing of the output buffer is a terrible interface". I asked myself the question "Why am I manually flushing so much? There must be a better way..." multiple times when I wrote the other patch that does s/xprintf/dprintf/,

Re: [Toybox] [PATCH] xputs: Do flush

about we just update the comment of xputs() (2), and add the line of flush in microcom.c (1)? On Sun, May 19, 2024 at 8:41 AM Rob Landley wrote: > On 5/16/24 06:46, Yi-Yo Chiang via Toybox wrote: > > The comment string claims xputs() to write, flush and check error. > > How

[Toybox] [PATCH] microcom: Flush after writing to stdout

Right now the output from the microcom program itself is buffered and not shown to the user as soon as possible, resulting in strange artifacts like: * Start of program "Escape character is ..." prompt is not shown until the user first hit the escape character. * "Filename: " prompt is not

[Toybox] [PATCH] xputs: Do flush

The comment string claims xputs() to write, flush and check error. However the 'flush' operation is actually missing due to 3e0e8c6 changing the default buffering mode from 'line' to 'block'. From 861e020ceb5971ba202fbd75ad2669c9e5e94dad Mon Sep 17 00:00:00 2001 From: Yi-Yo Chiang Date: Thu, 16

Re: [Toybox] netcat -f bug

The nodes under /dev/pts/ are allocated on demand, so there isn't a fixed pts/number. When a process opens /dev/ptmx (controlling end), a /dev/pts/ node would be allocated. Another process can then open the pts end and communicate with the controlling end. What my test is doing is to just open a

Re: [Toybox] netcat -f bug

On Thu, May 16, 2024 at 1:12 AM enh wrote: > On Sat, May 11, 2024 at 3:12 AM Yi-Yo Chiang via Toybox > wrote: > > > > > > > > On Sat, May 11, 2024 at 1:30 AM Rob Landley wrote: > >> > >> What's your use case triggering this patch? Because

Re: [Toybox] netcat -f bug

actually works and behave similarly enough to `stty raw -echo && nc > -f` for me. > > (but it's still much more convenient if I can do all that (double `cat` > and background process handling) with a single shorter `nc -f` command) > > >> >> On 5/10/24 0

Re: [Toybox] netcat -f bug

& stty raw isig -echo && cat >/dev/pts/0 > This actually works and behave similarly enough to `stty raw -echo && nc -f` for me. (but it's still much more convenient if I can do all that (double `cat` and background process handling) with a single shorter `nc -f` command) &g

[Toybox] stty bug

The _negate & combination_ type of settings are bugged. `stty cooked` and `stty raw` works fine, but the negated options: $ stty -raw stty: unknown option: cooked $ stty -cooked stty: unknown option: raw ___ Toybox mailing list Toybox@lists.landley.net

[Toybox] netcat -f bug

Hi, The -f option for netcat doesn't seem to be doing anything right now. It is missing a call to pollinate() after opening the specified device file. The patch adds back that line of pollinate(). Also make sure that the timeout handler is not armed for -f mode as -f shouldn't timeout. File open()

Re: [Toybox] Slow grep

On Thu, Sep 29, 2022 at 1:20 PM Rob Landley wrote: > On 9/28/22 14:54, enh wrote: > > heh... funny you should mention "." in the first position... > > > > $ echo "foo.jar" | old-toybox grep '\.jar' > > foo.jar > > $ echo "foo.jar" | new-toybox grep '\.jar' > > $ > > Technically that's '\' in the

Re: [Toybox] Slow grep

(I suffered a system failure during the weekend and lost all my browser tabs and consequently lost track of all my work...) Might be a stupid question, but what's so special about ". in first position"? Doesn't ANY '.' in ANY position (sans ) indicate a regex (not fixed pattern)? On Tue, Sep

Re: [Toybox] Slow grep

On Fri, Sep 16, 2022 at 1:20 PM Rob Landley wrote: > On 9/15/22 16:32, enh wrote: > > On Thu, Sep 15, 2022 at 1:45 PM Rob Landley > <mailto:r...@landley.net>> wrote: > > > > On 9/15/22 07:30, Yi-yo Chiang via Toybox wrote: > > > grep is

[Toybox] Slow grep

grep is slow when the number of patterns is large. We have some tests that use `grep -v -f $file1 $file2` to check if $file1 is a superset of $file2, and if not, then generate a report of what is in $file2 but not $file1. The command completes reasonably fast on desktop linux (grep (GNU grep)

[Toybox] [PATCH] Support tail +123

Old style of saying "tail -n +123". From 6ceb6f090dc7018e9a6d67dacbba9b74db34f418 Mon Sep 17 00:00:00 2001 From: Yi-Yo Chiang Date: Tue, 30 Aug 2022 17:39:10 +0800 Subject: [PATCH] Support tail +123 Old style of saying "tail -n +123". Change-Id: Ifaf78eb1d8611536a9e3428081009a55aea4ce47 ---

Re: [Toybox] [PATCH] losetup: Wait for ueventd to create loop device on Android

On Wed, Aug 24, 2022 at 7:56 PM Rob Landley wrote: > On 8/24/22 05:04, Yi-yo Chiang wrote: > > Digging through git history and I believe AOSP has been using "tmpfs as > /dev" > > plus "init and/or ueventd servicing uevents" since at least Android 1.0 > (circa > > 2008, > > >

Re: [Toybox] [PATCH] losetup: Wait for ueventd to create loop device on Android

y wrote: > Applied the patch, but WOW this is conceptually ugly... > > On 8/23/22 10:57, Yi-yo Chiang via Toybox wrote:> Android doesn't use > devtmpfs. > > Huh, I thought Android was using it because you guys got blamed for > shoehorning > userspace policy into the kernel ba

[Toybox] [PATCH] losetup: Wait for ueventd to create loop device on Android

Android doesn't use devtmpfs. Instead device nodes under /dev are created by userspace daemon ueventd. There could be a noticeable delay between LOOP_CTL_GET_FREE issued and loop device created, so we need to wait until it is created and then continue. The timeout (5s) and time quantum (20ms) is

[Toybox] [PATCH] mount: chomp() trailing '\n' off xrunread() return value

losetup -sf prints trailing newline, which confuses the mount command: mount /mnt/test.img /mnt/mntpoint > mount: '/dev/block/loop48 > '->'/mnt/test': No such file or directory Bug: 243494992 From cad3c19434b3578544877b867f7b46b4ef72f235 Mon Sep 17 00:00:00 2001 From: Yi-Yo Chiang Date:

Re: [Toybox] Recursive bind mounts.

I would prefer a standalone '--rbind' option, so people who care about this subtle difference have a choice. --bind -> MS_BIND --rbind -> MS_BIND|MS_REC -> could default to --bind or --rbind? IMO the default doesn't matter much if we can override with explicit --bind & --rbind. >From Android

Re: [Toybox] [PATCH] Support mount -o private mountpoint

On Fri, Jun 24, 2022 at 3:07 PM Rob Landley wrote: > On 6/21/22 11:30, Yi-yo Chiang via Toybox wrote: > > `mount -o private mountpoint` should change the mount propagation type > > of mountpoint to MS_PRIVATE. This didn't work because it falls into > > the "read /etc/f

Re: [Toybox] [PATCH] Support mount -o private mountpoint

Ping? Might have ended in the spam bucket again... On Wed, Jun 22, 2022, 00:30 Yi-yo Chiang wrote: > `mount -o private mountpoint` should change the mount propagation type > of mountpoint to MS_PRIVATE. This didn't work because it falls into > the "read /etc/fstab" branch (one argument), and

[Toybox] [PATCH] Support mount -o private mountpoint

`mount -o private mountpoint` should change the mount propagation type of mountpoint to MS_PRIVATE. This didn't work because it falls into the "read /etc/fstab" branch (one argument), and fails when mountpoint is not found in the fstab, or fstab is not found (Android case). `mount -o private blah

Re: [Toybox] [PATCH] modprobe: fix parsing of short lines.

I wonder, would it make cleaner and shorter code here, if we just unfold the `for (strtok(...) ...)` loop two times and check that both calls succeed. On Fri, Jun 4, 2021 at 6:20 AM enh via Toybox wrote: > The intent here seems to have been to ignore lines with too few > arguments to be valid,

[Toybox] [PATCH] cpio: Don't lchown() if -t is specified

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

[Toybox] [cpio] Various questions (mtime, inode number)

Was playing with the new cpio command and spotted a few oddities. Some of which I'm not sure are bugs or WAI? 1. cpio -i might not preserve mtime, due to later entries might modify previous entries' mtime. $ mkdir a && touch a/b $ touch -d @0 a a/b $ ls -al a total 8 drwxr-xr-x 2 yochiang

Re: [Toybox] [PATCH] setsid(1): call setsid(2) before setpgrp(2).

Interesting. Probably because our previous for-loop takes input from regular file. The GNU implementation seems to treat only special files (block and char devices) differently as a "magnetic tape". On Tue, Apr 20, 2021 at 5:33 PM Rob Landley wrote: > On 4/20/21 3:23 AM, Yi-yo Chia

Re: [Toybox] [PATCH] setsid(1): call setsid(2) before setpgrp(2).

Why do we need setsid in the new cpio testcase though? On Tue, Apr 20, 2021 at 3:50 AM enh via Toybox wrote: > 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(). > --- > toys/other/setsid.c | 9

Re: [Toybox] [PATCH] cpio: support reading concatenated cpio files.

On Sun, Apr 18, 2021 at 4:59 AM Rob Landley wrote: > On 4/17/21 8:40 AM, Yi-yo Chiang wrote: > > On Sat, Apr 17, 2021 at 7:32 PM Rob Landley > > wrote: > > > > On 4/17/21 4:43 AM, Yi-yo Chiang wrote: > > > On Sat, Apr 17, 2021 at 2:56 PM Rob Landley >

Re: [Toybox] [PATCH] cpio: support reading concatenated cpio files.

On Sat, Apr 17, 2021 at 7:32 PM Rob Landley wrote: > On 4/17/21 4:43 AM, Yi-yo Chiang wrote: > > On Sat, Apr 17, 2021 at 2:56 PM Rob Landley > > wrote: > > > > On 4/16/21 1:44 PM, Yi-yo Chiang wrote: > > > I'm not sure what Elliot's goal is? I assume he's trying

Re: [Toybox] [PATCH] cpio: support reading concatenated cpio files.

> > > > i'll chase up the person using `toybox cpio` and move them over to the > hermetic > > prebuilt build toybox later. for now i'll try to reproduce this locally > and see > > what the trouble is... > > Is this a _new_ failure, or is this a failure of the concatenated files it > didn't handle

Re: [Toybox] [PATCH] cpio: support reading concatenated cpio files.

On Sat, Apr 17, 2021 at 2:56 PM Rob Landley wrote: > On 4/16/21 1:44 PM, Yi-yo Chiang wrote: > > I'm not sure what Elliot's goal is? I assume he's trying to extract a > > concatenated ramdisk, and I still see a problem in the current solution. > > > > The buffer-format > > ( >

Re: [Toybox] [PATCH] cpio: support reading concatenated cpio files.

I'm not sure what Elliot's goal is? I assume he's trying to extract a concatenated ramdisk, and I still see a problem in the current solution. The buffer-format ( https://www.kernel.org/doc/Documentation/early-userspace/buffer-format.txt) says: initramfs := ("\0" | cpio_archive |

Re: [Toybox] [PATCH] cpio: Implement -u (copy unconditionally)

On Wed, Mar 3, 2021 at 1:56 AM enh wrote: > > > On Mon, Mar 1, 2021 at 5:43 PM Rob Landley wrote: > >> On 2/28/21 12:29 PM, Yi-yo Chiang wrote: >> > (I'll try to keep it short) >> > >> > My original motivation to send this patch is that my coworker found out >> (when he >> > was working with

Re: [Toybox] [PATCH] cpio: Implement -u (copy unconditionally)

(I kind of dozed off... so break off some questions / answers to another mail) On Sun, Feb 28, 2021 at 6:41 PM Rob Landley wrote: > On 2/27/21 10:18 AM, Yi-yo Chiang wrote: > > Do we want toybox cpio/tar to be feature-identical to GNU or Solaris' > > implementation? (I hope not, cause that

Re: [Toybox] [PATCH] cpio: Implement -u (copy unconditionally)

quot;dir replace dir" testcase, but one can also argue that directory is just a special type of file...) "dir replace file" and "file replace dir" are artifacts of the way I implemented the patch, because I unlink/rmdir a name regardless of the file type I'm going

Re: [Toybox] [PATCH] cpio: Implement -u (copy unconditionally)

# Test dir from archive replaces existing file $ rm -rf a $ touch a $ cpio -i wrote: > On 2/20/21 8:34 AM, Yi-yo Chiang via Toybox wrote: > > *ping* (in case this got categorized as spam by gmail) > > It did, and so did this reply. :) > > > On Sun, Feb 14, 2021 at 9:13 PM

Re: [Toybox] [PATCH] cpio: Implement -u (copy unconditionally)

gmail's spam filter >> again. >> >> I'll try to take a look tonight. >> >> Rob >> >> On 2/24/21 12:17 PM, enh via Toybox wrote: >> > ping? >> > >> > On Sun, Feb 14, 2021 at 5:13 AM Yi-Yo Chiang via Toybox >> > mailto:toybox@l

Re: [Toybox] [PATCH] cpio: Implement -u (copy unconditionally)

*ping* (in case this got categorized as spam by gmail) On Sun, Feb 14, 2021 at 9:13 PM Yi-Yo Chiang wrote: > If -u is specified, then replace any existing files or directories. > > If -u is not specified and the path to be inflated already exist, then > report EEXIST error. This behaves

Re: [Toybox] [PATCH] df: -a should even show mounts we couldn't stat.

> it's not clear to me whether yi-yo is happy yet? Finally got some time to thoroughly test the *enhanced* df! I'm pretty happy with the output now, where `df ` shows more accurate results than that of coreutils for over-mounted filesystems, and `df -a` shows all mounts no matter what (best

Re: [Toybox] [PATCH] df: -a should even show mounts we couldn't stat.

There is still one weird case left in df, albeit not related to previous issues, $ adb shell df Filesystem1K-blocksUsed Available Use% Mounted on /dev/block/dm-1 964296 961376 2920 100% / tmpfs 20046361060 2003576 1%

Re: [Toybox] [PATCH] df: -a should even show mounts we couldn't stat.

On Wed, Feb 17, 2021 at 12:36 AM Rob Landley wrote: > On 2/16/21 3:01 AM, Yi-yo Chiang wrote:> > I think the main purpose of > the > original patch is to show mounts whose > > > stat()/statvfs() failed. > > > > And the current one should do that? (I don't have any mount points I >

Re: [Toybox] [PATCH] df: -a should even show mounts we couldn't stat.

On Mon, Feb 15, 2021 at 10:31 PM Rob Landley wrote: > Sigh, thunderbird crashed and I lost 8 gazillion open reply windows with > half-composed messages. (Kmail used to remember messages being composed > and open > them back up again when it was relaunched. I miss kmail, but they tied it > to a >

Re: [Toybox] [PATCH] df: -a should even show mounts we couldn't stat.

Hi Rob, I think the main purpose of the original patch is to show mounts whose stat()/statvfs() failed. For example, an under-privileged user may be able to read /proc/mounts but lack the permission to stat(vfs) the mount point, so showing "-" is a way of saying "I know this XXX device is being

[Toybox] [PATCH] cpio: Implement -u (copy unconditionally)

If -u is specified, then replace any existing files or directories. If -u is not specified and the path to be inflated already exist, then report EEXIST error. This behaves slightly different from GNU cpio, as GNU cpio checks the timestamp and replaces when the timestamp of the existing file is

[Toybox] [PATCH] cpio: Guard free() with CFG_TOYBOX_FREE

--- toys/posix/cpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/toys/posix/cpio.c b/toys/posix/cpio.c index 795f890c..e8205a30 100644 --- a/toys/posix/cpio.c +++ b/toys/posix/cpio.c @@ -304,7 +304,7 @@ void cpio_main(void) free(link); xclose(fd); } -

Re: [Toybox] [PATCH] df: -a should even show mounts we couldn't stat.

Not related to your change, but I noticed we're using "statvfs.f_bsize" as filesystem block size to calculate the used percentage. We should use "statvfs.f_frsize" instead as that is the unit of "statvfs.f_blocks". On Sat, Feb 13, 2021 at 9:37 AM enh via Toybox wrote: > In xgetmountlist(), keep

Re: [Toybox] [PATCH] cpio: fix misaligned header if readlink() returns unexpected value

tually > give the length of the ciphertext, which will be slightly longer > than the plaintext due to NUL-padding and an extra 2-byte overhead. Looks like this is intentional :( On Tue, Feb 9, 2021 at 2:44 AM enh wrote: > > > On Mon, Feb 8, 2021 at 2:06 AM Yi-yo Chiang

Re: [Toybox] [PATCH] cpio: fix misaligned header if readlink() returns unexpected value

On Mon, Feb 8, 2021 at 5:19 PM Rob Landley wrote: > On 2/7/21 10:10 AM, Yi-Yo Chiang via Toybox wrote: > > If file type is symlink and readlink() fails or returns unexpected link > > size, then the file body wouldn't be written, resulting in a misaligned > > archive. > &

[Toybox] cpio: implement "-u" or just make "-u" the default behavior?

Right now cpio ignores the "-u" flag. (-u: Copy unconditionally (normally, an older file will not replace a newer file with the same name).) For directories, it behaves like "-u" is not specified, and for regular files, symlinks, devnode it behaves like "-u" is specified (sort of..) $ mkdir a $

Re: [Toybox] [PATCH] mkpathat: return EEXIST only if MKPATHAT_MKLAST is given

On Mon, Feb 8, 2021 at 3:41 PM Rob Landley wrote: > On 2/7/21 10:07 AM, Yi-Yo Chiang via Toybox wrote: > > There was a regression: > > > > $ mkdir a > > $ touch a/b > > I just tried that and it worked with no error? > I should've been more clear. I mean af

[Toybox] [PATCH] cpio: fix misaligned header if readlink() returns unexpected value

If file type is symlink and readlink() fails or returns unexpected link size, then the file body wouldn't be written, resulting in a misaligned archive. As explained in the comments, there are some cases where the link size returned by lstat() and readlink() may be different. To accommodate this,

[Toybox] [PATCH] mkpathat: return EEXIST only if MKPATHAT_MKLAST is given

There was a regression: $ mkdir a $ touch a/b Calling mkpath("a/b") would return an error with EEXIST errno. This is because "a/b" is a regular file. However mkpath() should only create the leading directories of "a/b", which is "a/", which shouldn't be an error because attempting to create an

Re: [Toybox] [PATCH 1/2] rm: Check file existence with lstat() explicitly if "-f" is specified

I found the original commit that adds this: https://android.googlesource.com/platform/bionic/+/35778253a5ed71e87a608ca590b63729d9f88567 There is even a link to this mailing list... Can't say I completely follow the discussion, as the thread is long and dated, and I may be missing a lot of

Re: [Toybox] [PATCH 1/2] rm: Check file existence with lstat() explicitly if "-f" is specified

(forgot to cc Elliott) On Tue, Feb 2, 2021, 12:06 Rob Landley wrote: > On 2/1/21 9:53 PM, Yi-yo Chiang wrote: > > There has to be a reason, but I'll defer that question to Elliott.. > > >

Re: [Toybox] [PATCH 1/2] rm: Check file existence with lstat() explicitly if "-f" is specified

There has to be a reason, but I'll defer that question to Elliott.. https://cs.android.com/android/platform/superproject/+/master:bionic/libc/bionic/faccessat.cpp;l=46;drc=50080a29f7327fcd009344844bb9e643b2d6b9c3 This line also left me scratching my head for half a day.

[Toybox] [PATCH 2/2] rm: Add testcase for "rm -f /missing_file"

--- tests/rm.test | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tests/rm.test b/tests/rm.test index 5ecbfdc1..9ab4c4bc 100755 --- a/tests/rm.test +++ b/tests/rm.test @@ -60,3 +60,9 @@ rm -rf d1 touch "meep" testing "-v" "rm -v meep | sed 's/emoved/m/'" "rm 'meep'\n" "" "" rm -f

[Toybox] [PATCH 1/2] rm: Check file existence with lstat() explicitly if "-f" is specified

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

Re: [Toybox] [PATCH] Skip mount.test if not running as root

Pointing out my own typo here... mount, *umount and friends On Mon, Feb 1, 2021, 21:02 Yi-yo Chiang wrote: > mount, mount and their friends usually require root permission, so let's > skip these when not running as root! > > -- > > Yi-yo Chiang > Software Engineer > yochi...@google.com >

[Toybox] [PATCH] Skip mount.test if not running as root

mount, mount and their friends usually require root permission, so let's skip these when not running as root! -- Yi-yo Chiang Software Engineer yochi...@google.com From c4b658d6217aa96ed91edb969fdb9c70b12770f8 Mon Sep 17 00:00:00 2001 From: Yo Chiang Date: Mon, 1 Feb 2021 17:15:19 +0800

[Toybox] [PATCH] Fix mount.test command string quoting

Use "" instead of '' to quote commands as the command contains expandable variables. I also found that most of the test cases are not working as intended. Most of the test commands are like "mount ... >/dev/null 2>&1 && && umount", so there is no visible output when mount succeeds or fails, and