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.)
---
 main.c            | 2 +-
 toys/other/yes.c  | 2 +-
 toys/posix/echo.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
From 7e7b57d50e459e82a789cb1211b58d921b47cee8 Mon Sep 17 00:00:00 2001
From: Elliott Hughes <[email protected]>
Date: Mon, 26 Apr 2021 15:13:24 -0700
Subject: [PATCH] More line buffering.

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.)
---
 main.c            | 2 +-
 toys/other/yes.c  | 2 +-
 toys/posix/echo.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/main.c b/main.c
index deea9897..6e3da111 100644
--- a/main.c
+++ b/main.c
@@ -95,7 +95,7 @@ void toy_singleinit(struct toy_list *which, char *argv[])
     for (toys.optc = 0; toys.optargs[toys.optc]; toys.optc++);
   }
 
-  if (!(which->flags & TOYFLAG_NOFORK)) {
+  if (strcmp(which->name, "toybox") && !(which->flags & TOYFLAG_NOFORK)) {
     toys.old_umask = umask(0);
     if (!(which->flags & TOYFLAG_UMASK)) umask(toys.old_umask);
 
diff --git a/toys/other/yes.c b/toys/other/yes.c
index 773a5a88..8edba0ae 100644
--- a/toys/other/yes.c
+++ b/toys/other/yes.c
@@ -2,7 +2,7 @@
  *
  * Copyright 2007 Rob Landley <[email protected]>
 
-USE_YES(NEWTOY(yes, NULL, TOYFLAG_USR|TOYFLAG_BIN))
+USE_YES(NEWTOY(yes, NULL, TOYFLAG_USR|TOYFLAG_BIN|TOYFLAG_LINEBUF))
 
 config YES
   bool "yes"
diff --git a/toys/posix/echo.c b/toys/posix/echo.c
index b546e94b..9b7b9222 100644
--- a/toys/posix/echo.c
+++ b/toys/posix/echo.c
@@ -9,7 +9,7 @@
  * We also honor -- to _stop_ option parsing (bash doesn't, we go with
  * consistency over compatibility here).
 
-USE_ECHO(NEWTOY(echo, "^?Een[-eE]", TOYFLAG_BIN|TOYFLAG_MAYFORK))
+USE_ECHO(NEWTOY(echo, "^?Een[-eE]", TOYFLAG_BIN|TOYFLAG_MAYFORK|TOYFLAG_LINEBUF))
 
 config ECHO
   bool "echo"
-- 
2.31.1.498.g6c1eba8ee3d-goog

_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to