From vda.linux at googlemail.com Tue Mar 1 07:48:19 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Mar 2022 08:48:19 +0100 Subject: [PATCH] ash: don't read past end of var in subvareval for bash substitutions In-Reply-To: <20220228073649.16485-1-soeren@soeren-tempel.net> References: <20220228073649.16485-1-soeren@soeren-tempel.net> Message-ID: On Mon, Feb 28, 2022 at 8:38 AM wrote: > From: S?ren Tempel > > Without this patch, BusyBox handles bash pattern substitutions without > a terminating '/' character incorrectly. > > Consider the following shell script: > > _bootstrapver=5.0.211-r0 > _referencesdir="/usr/${_bootstrapver/-*}/Sources" > echo $_referencesdir > > This should output `/usr/5.0.211/Sources`. However, without this patch > it instead outputs `/usr/5.0.211Sources`. This is due to the fact that > BusyBox expects the bash pattern substitutions to always be terminated > with a '/' (at least in this part of subvareval) and thus reads passed > the substitution itself and consumes the '/' character which is part of > the literal string. If there is no '/' after the substitution then > BusyBox might perform an out-of-bounds read under certain circumstances. > > When replacing the bash pattern substitution with `${_bootstrapver/-*/}`, > or with this patch applied, ash outputs the correct value. > > Signed-off-by: S?ren Tempel > --- > shell/ash.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/shell/ash.c b/shell/ash.c > index adb0f223a..8097d51c3 100644 > --- a/shell/ash.c > +++ b/shell/ash.c > @@ -7077,7 +7077,7 @@ subevalvar(char *start, char *str, int strloc, > repl = NULL; > break; > } > - if (*repl == '/') { > + if (*repl == '/' || (unsigned char)*repl == CTLENDVAR) { > *repl = '\0'; > break; > } This broke shell/ash_test/ash-vars/var_bash5.tests I'm going to use this: if (*repl == '/') { *repl = '\0'; break; } + if ((unsigned char)*repl == CTLENDVAR) { /* ${v/pattern} (no trailing /, no repl) */ + repl = NULL; + break; + } From vda.linux at googlemail.com Tue Mar 1 16:39:48 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Mar 2022 17:39:48 +0100 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: > On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: > > However, if this bug shows-up, probably it means that the system has > > a lot of processes running and a lot of processes created and > > destroyed compared to the max PID available. Thus, the system might be > > incorrectly configured compared with its typical usage which probably > > is the main reason because nobody complained before. > > Nah, a shell script can spin through an awful lot of PIDs pretty fast, and if > you're doing a -j 8 build that has a lot of script snippets (let alone parallel > autoconf etc) vs something with say a 10 second timeout? I try the below and it seems to be able to spawn "only" ~1500 processes/second. $ time sh -c 'i=30000; while test $((--i)) != 0; do sleep 0 & done 2>/dev/null' real 0m19.190s user 0m23.062s sys 0m6.732s My memory is hazy on this, but IIRC kernel also actually has some defensive code to not immediately reuse pids which just died. It's interesting to find out why pids are reused that fast on the affected system. Meanwhile: what "timeout" is doing is it tries to get out of the way of the PROG to be launched so that timeout's parent sees PROG (not timeout) as a child. E.g. it can send signals to it, get waitpid notifications if PROG has been stopped with a signal, and such. And PROG also has no spurious "timeout" child. "timeout" exists as an orphaned granchild. Let's go with a solution with fd opened to /proc/PID? From David.Laight at ACULAB.COM Tue Mar 1 17:06:35 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Tue, 1 Mar 2022 17:06:35 +0000 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: From: Denys Vlasenko > Sent: 01 March 2022 16:40 > > On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: > > On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: > > > However, if this bug shows-up, probably it means that the system has > > > a lot of processes running and a lot of processes created and > > > destroyed compared to the max PID available. Thus, the system might be > > > incorrectly configured compared with its typical usage which probably > > > is the main reason because nobody complained before. > > > > Nah, a shell script can spin through an awful lot of PIDs pretty fast, and if > > you're doing a -j 8 build that has a lot of script snippets (let alone parallel > > autoconf etc) vs something with say a 10 second timeout? > > I try the below and it seems to be able to spawn "only" > ~1500 processes/second. > > $ time sh -c 'i=30000; while test $((--i)) != 0; do sleep 0 & done 2>/dev/null' > real 0m19.190s > user 0m23.062s > sys 0m6.732s > > My memory is hazy on this, but IIRC kernel also actually has some > defensive code to not immediately reuse pids which just died. The Linux krnel only has protection for code inside the kernel. Basically there is a ref-counted structure that you need to send the signal - not the pid itself. I can't quite remember whether the pid itself can be reused even before that structure is freed. NetBSD does guarantee not to reuse a pid for a reasonable number of forks after a process exits. > It's interesting to find out why pids are reused that fast on the > affected system. They are allocated by a simple numeric scan for a free pid. So it depends on where the scan is and the pid being freed. It can be reused for the very next fork(). > Meanwhile: what "timeout" is doing is it tries to get out > of the way of the PROG to be launched so that timeout's parent > sees PROG (not timeout) as a child. E.g. it can send signals > to it, get waitpid notifications if PROG has been stopped > with a signal, and such. I also believe it is only checking the pid every (few?) seconds. > And PROG also has no spurious "timeout" child. > "timeout" exists as an orphaned granchild. > > Let's go with a solution with fd opened to /proc/PID? I think you need to verify some part of the process state. Especially for pre-pidfd kernels. Probably the process start time. If that changes the pid has been reused. That gets the timing window down to 'we checked it was the right process', but the pid was reused before we could send the signal. It also requires the process to exit on exactly its timeout. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From steffen at sdaoden.eu Tue Mar 1 17:49:17 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Mar 2022 18:49:17 +0100 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: <20220301174917.eoVFB%steffen@sdaoden.eu> Hello. ..despite that particular timeout(1), i have not looked.. David Laight wrote in : |From: Denys Vlasenko |> Sent: 01 March 2022 16:40 |> On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: |>> On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: ... |> My memory is hazy on this, but IIRC kernel also actually has some |> defensive code to not immediately reuse pids which just died. | |The Linux krnel only has protection for code inside the kernel. |Basically there is a ref-counted structure that you need to send the |signal - not the pid itself. |I can't quite remember whether the pid itself can be reused even before |that structure is freed. | |NetBSD does guarantee not to reuse a pid for a reasonable number |of forks after a process exits. ...which might be fruitless with 16-bit pids, define "reasonable". Matt Dillon of DragonFly BSD (crond etc.) made, after implementing some DBSD kernel optimizations (iirc), tests with statically linked programs and... quoting myself i remember Matthew Dillon's post on DragonFly BSD users@[1], where he claims 450000 execs per second for a statically linked binary, and about 45000 execs per second for a dynamic one, with DragonFly 5.6 on a threadripper. [1] https://marc.info/?l=dragonfly-users&m=155846667020624&w=2 (Hope that is still valid.) It think it is a problem with shells, i once stumbled over this with a particular (now completely rewritten) of the test suite of the mailer i maintain: My guess would have been that if i kill(1) a job specification, then the sh(1)ell would refuse to use its builtin kill(1) to kill a PID that was saved away from ${!}, and the process in question has already terminated. Of course using job specifications is impossible here, let alone portably (though that i have not even tried, because set -m results in a lot of unwanted noise). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rob at landley.net Tue Mar 1 19:42:03 2022 From: rob at landley.net (Rob Landley) Date: Tue, 1 Mar 2022 13:42:03 -0600 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: <2317c961-5b4b-796b-9654-22312d9da8a6@landley.net> On 3/1/22 10:39 AM, Denys Vlasenko wrote: > On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: >> On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: >> > However, if this bug shows-up, probably it means that the system has >> > a lot of processes running and a lot of processes created and >> > destroyed compared to the max PID available. Thus, the system might be >> > incorrectly configured compared with its typical usage which probably >> > is the main reason because nobody complained before. >> >> Nah, a shell script can spin through an awful lot of PIDs pretty fast, and if >> you're doing a -j 8 build that has a lot of script snippets (let alone parallel >> autoconf etc) vs something with say a 10 second timeout? > > I try the below and it seems to be able to spawn "only" > ~1500 processes/second. Let's see, off the top of my head... 1) make -j 8 2) Not all wrapper variants ala system() and ccache and friends will exec() without a fork(). 3) the default /proc/sys/kernel/pid_max is only 32768, 10 second timeout would see a wrap at 1.5k/sec. 4) my laptop has about 500 persistent processes running right now and isn't really busy: the system can only recycle the free ones. 5) Containers tend to have a small PID budget since each container PID is mapped to a host PID (https://kubernetes.io/docs/concepts/policy/pid-limiting/)... 6) Some of those short-lived processes may be threaded, does TID count as using a PID? (I honestly don't know how that maps these days: cat /proc/sys/kernel/threads-max is 127327 WHILE pid_max is 32768?) > $ time sh -c 'i=30000; while test $((--i)) != 0; do sleep 0 & done 2>/dev/null' > real 0m19.190s > user 0m23.062s > sys 0m6.732s > > My memory is hazy on this, but IIRC kernel also actually has some > defensive code to not immediately reuse pids which just died. Other than zombie processes? Isn't it just LRU cycling through them in order? It won't reuse a PID that's still active (open filehandle and such) but once it's gone it forgets about it. It's hard to tell what kernel/pid.c is doing these days with all the namespace stuff in there, but the idr_alloc_cyclic() call just takes pid_min and pid_max as arguments...? Are you thinking of SO_REUSEADDR perhaps? > It's interesting to find out why pids are reused that fast on the > affected system. The list above is not remotely exhaustive, it's just what came to mind. I have no idea what horrific combination of systemd and ruby might decide to spawn a process to handle every dbus event or run an RPC service via inetd, but I try not to assume it won't happen either. (I never know what ELSE the system is doing...) > Meanwhile: what "timeout" is doing is it tries to get out > of the way of the PROG to be launched so that timeout's parent > sees PROG (not timeout) as a child. E.g. it can send signals > to it, get waitpid notifications if PROG has been stopped > with a signal, and such. Is that how any other timeout works? On devuan: $ timeout 100 /bin/bash $ ps $PPID PID TTY STAT TIME COMMAND 28825 pts/19 S 0:00 timeout 100 /bin/bash Or for that matter: $ sudo /bin/bash # ps $PPID PID TTY STAT TIME COMMAND 28690 pts/19 S 0:00 sudo /bin/bash A lot of commands like env/nohup/chroot/linux64 exec their arguments, but that's because they do a thing up front to modify the process context and are then done. There's no "env process" lying around monitoring the child because there's nothing for it to do. When there IS something left to do: $ strace /bin/bash 2>/dev/null ps $PPID PID TTY STAT TIME COMMAND 29428 pts/19 S+ 0:00 strace /bin/bash It's generally gonna stay the parent because the parent/child process relationship with zombie sigchild delivery is the traditional unix mechanism to avoids PID reuse races. > And PROG also has no spurious "timeout" child. > "timeout" exists as an orphaned granchild. > > Let's go with a solution with fd opened to /proc/PID? *shrug* I leave you to it. Not what I did: https://github.com/landley/toybox/blob/master/toys/other/timeout.c Let's hold our nose and see what coreutils did... https://github.com/coreutils/coreutils/blob/master/src/timeout.c Looks like fork(), execvp(), and waitpid(). Standard parent/child relationship. Rob From vda.linux at googlemail.com Tue Mar 1 19:45:13 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Mar 2022 20:45:13 +0100 Subject: suspected bug in timeout command In-Reply-To: <20220301174917.eoVFB%steffen@sdaoden.eu> References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> <20220301174917.eoVFB%steffen@sdaoden.eu> Message-ID: On Tue, Mar 1, 2022 at 6:52 PM Steffen Nurpmeso wrote: > David Laight wrote in > : > |From: Denys Vlasenko > |> Sent: 01 March 2022 16:40 > |> On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: > |>> On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: > ... > |> My memory is hazy on this, but IIRC kernel also actually has some > |> defensive code to not immediately reuse pids which just died. > | > |The Linux krnel only has protection for code inside the kernel. > |Basically there is a ref-counted structure that you need to send the > |signal - not the pid itself. > |I can't quite remember whether the pid itself can be reused even before > |that structure is freed. > | > |NetBSD does guarantee not to reuse a pid for a reasonable number > |of forks after a process exits. > > ...which might be fruitless with 16-bit pids, define "reasonable". > Matt Dillon of DragonFly BSD (crond etc.) made, after implementing > some DBSD kernel optimizations (iirc), tests with statically > linked programs and... quoting myself > > i remember Matthew Dillon's post on DragonFly BSD users@[1], where > he claims 450000 execs per second for a statically linked binary, > and about 45000 execs per second for a dynamic one, with DragonFly > 5.6 on a threadripper. What's relevant is how many fork's you can do per second. Not execs. From vda.linux at googlemail.com Tue Mar 1 21:57:26 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Mar 2022 22:57:26 +0100 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko wrote: > Meanwhile: what "timeout" is doing is it tries to get out > of the way of the PROG to be launched so that timeout's parent > sees PROG (not timeout) as a child. E.g. it can send signals > to it, get waitpid notifications if PROG has been stopped > with a signal, and such. > > And PROG also has no spurious "timeout" child. > "timeout" exists as an orphaned granchild. > > Let's go with a solution with fd opened to /proc/PID? This little test: int fd = open("/proc/self", O_RDONLY); int parent = getpid(); int pid = fork(); if (pid) { //parent sleep(1); exit(0); } sleep(2); printf("openat:%d\n", openat(fd, ".", O_RDONLY)); while (openat(fd, ".", O_RDONLY) == -1) continue; and a separate "spawn 40k 'sleep 0.03'" loop seems to indicate that openat(fd, ".") on the exited /proc/PID fails, and continues to fail even if another process with this PID exists again (pid was reused). This would make it impossible that this "does process exist?" test hooks on a different process with the same pid: while (1) { sleep(1); if (--timeout <= 0) break; - if (kill(pid, 0)) { + tfd = openat(fd, ".", O_RDONLY); + if (tfd == -1) { /* process is gone */ return EXIT_SUCCESS; } + close(tfd); } It would still be possible for the watched process to exit right before "timeout" decided to SIGTERM it, another process to fork and reuse this pid, and get this SIGTERM instead. From David.Laight at ACULAB.COM Tue Mar 1 22:15:53 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Tue, 1 Mar 2022 22:15:53 +0000 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: From: Denys Vlasenko > Sent: 01 March 2022 21:57 > > On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko wrote: > > Meanwhile: what "timeout" is doing is it tries to get out > > of the way of the PROG to be launched so that timeout's parent > > sees PROG (not timeout) as a child. E.g. it can send signals > > to it, get waitpid notifications if PROG has been stopped > > with a signal, and such. > > > > And PROG also has no spurious "timeout" child. > > "timeout" exists as an orphaned granchild. > > > > Let's go with a solution with fd opened to /proc/PID? > > This little test: > > int fd = open("/proc/self", O_RDONLY); > int parent = getpid(); > int pid = fork(); > if (pid) { //parent > sleep(1); > exit(0); > } > sleep(2); > printf("openat:%d\n", openat(fd, ".", O_RDONLY)); > while (openat(fd, ".", O_RDONLY) == -1) > continue; > > and a separate "spawn 40k 'sleep 0.03'" loop > seems to indicate that openat(fd, ".") on the exited > /proc/PID fails, and continues to fail > even if another process with this PID exists > again (pid was reused). Which kernel? That may not fail on pre-pidfd kernels. There were some discussions on the linux kernel mailing list that I half followed. But it is probably a lot better that anything else at least for the current kernels that people are probably going to use. (Apart from those of us who have to build release binaries on old systems in order that customers can run them on the old distros they like to use....) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From David.Laight at ACULAB.COM Tue Mar 1 22:24:49 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Tue, 1 Mar 2022 22:24:49 +0000 Subject: suspected bug in timeout command In-Reply-To: <20220301174917.eoVFB%steffen@sdaoden.eu> References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> <20220301174917.eoVFB%steffen@sdaoden.eu> Message-ID: <3c1a02d162c34e908af85ac008a87877@AcuMS.aculab.com> From: Steffen Nurpmeso > Sent: 01 March 2022 17:49 ... > > David Laight wrote in > : > |From: Denys Vlasenko > |> Sent: 01 March 2022 16:40 > |> On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: > |>> On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: > ... > |> My memory is hazy on this, but IIRC kernel also actually has some > |> defensive code to not immediately reuse pids which just died. > | > |The Linux krnel only has protection for code inside the kernel. > |Basically there is a ref-counted structure that you need to send the > |signal - not the pid itself. > |I can't quite remember whether the pid itself can be reused even before > |that structure is freed. > | > |NetBSD does guarantee not to reuse a pid for a reasonable number > |of forks after a process exits. > > ...which might be fruitless with 16-bit pids, define "reasonable". Nothing stops pids going beyond 16 bits. (Apart from some of the very old emulations.) Much like nothing really requires the pid allocator to even start allocating linearly (after giving init pid 1) - but that is rather expected. I can't remember at which point it went above 32767. Was over 20 years ago when I wrote it :-) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From vda.linux at googlemail.com Tue Mar 1 22:40:13 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Mar 2022 23:40:13 +0100 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: On Tue, Mar 1, 2022 at 11:15 PM David Laight wrote: > From: Denys Vlasenko > > and a separate "spawn 40k 'sleep 0.03'" loop > > seems to indicate that openat(fd, ".") on the exited > > /proc/PID fails, and continues to fail > > even if another process with this PID exists > > again (pid was reused). > > Which kernel? > That may not fail on pre-pidfd kernels. > There were some discussions on the linux kernel mailing list > that I half followed. 4.12.0-0.rc3.git0.2.fc27.x86_64 From David.Laight at ACULAB.COM Tue Mar 1 23:02:48 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Tue, 1 Mar 2022 23:02:48 +0000 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: <7fead8c6f7174ba98276efe08198def4@AcuMS.aculab.com> From: Denys Vlasenko > Sent: 01 March 2022 22:40 > > On Tue, Mar 1, 2022 at 11:15 PM David Laight wrote: > > From: Denys Vlasenko > > > and a separate "spawn 40k 'sleep 0.03'" loop > > > seems to indicate that openat(fd, ".") on the exited > > > /proc/PID fails, and continues to fail > > > even if another process with this PID exists > > > again (pid was reused). > > > > Which kernel? > > That may not fail on pre-pidfd kernels. > > There were some discussions on the linux kernel mailing list > > that I half followed. > > 4.12.0-0.rc3.git0.2.fc27.x86_64 Reasonably old then. I could check on a 3.10 RHEL7 kernel. But any busybox fix is likely to run on a newish kernel. Not some old distro kernel. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From steffen at sdaoden.eu Tue Mar 1 23:23:43 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Mar 2022 00:23:43 +0100 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> <20220301174917.eoVFB%steffen@sdaoden.eu> Message-ID: <20220301232343._3G--%steffen@sdaoden.eu> Denys Vlasenko wrote in : |On Tue, Mar 1, 2022 at 6:52 PM Steffen Nurpmeso wrote: |> David Laight wrote in |> : |>|From: Denys Vlasenko |>|> Sent: 01 March 2022 16:40 |>|> On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: |>|>> On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: |> ... |>|> My memory is hazy on this, but IIRC kernel also actually has some |>|> defensive code to not immediately reuse pids which just died. |>| |>|The Linux krnel only has protection for code inside the kernel. |>|Basically there is a ref-counted structure that you need to send the |>|signal - not the pid itself. |>|I can't quite remember whether the pid itself can be reused even before |>|that structure is freed. |>| |>|NetBSD does guarantee not to reuse a pid for a reasonable number |>|of forks after a process exits. |> |> ...which might be fruitless with 16-bit pids, define "reasonable". |> Matt Dillon of DragonFly BSD (crond etc.) made, after implementing |> some DBSD kernel optimizations (iirc), tests with statically |> linked programs and... quoting myself |> |> i remember Matthew Dillon's post on DragonFly BSD users@[1], where |> he claims 450000 execs per second for a statically linked binary, |> and about 45000 execs per second for a dynamic one, with DragonFly |> 5.6 on a threadripper. | |What's relevant is how many fork's you can do per second. Not execs. mumble --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Tue Mar 1 23:47:37 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Mar 2022 00:47:37 +0100 Subject: suspected bug in timeout command In-Reply-To: <3c1a02d162c34e908af85ac008a87877@AcuMS.aculab.com> References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> <20220301174917.eoVFB%steffen@sdaoden.eu> <3c1a02d162c34e908af85ac008a87877@AcuMS.aculab.com> Message-ID: <20220301234737.02o58%steffen@sdaoden.eu> David Laight wrote in <3c1a02d162c34e908af85ac008a87877 at AcuMS.aculab.com>: |From: Steffen Nurpmeso |> Sent: 01 March 2022 17:49 |> David Laight wrote in |> : |>|From: Denys Vlasenko |>|> Sent: 01 March 2022 16:40 |>|> On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: |>|>> On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: |> ... |>|> My memory is hazy on this, but IIRC kernel also actually has some |>|> defensive code to not immediately reuse pids which just died. |>| |>|The Linux krnel only has protection for code inside the kernel. |>|Basically there is a ref-counted structure that you need to send the |>|signal - not the pid itself. |>|I can't quite remember whether the pid itself can be reused even before |>|that structure is freed. |>| |>|NetBSD does guarantee not to reuse a pid for a reasonable number |>|of forks after a process exits. |> |> ...which might be fruitless with 16-bit pids, define "reasonable". | |Nothing stops pids going beyond 16 bits. |(Apart from some of the very old emulations.) |Much like nothing really requires the pid allocator to even start |allocating linearly (after giving init pid 1) - but that is |rather expected. | |I can't remember at which point it went above 32767. |Was over 20 years ago when I wrote it :-) Ah, kernel. Not my league then :-) (I knew the (Linux) sysctl/proc entry, but it is unchanged here.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rob at landley.net Wed Mar 2 06:01:39 2022 From: rob at landley.net (Rob Landley) Date: Wed, 2 Mar 2022 00:01:39 -0600 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> <20220301174917.eoVFB%steffen@sdaoden.eu> Message-ID: <8cadbcc2-0b42-b8d2-ba97-c0186a7f4fd4@landley.net> On 3/1/22 1:45 PM, Denys Vlasenko wrote: > On Tue, Mar 1, 2022 at 6:52 PM Steffen Nurpmeso wrote: >> David Laight wrote in >> : >> |From: Denys Vlasenko >> |> Sent: 01 March 2022 16:40 >> |> On Tue, Feb 15, 2022 at 12:31 PM Rob Landley wrote: >> |>> On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: >> ... >> |> My memory is hazy on this, but IIRC kernel also actually has some >> |> defensive code to not immediately reuse pids which just died. >> | >> |The Linux krnel only has protection for code inside the kernel. >> |Basically there is a ref-counted structure that you need to send the >> |signal - not the pid itself. >> |I can't quite remember whether the pid itself can be reused even before >> |that structure is freed. >> | >> |NetBSD does guarantee not to reuse a pid for a reasonable number >> |of forks after a process exits. >> >> ...which might be fruitless with 16-bit pids, define "reasonable". >> Matt Dillon of DragonFly BSD (crond etc.) made, after implementing >> some DBSD kernel optimizations (iirc), tests with statically >> linked programs and... quoting myself >> >> i remember Matthew Dillon's post on DragonFly BSD users@[1], where >> he claims 450000 execs per second for a statically linked binary, >> and about 45000 execs per second for a dynamic one, with DragonFly >> 5.6 on a threadripper. > > What's relevant is how many fork's you can do per second. Not execs. Back when Ingo Molnar was cleaning up the thread spawn/exit code in the kernel I vaguely remember he benchmarked his last optimization pass at 2 million/second on some big SMP system, but that was quite a while ago (I want to say 2004?) It was the eventual follow-up to this line of optimization work: https://lwn.net/Articles/8131/ Of course all those did was call clone() and immediately exit(), and it was threads not processes so avoided most of the VM setup work and copying the file descriptor table and so on. (And was before the current namespace stuff.) Rob From rob at landley.net Wed Mar 2 06:13:07 2022 From: rob at landley.net (Rob Landley) Date: Wed, 2 Mar 2022 00:13:07 -0600 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: <5b28f318-b5a6-dd7f-00c8-1cd06fe5903d@landley.net> On 3/1/22 4:15 PM, David Laight wrote: > From: Denys Vlasenko >> Sent: 01 March 2022 21:57 >> >> On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko wrote: >> > Meanwhile: what "timeout" is doing is it tries to get out >> > of the way of the PROG to be launched so that timeout's parent >> > sees PROG (not timeout) as a child. E.g. it can send signals >> > to it, get waitpid notifications if PROG has been stopped >> > with a signal, and such. >> > >> > And PROG also has no spurious "timeout" child. >> > "timeout" exists as an orphaned granchild. >> > >> > Let's go with a solution with fd opened to /proc/PID? >> >> This little test: >> >> int fd = open("/proc/self", O_RDONLY); >> int parent = getpid(); >> int pid = fork(); >> if (pid) { //parent >> sleep(1); >> exit(0); >> } >> sleep(2); >> printf("openat:%d\n", openat(fd, ".", O_RDONLY)); >> while (openat(fd, ".", O_RDONLY) == -1) >> continue; >> >> and a separate "spawn 40k 'sleep 0.03'" loop >> seems to indicate that openat(fd, ".") on the exited >> /proc/PID fails, and continues to fail >> even if another process with this PID exists >> again (pid was reused). > > Which kernel? > That may not fail on pre-pidfd kernels. Nah, nothing to do with that. If you have a file descriptor open to anything under /proc/$PID then the reference count on the corresponding task struct can't go to zero so the bit doesn't get cleared in the table. The dirfd still being open pins it the same way a filehandle to a deleted file pins the inode... Last I checked (many moons ago) there was a bitmask of active processes that could be quickly checked for next empty bit and updated with lockless compare-and-swap assembly magic (hence the O(1) part). That's why max_pid defaults to 4096*8, it's one page. (I followed the O(1) rewrites when they went in, and some of the early container work, but that was 10 years ago now...) I still think it's silly to spend extra effort to make busybox timeout work differently than anybody else's timeout, but it's Denys' codebase... Rob From rafdev at dinapo.li Wed Mar 2 07:45:07 2022 From: rafdev at dinapo.li (Raffaello D. Di Napoli) Date: Wed, 2 Mar 2022 02:45:07 -0500 Subject: suspected bug in timeout command In-Reply-To: References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> Message-ID: <3311ef5f-c219-2735-a3d0-85b6acddabd7@dinapo.li> On 3/1/22 16:57, Denys Vlasenko wrote: > On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko > wrote: >> Meanwhile: what "timeout" is doing is it tries to get out >> of the way of the PROG to be launched so that timeout's parent >> sees PROG (not timeout) as a child. E.g. it can send signals >> to it, get waitpid notifications if PROG has been stopped >> with a signal, and such. >> >> And PROG also has no spurious "timeout" child. >> "timeout" exists as an orphaned granchild. That doesn?t seem to be a concern for coreutils, according to Rob?s inspection. (I haven?t looked, but I?ll assume they still do signal forwarding and everything that can be done cheaply.) Isn?t it a goal of BB to avoid unnecessary divergence from coreutils? >> Let's go with a solution with fd opened to /proc/PID? I?d think simplifying the implementation and bringing it closer to coreutils? would be more in line with BB?s goals, instead of making it larger and more complicated (especially considering how counter-intuitive it is already, despite being fairly small). Also, that would add dependency on procfs being mounted (and configured in the kernel ;) > It would still be possible for the watched process to exit > right before "timeout" decided to SIGTERM it, > another process to fork and reuse this pid, and get > this SIGTERM instead. That seems? undesirable, if even less likely than the original issue. -- Raf From mconrad at intellitree.com Wed Mar 2 08:50:24 2022 From: mconrad at intellitree.com (Michael Conrad) Date: Wed, 02 Mar 2022 08:50:24 +0000 (UTC) Subject: suspected bug in timeout command In-Reply-To: <3311ef5f-c219-2735-a3d0-85b6acddabd7@dinapo.li> References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> <3311ef5f-c219-2735-a3d0-85b6acddabd7@dinapo.li> Message-ID: <41846838-8690-cb37-2944-397b4df13b2e@intellitree.com> On 3/2/22 02:45, Raffaello D. Di Napoli wrote: > On 3/1/22 16:57, Denys Vlasenko wrote: >> On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko >> wrote: >>> Meanwhile: what "timeout" is doing is it tries to get out >>> of the way of the PROG to be launched so that timeout's parent >>> sees PROG (not timeout) as a child. E.g. it can send signals >>> to it, get waitpid notifications if PROG has been stopped >>> with a signal, and such. >>> >>> And PROG also has no spurious "timeout" child. >>> "timeout" exists as an orphaned granchild. > > That doesn?t seem to be a concern for coreutils, according to Rob?s > inspection. (I haven?t looked, but I?ll assume they still do signal > forwarding and everything that can be done cheaply.) Isn?t it a goal > of BB to avoid unnecessary divergence from coreutils? > > >>> Let's go with a solution with fd opened to /proc/PID? > > I?d think simplifying the implementation and bringing it closer to > coreutils? would be more in line with BB?s goals, instead of making it > larger and more complicated (especially considering how > counter-intuitive it is already, despite being fairly small). It might be worth mentioning that busybox can't conform to coreutils unless it does remain the parent process, because of this detail: (from coreutils' timeout man page) > If the command times out, and --preserve-status is not set, then > exit with status 124.? Otherwise, exit with the status of COMMAND. timeout doesn't appear to be part of POSIX, though. From rafdev at dinapo.li Wed Mar 2 12:14:46 2022 From: rafdev at dinapo.li (Raffaello D. Di Napoli) Date: Wed, 2 Mar 2022 07:14:46 -0500 Subject: suspected bug in timeout command In-Reply-To: <41846838-8690-cb37-2944-397b4df13b2e@intellitree.com> References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> <3311ef5f-c219-2735-a3d0-85b6acddabd7@dinapo.li> <41846838-8690-cb37-2944-397b4df13b2e@intellitree.com> Message-ID: <3b0697d2-01b6-d36b-10da-32d8cf91735f@dinapo.li> On 3/2/22 03:50, Michael Conrad wrote: > On 3/2/22 02:45, Raffaello D. Di Napoli wrote: >> On 3/1/22 16:57, Denys Vlasenko wrote: >>> On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko >>> wrote: >>>> Meanwhile: what "timeout" is doing is it tries to get out >>>> of the way of the PROG to be launched so that timeout's parent >>>> sees PROG (not timeout) as a child. E.g. it can send signals >>>> to it, get waitpid notifications if PROG has been stopped >>>> with a signal, and such. >>>> >>>> And PROG also has no spurious "timeout" child. >>>> "timeout" exists as an orphaned granchild. >> >> That doesn?t seem to be a concern for coreutils, according to Rob?s >> inspection. (I haven?t looked, but I?ll assume they still do signal >> forwarding and everything that can be done cheaply.) Isn?t it a goal >> of BB to avoid unnecessary divergence from coreutils? >> >> >>>> Let's go with a solution with fd opened to /proc/PID? >> >> I?d think simplifying the implementation and bringing it closer to >> coreutils? would be more in line with BB?s goals, instead of making >> it larger and more complicated (especially considering how >> counter-intuitive it is already, despite being fairly small). > > > It might be worth mentioning that busybox can't conform to coreutils > unless it does remain the parent process, because of this detail: > (from coreutils' timeout man page) > > > If the command times out, and --preserve-status is not set, then > > exit with status 124.? Otherwise, exit with the status of COMMAND. Well, yes. I already pointed out in an earlier message I see a rewrite as unavoidable, to really fix the reported issue. By ?simplifying the implementation? now I meant redoing it so that it aligns not only with coreutils, but also with what _every single person who?s looked at it in this thread_ expected, i.e. the conventional parent/child relationship rather than a reverse grandchild/parent as it is today. > timeout doesn't appear to be part of POSIX, though. I don?t think POSIX would include verbiage that would directly impart a design to a utility other than its arguments and expectations. However BB should be compelled to avoid a design vulnerable to race conditions, regardless of whether a utility is part of POSIX or not. -- Raf From steffen at sdaoden.eu Wed Mar 2 12:59:17 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Mar 2022 13:59:17 +0100 Subject: suspected bug in timeout command In-Reply-To: <3b0697d2-01b6-d36b-10da-32d8cf91735f@dinapo.li> References: <871r0cc5vn.fsf@tarshish> <1ca50691-71fd-f810-28be-cda8c3d73da5@landley.net> <2a4c26b8-8235-a2d4-db84-644d6130ba81@dinapo.li> <3311ef5f-c219-2735-a3d0-85b6acddabd7@dinapo.li> <41846838-8690-cb37-2944-397b4df13b2e@intellitree.com> <3b0697d2-01b6-d36b-10da-32d8cf91735f@dinapo.li> Message-ID: <20220302125917.3mTLp%steffen@sdaoden.eu> Raffaello D. Di Napoli wrote in <3b0697d2-01b6-d36b-10da-32d8cf91735f at dinapo.li>: |On 3/2/22 03:50, Michael Conrad wrote: |> On 3/2/22 02:45, Raffaello D. Di Napoli wrote: |>> On 3/1/22 16:57, Denys Vlasenko wrote: |>>> On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko |>>> wrote: ... |>>>> Let's go with a solution with fd opened to /proc/PID? |>> |>> I?d think simplifying the implementation and bringing it closer to |>> coreutils? would be more in line with BB?s goals, instead of making ... |> It might be worth mentioning that busybox can't conform to coreutils |> unless it does remain the parent process, because of this detail: |> (from coreutils' timeout man page) |> |>> If the command times out, and --preserve-status is not set, then |>> exit with status 124.? Otherwise, exit with the status of COMMAND. | |Well, yes. I already pointed out in an earlier message I see a rewrite |as unavoidable, to really fix the reported issue. By ?simplifying the I just want to point out that FreeBSD has a small timeout implementation, with busybox environment (as i know it, argv parse etc) it could be even smaller. |implementation? now I meant redoing it so that it aligns not only with |coreutils, but also with what _every single person who?s looked at it in |this thread_ expected, i.e. the conventional parent/child relationship |rather than a reverse grandchild/parent as it is today. Maybe then adding PR_SET_CHILD_SUBREAPER prctl(2) (already used in busybox) would be a suggestion. ... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rmy at pobox.com Thu Mar 3 11:35:46 2022 From: rmy at pobox.com (Ron Yorston) Date: Thu, 03 Mar 2022 11:35:46 +0000 Subject: [PATCH] vi: improved handling of backspace in replace mode Message-ID: <6220a812.VAZrmlfX2YRwoUVn%rmy@pobox.com> In replace mode ('R' command) the backspace character should get special treatment: - backspace only goes back to the start of the replacement; - backspacing over replaced characters restores the original text. Prior to this commit BusyBox vi deleted the characters both before and after the cursor in replace mode. function old new delta undo_pop - 235 +235 char_insert 858 884 +26 indicate_error 81 84 +3 find_range 654 657 +3 static.text_yank 77 79 +2 do_cmd 4486 4243 -243 ------------------------------------------------------------------------------ (add/remove: 1/0 grow/shrink: 4/1 up/down: 269/-243) Total: 26 bytes Signed-off-by: Ron Yorston --- editors/vi.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/editors/vi.c b/editors/vi.c index d37cd48a3..4257c0fdc 100644 --- a/editors/vi.c +++ b/editors/vi.c @@ -224,6 +224,7 @@ #endif +#define isbackspace(c) ((c) == term_orig.c_cc[VERASE] || (c) == 8 || (c) == 127) enum { MAX_TABSTOP = 32, // sanity limit @@ -342,6 +343,7 @@ struct globals { int last_modified_count; // = -1; int cmdline_filecnt; // how many file names on cmd line int cmdcnt; // repetition count + char *rstart; // start of text in Replace mode unsigned rows, columns; // the terminal screen is this size #if ENABLE_FEATURE_VI_ASK_TERMINAL int get_rowcol_error; @@ -474,6 +476,7 @@ struct globals { #define last_modified_count (G.last_modified_count) #define cmdline_filecnt (G.cmdline_filecnt ) #define cmdcnt (G.cmdcnt ) +#define rstart (G.rstart ) #define rows (G.rows ) #define columns (G.columns ) #define crow (G.crow ) @@ -1212,7 +1215,7 @@ static char *get_input_line(const char *prompt) c = get_one_char(); if (c == '\n' || c == '\r' || c == 27) break; // this is end of input - if (c == term_orig.c_cc[VERASE] || c == 8 || c == 127) { + if (isbackspace(c)) { // user wants to erase prev char write1("\b \b"); // erase char on screen buf[--i] = '\0'; @@ -2174,8 +2177,16 @@ static char *char_insert(char *p, char c, int undo) // insert the char c at 'p' p += 1 + stupid_insert(p, ' '); } #endif - } else if (c == term_orig.c_cc[VERASE] || c == 8 || c == 127) { // Is this a BS - if (p > text) { + } else if (isbackspace(c)) { + if (cmd_mode == 2) { + // special treatment for backspace in Replace mode + if (p > rstart) { + p--; +#if ENABLE_FEATURE_VI_UNDO + undo_pop(); +#endif + } + } else if (p > text) { p--; p = text_hole_delete(p, p, ALLOW_UNDO_QUEUED); // shrink buffer 1 char } @@ -3703,9 +3714,9 @@ static void do_cmd(int c) undo_queue_commit(); } else { if (1 <= c || Isprint(c)) { - if (c != 27) - dot = yank_delete(dot, dot, PARTIAL, YANKDEL, ALLOW_UNDO); // delete char - dot = char_insert(dot, c, ALLOW_UNDO_CHAIN); // insert new char + if (c != 27 && !isbackspace(c)) + dot = yank_delete(dot, dot, PARTIAL, YANKDEL, ALLOW_UNDO); + dot = char_insert(dot, c, ALLOW_UNDO_CHAIN); } goto dc1; } @@ -4264,6 +4275,7 @@ static void do_cmd(int c) dc5: cmd_mode = 2; undo_queue_commit(); + rstart = dot; break; case KEYCODE_DELETE: if (dot < end - 1) -- 2.35.1 From stuff at decentral.ch Thu Mar 3 17:59:41 2022 From: stuff at decentral.ch (Tim Tassonis) Date: Thu, 3 Mar 2022 18:59:41 +0100 Subject: Question about isolating and re-using code from busybox Message-ID: <5af2a288-7ce0-aa20-e1dc-607bec2c64d1@decentral.ch> Hi all I've written a package manager in C for my distro where packages are basically gzipped cpio (newc type) archives. I'm currently using the libarchive library in the program for extraction, which works well, but is quite a big dependency. So, as busybox handles those archives well (I tested it), I though it would be nice to get rid of libarchive and use the code from busybox. As my package manager is GPL, too, there should also be no licensing issues. However, I have not dug too deep into the busybox code yet and just wanted to ask whether someone knows if this is a good idea, e.g. how much work it would be to isolate the needed parts for use in my code. Has anybody else here ever done a similar thing, or is there maybe even a document giving a rough idea about what has to be considered or how to go about that the easiest? Sorry if this post is considered off-topic, I just though maybe someone has a quick answer that will save me some work. Bye Tim From logout at free.fr Fri Mar 4 06:48:58 2022 From: logout at free.fr (Emmanuel Deloget) Date: Fri, 4 Mar 2022 07:48:58 +0100 Subject: Question about isolating and re-using code from busybox In-Reply-To: <5af2a288-7ce0-aa20-e1dc-607bec2c64d1@decentral.ch> References: <5af2a288-7ce0-aa20-e1dc-607bec2c64d1@decentral.ch> Message-ID: Hello Tim, it seems to me that it should not be that complicated, as the tar handling code is mostly encapsulated into a library of its own. See https://git.busybox.net/busybox/tree/archival/libarchive for futher reference. Best regards, -- Emmanuel Deloget Le jeu. 3 mars 2022 ? 18:59, Tim Tassonis a ?crit : > > Hi all > > I've written a package manager in C for my distro where packages are > basically gzipped cpio (newc type) archives. > > I'm currently using the libarchive library in the program for > extraction, which works well, but is quite a big dependency. > > So, as busybox handles those archives well (I tested it), I though it > would be nice to get rid of libarchive and use the code from busybox. As > my package manager is GPL, too, there should also be no licensing issues. > > However, I have not dug too deep into the busybox code yet and just > wanted to ask whether someone knows if this is a good idea, e.g. how > much work it would be to isolate the needed parts for use in my code. > > Has anybody else here ever done a similar thing, or is there maybe even > a document giving a rough idea about what has to be considered or how to > go about that the easiest? > > Sorry if this post is considered off-topic, I just though maybe someone > has a quick answer that will save me some work. > > > Bye > Tim > > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From rep.dot.nop at gmail.com Fri Mar 4 13:38:06 2022 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Fri, 04 Mar 2022 14:38:06 +0100 Subject: Question about isolating and re-using code from busybox In-Reply-To: References: <5af2a288-7ce0-aa20-e1dc-607bec2c64d1@decentral.ch> Message-ID: <95068BB3-FBB2-460C-B2A3-7EEE597DC25A@gmail.com> On 4 March 2022 07:48:58 CET, Emmanuel Deloget wrote: >Hello Tim, > >it seems to me that it should not be that complicated, as the tar >handling code is mostly encapsulated into a library of its own. > >See https://git.busybox.net/busybox/tree/archival/libarchive for >futher reference. I think we provide means to build busybox as shared library. Iff this ist still in there, you could simply link against that. Of course you have to be aware that we do not guarantee a stable library API. But that said, it gets changed seldomly if at all. HTH, > >Best regards, > >-- Emmanuel Deloget > > >Le jeu. 3 mars 2022 ? 18:59, Tim Tassonis a ?crit : >> >> Hi all >> >> I've written a package manager in C for my distro where packages are >> basically gzipped cpio (newc type) archives. >> >> I'm currently using the libarchive library in the program for >> extraction, which works well, but is quite a big dependency. >> >> So, as busybox handles those archives well (I tested it), I though it >> would be nice to get rid of libarchive and use the code from busybox. As >> my package manager is GPL, too, there should also be no licensing issues. >> >> However, I have not dug too deep into the busybox code yet and just >> wanted to ask whether someone knows if this is a good idea, e.g. how >> much work it would be to isolate the needed parts for use in my code. >> >> Has anybody else here ever done a similar thing, or is there maybe even >> a document giving a rough idea about what has to be considered or how to >> go about that the easiest? >> >> Sorry if this post is considered off-topic, I just though maybe someone >> has a quick answer that will save me some work. >> >> >> Bye >> Tim >> >> >> _______________________________________________ >> busybox mailing list >> busybox at busybox.net >> http://lists.busybox.net/mailman/listinfo/busybox >_______________________________________________ >busybox mailing list >busybox at busybox.net >http://lists.busybox.net/mailman/listinfo/busybox From David.Laight at ACULAB.COM Fri Mar 4 13:50:38 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Fri, 4 Mar 2022 13:50:38 +0000 Subject: Question about isolating and re-using code from busybox In-Reply-To: <95068BB3-FBB2-460C-B2A3-7EEE597DC25A@gmail.com> References: <5af2a288-7ce0-aa20-e1dc-607bec2c64d1@decentral.ch> <95068BB3-FBB2-460C-B2A3-7EEE597DC25A@gmail.com> Message-ID: <356bcc8c51ee464f8ccccabc28d9a1c0@AcuMS.aculab.com> From: Bernhard Reutner-Fischer > Sent: 04 March 2022 13:38 > > On 4 March 2022 07:48:58 CET, Emmanuel Deloget wrote: > >Hello Tim, > > > >it seems to me that it should not be that complicated, as the tar > >handling code is mostly encapsulated into a library of its own. > > > >See https://git.busybox.net/busybox/tree/archival/libarchive for > >futher reference. > > I think we provide means to build busybox as shared library. Iff this ist still in there, you could > simply link against that. > > Of course you have to be aware that we do not guarantee a stable library API. But that said, it gets > changed seldomly if at all. I'd worry about resource leaks if the process doesn't exit after running an applet. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From vda.linux at googlemail.com Fri Mar 4 21:58:45 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Mar 2022 22:58:45 +0100 Subject: [PATCH] vi: improved handling of backspace in replace mode In-Reply-To: <6220a812.VAZrmlfX2YRwoUVn%rmy@pobox.com> References: <6220a812.VAZrmlfX2YRwoUVn%rmy@pobox.com> Message-ID: Applied, thank you On Thu, Mar 3, 2022 at 12:41 PM Ron Yorston wrote: > > In replace mode ('R' command) the backspace character should get > special treatment: > > - backspace only goes back to the start of the replacement; > - backspacing over replaced characters restores the original text. > > Prior to this commit BusyBox vi deleted the characters both before > and after the cursor in replace mode. > > function old new delta > undo_pop - 235 +235 > char_insert 858 884 +26 > indicate_error 81 84 +3 > find_range 654 657 +3 > static.text_yank 77 79 +2 > do_cmd 4486 4243 -243 > ------------------------------------------------------------------------------ > (add/remove: 1/0 grow/shrink: 4/1 up/down: 269/-243) Total: 26 bytes > > Signed-off-by: Ron Yorston > --- > editors/vi.c | 24 ++++++++++++++++++------ > 1 file changed, 18 insertions(+), 6 deletions(-) > > diff --git a/editors/vi.c b/editors/vi.c > index d37cd48a3..4257c0fdc 100644 > --- a/editors/vi.c > +++ b/editors/vi.c > @@ -224,6 +224,7 @@ > > #endif > > +#define isbackspace(c) ((c) == term_orig.c_cc[VERASE] || (c) == 8 || (c) == 127) > > enum { > MAX_TABSTOP = 32, // sanity limit > @@ -342,6 +343,7 @@ struct globals { > int last_modified_count; // = -1; > int cmdline_filecnt; // how many file names on cmd line > int cmdcnt; // repetition count > + char *rstart; // start of text in Replace mode > unsigned rows, columns; // the terminal screen is this size > #if ENABLE_FEATURE_VI_ASK_TERMINAL > int get_rowcol_error; > @@ -474,6 +476,7 @@ struct globals { > #define last_modified_count (G.last_modified_count) > #define cmdline_filecnt (G.cmdline_filecnt ) > #define cmdcnt (G.cmdcnt ) > +#define rstart (G.rstart ) > #define rows (G.rows ) > #define columns (G.columns ) > #define crow (G.crow ) > @@ -1212,7 +1215,7 @@ static char *get_input_line(const char *prompt) > c = get_one_char(); > if (c == '\n' || c == '\r' || c == 27) > break; // this is end of input > - if (c == term_orig.c_cc[VERASE] || c == 8 || c == 127) { > + if (isbackspace(c)) { > // user wants to erase prev char > write1("\b \b"); // erase char on screen > buf[--i] = '\0'; > @@ -2174,8 +2177,16 @@ static char *char_insert(char *p, char c, int undo) // insert the char c at 'p' > p += 1 + stupid_insert(p, ' '); > } > #endif > - } else if (c == term_orig.c_cc[VERASE] || c == 8 || c == 127) { // Is this a BS > - if (p > text) { > + } else if (isbackspace(c)) { > + if (cmd_mode == 2) { > + // special treatment for backspace in Replace mode > + if (p > rstart) { > + p--; > +#if ENABLE_FEATURE_VI_UNDO > + undo_pop(); > +#endif > + } > + } else if (p > text) { > p--; > p = text_hole_delete(p, p, ALLOW_UNDO_QUEUED); // shrink buffer 1 char > } > @@ -3703,9 +3714,9 @@ static void do_cmd(int c) > undo_queue_commit(); > } else { > if (1 <= c || Isprint(c)) { > - if (c != 27) > - dot = yank_delete(dot, dot, PARTIAL, YANKDEL, ALLOW_UNDO); // delete char > - dot = char_insert(dot, c, ALLOW_UNDO_CHAIN); // insert new char > + if (c != 27 && !isbackspace(c)) > + dot = yank_delete(dot, dot, PARTIAL, YANKDEL, ALLOW_UNDO); > + dot = char_insert(dot, c, ALLOW_UNDO_CHAIN); > } > goto dc1; > } > @@ -4264,6 +4275,7 @@ static void do_cmd(int c) > dc5: > cmd_mode = 2; > undo_queue_commit(); > + rstart = dot; > break; > case KEYCODE_DELETE: > if (dot < end - 1) > -- > 2.35.1 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From stuff at decentral.ch Sat Mar 5 23:55:17 2022 From: stuff at decentral.ch (Tim Tassonis) Date: Sun, 6 Mar 2022 00:55:17 +0100 Subject: Question about isolating and re-using code from busybox In-Reply-To: <95068BB3-FBB2-460C-B2A3-7EEE597DC25A@gmail.com> References: <5af2a288-7ce0-aa20-e1dc-607bec2c64d1@decentral.ch> <95068BB3-FBB2-460C-B2A3-7EEE597DC25A@gmail.com> Message-ID: On 3/4/22 14:38, Bernhard Reutner-Fischer wrote: > On 4 March 2022 07:48:58 CET, Emmanuel Deloget wrote: >> Hello Tim, >> >> it seems to me that it should not be that complicated, as the tar >> handling code is mostly encapsulated into a library of its own. >> >> See https://git.busybox.net/busybox/tree/archival/libarchive for >> futher reference. > > I think we provide means to build busybox as shared library. Iff this ist still in there, you could simply link against that. I'd really more looking at copying code over and use it statically, as I want the package manager to have as little dependencies as possible. Currently, I do a static build of libarchive and link against that. > > Of course you have to be aware that we do not guarantee a stable library API. But that said, it gets changed seldomly if at all. That would be no problem, I'm just interested in the cpio/gz bits. Bye Tim From yetanothergeek at gmail.com Sun Mar 6 03:08:46 2022 From: yetanothergeek at gmail.com (Jeff Pohlmeyer) Date: Sat, 5 Mar 2022 21:08:46 -0600 Subject: Question about isolating and re-using code from busybox In-Reply-To: <5af2a288-7ce0-aa20-e1dc-607bec2c64d1@decentral.ch> References: <5af2a288-7ce0-aa20-e1dc-607bec2c64d1@decentral.ch> Message-ID: On Thu, Mar 3, 2022 at 12:21 PM Tim Tassonis wrote: > I've written a package manager in C for my distro where packages are > basically gzipped cpio (newc type) archives. > I though it would be nice to get rid of libarchive and use the code from > busybox. Just a thought, but maybe you could rework your package manager into a busybox applet, possibly using the existing "rpm" and "dpkg" applets as a reference. - Jeff From pgf at foxharp.boston.ma.us Mon Mar 7 17:40:42 2022 From: pgf at foxharp.boston.ma.us (Paul Fox) Date: Mon, 07 Mar 2022 12:40:42 -0500 Subject: add support for PATH in crontabs Message-ID: <20220307174042.8EB362E00D1@grass.foxharp.boston.ma.us> Well, it's been about 14 years since I last contributed to busybox. I changed jobs back then, and no longer had a day-to-day need for (or time for!) improvements. But I've still used it often. Nice to see familiar names still. (Hi Denys!) Today's fix is for something that's bitten me several times over the years. busybox crond doesn't allow setting PATH within a crontab. This wouldn't be so bad, except that many distros/devices that use busybox don't provide for easy access to logging (and certainly not email!) for errors. It took me an embarrassing amount of time yesterday to figure out why my command (from $HOME/bin) wasn't running as expected, using piCorePlayer (based on Tiny Core Linux) on a Raspberry Pi. I've tested this with and without ENABLE_FEATURE_CROND_CALL_SENDMAIL, as well as resetting PATH part way through a crontab, to see that the changes only affect subsequent lines. I'm afraid I can't remember how to generate the cool automatic size diffs. The code change seems to add fewer than 100 bytes, but I also ifdefed a very old level 5 debug loop in Parsefield(), which saved over 100. So I think there's been a net shrinkage of about 30 bytes. paul =---------------------- paul fox, pgf at foxharp.boston.ma.us (arlington, ma) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-crond-implement-support-for-setting-PATH-in-crontab-.patch Type: text/x-diff Size: 4468 bytes Desc: 0001-crond-implement-support-for-setting-PATH-in-crontab-.patch URL: From peter0x44 at snopyta.org Mon Mar 7 23:42:32 2022 From: peter0x44 at snopyta.org (Peter0x44) Date: Mon, 07 Mar 2022 23:42:32 +0000 Subject: add support for PATH in crontabs In-Reply-To: <20220307174042.8EB362E00D1@grass.foxharp.boston.ma.us> References: <20220307174042.8EB362E00D1@grass.foxharp.boston.ma.us> Message-ID: > I'm afraid I can't remember how to generate the cool automatic size > diffs. The code change seems to add fewer than 100 bytes, but I also > ifdefed a very old level 5 debug loop in Parsefield(), which saved > over 100. So I think there's been a net shrinkage of about 30 bytes. Hi Paul, The size diffs are generated using `make bloatcheck` Regards, Peter D. From pgf at foxharp.boston.ma.us Tue Mar 8 21:12:54 2022 From: pgf at foxharp.boston.ma.us (Paul Fox) Date: Tue, 08 Mar 2022 16:12:54 -0500 Subject: add support for PATH in crontabs In-Reply-To: (sfid-20220307_184245_326183_567A6B13) References: <20220307174042.8EB362E00D1@grass.foxharp.boston.ma.us> (sfid-20220307_184245_326183_567A6B13) Message-ID: <20220308211254.E21A92E1177@grass.foxharp.boston.ma.us> peter0x44 wrote: > > I'm afraid I can't remember how to generate the cool automatic size > > diffs. The code change seems to add fewer than 100 bytes, but I also > > ifdefed a very old level 5 debug loop in Parsefield(), which saved > > over 100. So I think there's been a net shrinkage of about 30 bytes. > > Hi Paul, > > The size diffs are generated using `make bloatcheck` > Thanks Peter -- That confirms what I thought: function old new delta load_crontab 1043 1117 +74 .rodata 3509 3515 +6 bb_putchar_stderr 38 - -38 ParseField 507 437 -70 ------------------------------------------------------------------------------ (add/remove: 0/1 grow/shrink: 2/1 up/down: 80/-108) Total: -28 bytes text data bss dec hex filename 78292 2767 1528 82587 1429b busybox_old 78264 2767 1528 82559 1427f busybox_unstripped =---------------------- paul fox, pgf at foxharp.boston.ma.us (arlington, ma) From kmehltretter at gmail.com Tue Mar 8 22:41:04 2022 From: kmehltretter at gmail.com (Karl Mehltretter) Date: Tue, 8 Mar 2022 23:41:04 +0100 Subject: ifplugd: possible bug, monotonic clock value can be zero Message-ID: Hi, looking through the source code, I may have spotted a bug in ifplugd. The variable "delay_time" is used to hold a monotonic clock time but it is also set/compared to special value 0. In about 68 years the monotonic (32 bit int) clock arrives back at 0. If the monotonic clock starts at some other value, arriving at 0 can happen a lot sooner. For this "wrapped" value 0 case, the script will erroneously not be executed. I see two possible solutions: 1) Add back a workaround that increases the value to 1 in this case. (This solution seems to be in previous versions of busybox, before the "1970" comment was added..) However, this workaround will introduce an extra delay of 1 second. There is already some code guarded with "#if 0", but enabling this code can bring additional delays due to the (unnecessary?) sleep(1). 2) A cleaner solution would be to introduce a separate flag variable that is set/reset/checked and variable delay_time would then only be used for monotonic clock comparisons. Any comments ? Best regards, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From 8192 at wp.pl Thu Mar 10 22:39:45 2022 From: 8192 at wp.pl (jkm) Date: Thu, 10 Mar 2022 23:39:45 +0100 Subject: /sbin/init overrides HOME and TERM env vars Message-ID: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> Dear BusyBox devs, Could you take a look at this Alpine Linux issue? https://gitlab.alpinelinux.org/alpine/aports/-/issues/13578 I believe that init command from BusyBox overrides HOME and TERM environment variables that were set in boot params. As a result, the following env vars that were set in boot params: HOME=/root TERM=linux are changed to: HOME=/ TERM=vt102 I suggest to check if HOME env var is set instead of hardcoding it: putenv((char *) "HOME=/"); When it comes to TERM env var, a more sophisticated check is made: #ifdef VT_OPENQRY if (ioctl(STDIN_FILENO, VT_OPENQRY, &vtno) != 0) { /* Not a linux terminal, probably serial console. * Force the TERM setting to vt102 * if TERM is set to linux (the default) */ if (!s || strcmp(s, "linux") == 0) putenv((char*)"TERM=vt102"); # if !ENABLE_FEATURE_INIT_SYSLOG G.log_console = NULL; # endif } else #endif Maybe adding a CONFIG_CHECK_VT_OPENQRY in order to make this check optional would be a good idea? Please share your thoughts. Regards, jkm From pgf at foxharp.boston.ma.us Fri Mar 11 11:57:46 2022 From: pgf at foxharp.boston.ma.us (Paul Fox) Date: Fri, 11 Mar 2022 06:57:46 -0500 Subject: /sbin/init overrides HOME and TERM env vars In-Reply-To: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> (sfid-20220310_174638_137746_33079B1B) References: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> (sfid-20220310_174638_137746_33079B1B) Message-ID: <20220311115746.22B242E0219@grass.foxharp.boston.ma.us> I'm curious whether you can solve your problem by simply setting TERM and HOME in /etc/profile. It looks to me like it should be read, given that you've started ash with "-/bin/ash" in inittab. I haven't thought all that hard about this, but from looking at the code, and your requirements (which are surprising to me, but maybe shouldn't be), perhaps the best busybox change would be a new FEATURE_INIT_INHERIT_ENVIRONMENT, which prevents init from setting any environment at all. I assume your boot code could set PATH and SHELL as well as TERM and HOME? paul jkm wrote: > Dear BusyBox devs, > > Could you take a look at this Alpine Linux issue? > https://gitlab.alpinelinux.org/alpine/aports/-/issues/13578 > > I believe that init command from BusyBox overrides HOME and TERM > environment variables that were set in boot params. > > As a result, the following env vars that were set in boot params: > HOME=/root > TERM=linux > > are changed to: > HOME=/ > TERM=vt102 > > I suggest to check if HOME env var is set instead of hardcoding it: > > putenv((char *) "HOME=/"); > > When it comes to TERM env var, a more sophisticated check is made: > > #ifdef VT_OPENQRY > if (ioctl(STDIN_FILENO, VT_OPENQRY, &vtno) != 0) { > /* Not a linux terminal, probably serial console. > * Force the TERM setting to vt102 > * if TERM is set to linux (the default) */ > if (!s || strcmp(s, "linux") == 0) > putenv((char*)"TERM=vt102"); > # if !ENABLE_FEATURE_INIT_SYSLOG > G.log_console = NULL; > # endif > } else > #endif > > Maybe adding a CONFIG_CHECK_VT_OPENQRY in order to make this check > optional would be a good idea? > > Please share your thoughts. > > Regards, > jkm > > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox > =---------------------- paul fox, pgf at foxharp.boston.ma.us (arlington, ma) From 8192 at wp.pl Fri Mar 11 17:39:15 2022 From: 8192 at wp.pl (jkm) Date: Fri, 11 Mar 2022 18:39:15 +0100 Subject: /sbin/init overrides HOME and TERM env vars In-Reply-To: <20220311115746.22B242E0219@grass.foxharp.boston.ma.us> References: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> <20220311115746.22B242E0219@grass.foxharp.boston.ma.us> Message-ID: Dear Paul > I'm curious whether you can solve your problem by simply setting > TERM and HOME in /etc/profile. It looks to me like it should be > read, given that you've started ash with "-/bin/ash" in inittab. Of course, I have already done that, but I consider it as a temporary workaround rather than a real solution. > I haven't thought all that hard about this, but from looking at > the code, and your requirements (which are surprising to me, but > maybe shouldn't be), perhaps the best busybox change would be > a new FEATURE_INIT_INHERIT_ENVIRONMENT, which prevents init from > setting any environment at all. I assume your boot code > could set PATH and SHELL as well as TERM and HOME? HOME and TERM environment variables are crucial for other programs that init command is supposed to spawn. In my humble opinion, user should be able to pass these env vars along with boot params and expect init command to respect them. My proposal is to at least add a check if HOME env var is set and only if HOME env var is not passed, then set it to "/": /* Make sure environs is set to something sane */ - putenv((char *) "HOME=/"); + if (getenv("HOME") == NULL) + putenv((char *) "HOME=/"); + putenv((char *) bb_PATH_root_path); What do you think? Regards, jkm From pgf at foxharp.boston.ma.us Fri Mar 11 18:49:41 2022 From: pgf at foxharp.boston.ma.us (Paul Fox) Date: Fri, 11 Mar 2022 13:49:41 -0500 Subject: /sbin/init overrides HOME and TERM env vars In-Reply-To: (sfid-20220311_123941_486957_7932847E) References: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> <20220311115746.22B242E0219@grass.foxharp.boston.ma.us> (sfid-20220311_123941_486957_7932847E) Message-ID: <20220311184941.77BB32E00D1@grass.foxharp.boston.ma.us> jkm wrote: > Dear Paul > > > I'm curious whether you can solve your problem by simply setting > > TERM and HOME in /etc/profile. It looks to me like it should be > > read, given that you've started ash with "-/bin/ash" in inittab. > > Of course, I have already done that, but I consider it > as a temporary workaround rather than a real solution. Ah, okay. It feels "real" to me -- at least as "real" as spawning user shells directly from init. Why would the boot loader ever be involved in determining a home directory, or a terminal type? The boot loader's job is to run the correct kernel for the hardware -- not establish the userspace environment. Traditionally HOME is set by login, and TERM is set either by the user, or sometimes via getty. If you don't want a login prompt (understandable) then you're probably looking for something like agetty's --autologin flag, which allows you to suppress the prompting, while still using all of the usual login mechanisms. (I'm a little surprised busybox's getty doesn't already have that. > > > I haven't thought all that hard about this, but from looking at > > the code, and your requirements (which are surprising to me, but > > maybe shouldn't be), perhaps the best busybox change would be > > a new FEATURE_INIT_INHERIT_ENVIRONMENT, which prevents init from > > setting any environment at all. I assume your boot code > > could set PATH and SHELL as well as TERM and HOME? > HOME and TERM environment variables are crucial for other programs > that init command is supposed to spawn. In my humble opinion, > user should be able to pass these env vars along with boot params > and expect init command to respect them. My proposal is to at least My proposal would allow that too. And it would avoid having to add "if (!alreadyset)" checks for the other variables init sets up, when someone else asks. But clearly, your proposal would work as well. As does setting the variables in /etc/profile. ;-) paul > add a check if HOME env var is set and only if HOME env var is not > passed, then set it to "/": > > /* Make sure environs is set to something sane */ > - putenv((char *) "HOME=/"); > + if (getenv("HOME") == NULL) > + putenv((char *) "HOME=/"); > + > putenv((char *) bb_PATH_root_path); > > What do you think? > > Regards, > jkm > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox > =---------------------- paul fox, pgf at foxharp.boston.ma.us (arlington, ma) From stefan.seyfried at googlemail.com Sat Mar 12 00:42:54 2022 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Sat, 12 Mar 2022 01:42:54 +0100 Subject: /sbin/init overrides HOME and TERM env vars In-Reply-To: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> References: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> Message-ID: On 10.03.22 23:39, jkm wrote: > Dear BusyBox devs, > > Could you take a look at this Alpine Linux issue? > https://gitlab.alpinelinux.org/alpine/aports/-/issues/13578 > > I believe that init command from BusyBox overrides HOME and TERM > environment variables that were set in boot params. > > As a result, the following env vars that were set in boot params: > HOME=/root > TERM=linux Looking at the kernel code in init/main.c, it does look like HOME=/ TERM=linux is hard coded in the kernel with no way to override this from the command line. Did you check if you can actually set this to something else? > are changed to: > HOME=/ > TERM=vt102 > > I suggest to check if HOME env var is set instead of hardcoding it: > > ????putenv((char *) "HOME=/"); If I'm right, then this will always be set, so this check will not actually help you. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From 8192 at wp.pl Sat Mar 12 10:19:29 2022 From: 8192 at wp.pl (jkm) Date: Sat, 12 Mar 2022 11:19:29 +0100 Subject: /sbin/init overrides HOME and TERM env vars In-Reply-To: References: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> Message-ID: <128771cb-a5ed-f6c6-9774-e4617528d7a5@wp.pl> Dear Stefan > Looking at the kernel code in init/main.c, it does look like HOME=/ > TERM=linux is hard coded in the kernel with no way to override this from > the command line. I guess you are wrong. HOME and TERM env vars can be overriden with boot params. Anyway, if HOME=/ is hardcoded in the kernel then what is the reason for setting it in init command for the second time? putenv((char *) "HOME=/"); > Did you check if you can actually set this to something else? Yes, I did. Please read this ticket: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13578 Regards, jkm From stefan.seyfried at googlemail.com Sat Mar 12 12:00:15 2022 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Sat, 12 Mar 2022 13:00:15 +0100 Subject: /sbin/init overrides HOME and TERM env vars In-Reply-To: <128771cb-a5ed-f6c6-9774-e4617528d7a5@wp.pl> References: <17861c38-3c89-16a5-b713-f621617a3d2f@wp.pl> <128771cb-a5ed-f6c6-9774-e4617528d7a5@wp.pl> Message-ID: On 12.03.22 11:19, jkm wrote: > Dear Stefan > >> Looking at the kernel code in init/main.c, it does look like HOME=/ >> TERM=linux is hard coded in the kernel with no way to override this >> from the command line. > > I guess you are wrong. > HOME and TERM env vars can be overriden with boot params. Ok, then I was reading the kernel code wrong ;-) > Anyway, if HOME=/ is hardcoded in the kernel then what is the reason for > setting it in init command for the second time? > > ????putenv((char *) "HOME=/"); I guessed it was some (old) compatibility stuff, reaching back to kernels 0.99.x when HOME and TERM might not have been set by the kernel already ;-) >> Did you check if you can actually set this to something else? > > Yes, I did. Then I'll shut up now :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From jianbin.yang at nokia-sbell.com Mon Mar 14 12:55:55 2022 From: jianbin.yang at nokia-sbell.com (Yang, Jianbin (NSB - CN/Shanghai)) Date: Mon, 14 Mar 2022 12:55:55 +0000 Subject: How can make busybox passwd with pam_pwhistory.so for password history Message-ID: <5a5fae67e2964b3ab80c058f979018b9@nokia-sbell.com> Hello, I use busybox 1.34.1 within OpenWRT, and use libpam 1.5.1. Now I need to implement password history check. I set BUSYBOX_DEFAULT_PAM with y, then can see libpam.so library linked for libbusybox.so and passwd binary. root at OpenWrt:/# ldd /lib/libbusybox.so.1.34.1 ldd (0x7f9a121000) libpam.so.0 => /usr/lib/libpam.so.0 (0x7f9a04f000) libpam_misc.so.0 => /usr/lib/libpam_misc.so.0 (0x7f9a03b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f9a016000) libc.so => ldd (0x7f9a121000) root at OpenWrt:/# root at OpenWrt:/# ldd /bin/passwd /lib/ld-musl-aarch64.so.1 (0x7f80200000) libbusybox.so.1.34.1 => /lib/libbusybox.so.1.34.1 (0x7f8014f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f8012a000) libc.so => /lib/ld-musl-aarch64.so.1 (0x7f80200000) libpam.so.0 => /usr/lib/libpam.so.0 (0x7f80109000) libpam_misc.so.0 => /usr/lib/libpam_misc.so.0 (0x7f800f5000) I also configure "password required pam_pwhistory.so enforce_for_root remember=3" into /etc/pam.d/common-password. But password history check function isn't triggered, I also can't find opasswd file. Who can help me for what's wrong there? Thank you. Jianbin Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmy at pobox.com Fri Mar 18 11:29:07 2022 From: rmy at pobox.com (Ron Yorston) Date: Fri, 18 Mar 2022 11:29:07 +0000 Subject: [PATCH 0/2] vi: autoindent fixes Message-ID: <62346d03.OcUOw+6dz4sBhm+3%rmy@pobox.com> Still dogfooding BusyBox vi I happened upon a regression in autoindent. While investigating that I also found that the 'cc' command didn't handle autoindent properly. Fixes follow. Ron From rmy at pobox.com Fri Mar 18 11:29:53 2022 From: rmy at pobox.com (Ron Yorston) Date: Fri, 18 Mar 2022 11:29:53 +0000 Subject: [PATCH 1/2] vi: fix regression in autoindent handling In-Reply-To: <62346d03.OcUOw+6dz4sBhm+3%rmy@pobox.com> References: <62346d03.OcUOw+6dz4sBhm+3%rmy@pobox.com> Message-ID: <62346d31.okbowq+PzDxP/l6e%rmy@pobox.com> Suppose autoindent is enabled and we have a line with an initial tab where we want to split the words onto separate lines: split the words One way to do this is with the sequence 'f r;r', but in BusyBox vi the result is: split he words This is a regression introduced by commit 9659a8db1 (vi: remove autoindent from otherwise empty lines). The amount of indentation is being recorded when the 'r' command inserts a newline but isn't subsequently reset. A fix is to only record the indent when in insert or replace mode. Proper handling of the 'o' and 'O' commands then requires them to switch to insert mode before calling char_insert() to insert a newline. function old new delta char_insert 884 891 +7 do_cmd 4243 4247 +4 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/0 up/down: 11/0) Total: 11 bytes Signed-off-by: Ron Yorston --- editors/vi.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/editors/vi.c b/editors/vi.c index 4257c0fdc..e63ca60d4 100644 --- a/editors/vi.c +++ b/editors/vi.c @@ -2226,7 +2226,10 @@ static char *char_insert(char *p, char c, int undo) // insert the char c at 'p' p--; // open above, indent before newly inserted NL if (len) { - indentcol = col; + // only record indent if in insert/replace mode or for + // the 'o'/'O' commands, which are switched to insert + // mode early. + indentcol = cmd_mode != 0 ? col : 0; if (expandtab) { ntab = 0; nspc = col; @@ -4264,6 +4267,9 @@ static void do_cmd(int c) case 'o': // o- open an empty line below dot_end(); dc3: +#if ENABLE_FEATURE_VI_SETOPTS + cmd_mode = 1; // switch to insert mode early +#endif dot = char_insert(dot, '\n', ALLOW_UNDO); if (c == 'O' && !autoindent) { // done in char_insert() for 'O'+autoindent -- 2.35.1 From rmy at pobox.com Fri Mar 18 11:30:38 2022 From: rmy at pobox.com (Ron Yorston) Date: Fri, 18 Mar 2022 11:30:38 +0000 Subject: [PATCH 2/2] vi: handle autoindent in 'cc' command In-Reply-To: <62346d03.OcUOw+6dz4sBhm+3%rmy@pobox.com> References: <62346d03.OcUOw+6dz4sBhm+3%rmy@pobox.com> Message-ID: <62346d5e.4PdPKgQQU1mxqlaf%rmy@pobox.com> When the 'cc' command is invoked with autoindent enabled it should use the indent of the first line being changed. The size of the indent has to be established before char_insert() is called as the lines being changed are deleted. Introduce a new global variable, newindent, to handle this. The indentcol global is now effectively a static variable in char_insert(). function old new delta do_cmd 4247 4308 +61 vi_main 416 422 +6 char_insert 891 875 -16 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/1 up/down: 67/-16) Total: 51 bytes Signed-off-by: Ron Yorston --- editors/vi.c | 71 ++++++++++++++++++++++++++++++++++------------------ 1 file changed, 47 insertions(+), 24 deletions(-) diff --git a/editors/vi.c b/editors/vi.c index e63ca60d4..6edff0b5a 100644 --- a/editors/vi.c +++ b/editors/vi.c @@ -380,7 +380,9 @@ struct globals { char *last_search_pattern; // last pattern from a '/' or '?' search #endif #if ENABLE_FEATURE_VI_SETOPTS - int indentcol; // column of recently autoindent, 0 or -1 + int char_insert__indentcol; // column of recent autoindent or 0 + int newindent; // autoindent value for 'O'/'cc' commands + // or -1 to use indent from previous line #endif smallint cmd_error; @@ -507,7 +509,8 @@ struct globals { #define ioq_start (G.ioq_start ) #define dotcnt (G.dotcnt ) #define last_search_pattern (G.last_search_pattern) -#define indentcol (G.indentcol ) +#define char_insert__indentcol (G.char_insert__indentcol) +#define newindent (G.newindent ) #define cmd_error (G.cmd_error ) #define edit_file__cur_line (G.edit_file__cur_line) @@ -540,10 +543,11 @@ struct globals { #define INIT_G() do { \ SET_PTR_TO_GLOBALS(xzalloc(sizeof(G))); \ - last_modified_count = -1; \ + last_modified_count--; \ /* "" but has space for 2 chars: */ \ IF_FEATURE_VI_SEARCH(last_search_pattern = xzalloc(2);) \ tabstop = 8; \ + IF_FEATURE_VI_SETOPTS(newindent--;) \ } while (0) #if ENABLE_FEATURE_VI_CRASHME @@ -2112,6 +2116,7 @@ static size_t indent_len(char *p) static char *char_insert(char *p, char c, int undo) // insert the char c at 'p' { #if ENABLE_FEATURE_VI_SETOPTS +# define indentcol char_insert__indentcol size_t len; int col, ntab, nspc; #endif @@ -2140,7 +2145,8 @@ static char *char_insert(char *p, char c, int undo) // insert the char c at 'p' #if ENABLE_FEATURE_VI_SETOPTS if (autoindent) { len = indent_len(bol); - if (len && get_column(bol + len) == indentcol && bol[len] == '\n') { + col = get_column(bol + len); + if (len && col == indentcol && bol[len] == '\n') { // remove autoindent from otherwise empty line text_hole_delete(bol, bol + len - 1, undo); p = bol; @@ -2209,26 +2215,30 @@ static char *char_insert(char *p, char c, int undo) // insert the char c at 'p' showmatching(p - 1); } if (autoindent && c == '\n') { // auto indent the new line - // use indent of current/previous line - bol = indentcol < 0 ? p : prev_line(p); - len = indent_len(bol); - col = get_column(bol + len); - - if (len && col == indentcol) { - // previous line was empty except for autoindent - // move the indent to the current line - memmove(bol + 1, bol, len); - *bol = '\n'; - return p; + if (newindent < 0) { + // use indent of previous line + bol = prev_line(p); + len = indent_len(bol); + col = get_column(bol + len); + + if (len && col == indentcol) { + // previous line was empty except for autoindent + // move the indent to the current line + memmove(bol + 1, bol, len); + *bol = '\n'; + return p; + } + } else { + // for 'O'/'cc' commands add indent before newly inserted NL + if (p != end - 1) // but not for 'cc' at EOF + p--; + col = newindent; } - if (indentcol < 0) - p--; // open above, indent before newly inserted NL - - if (len) { + if (col) { // only record indent if in insert/replace mode or for - // the 'o'/'O' commands, which are switched to insert - // mode early. + // the 'o'/'O'/'cc' commands, which are switched to + // insert mode early. indentcol = cmd_mode != 0 ? col : 0; if (expandtab) { ntab = 0; @@ -2251,6 +2261,7 @@ static char *char_insert(char *p, char c, int undo) // insert the char c at 'p' } #if ENABLE_FEATURE_VI_SETOPTS indentcol = 0; +# undef indentcol #endif return p; } @@ -4219,6 +4230,9 @@ static void do_cmd(int c) case 'i': // i- insert before current char case KEYCODE_INSERT: // Cursor Key Insert dc_i: +#if ENABLE_FEATURE_VI_SETOPTS + newindent = -1; +#endif cmd_mode = 1; // start inserting undo_queue_commit(); // commit queue when cmd_mode changes break; @@ -4261,7 +4275,8 @@ static void do_cmd(int c) case 'O': // O- open an empty line above dot_begin(); #if ENABLE_FEATURE_VI_SETOPTS - indentcol = -1; + // special case: use indent of current line + newindent = get_column(dot + indent_len(dot)); #endif goto dc3; case 'o': // o- open an empty line below @@ -4384,14 +4399,22 @@ static void do_cmd(int c) if (buftype == WHOLE) { save_dot = p; // final cursor position is start of range p = begin_line(p); +#if ENABLE_FEATURE_VI_SETOPTS + if (c == 'c') // special case: use indent of current line + newindent = get_column(p + indent_len(p)); +#endif q = end_line(q); } dot = yank_delete(p, q, buftype, yf, ALLOW_UNDO); // delete word if (buftype == WHOLE) { if (c == 'c') { +#if ENABLE_FEATURE_VI_SETOPTS + cmd_mode = 1; // switch to insert mode early +#endif dot = char_insert(dot, '\n', ALLOW_UNDO_CHAIN); - // on the last line of file don't move to prev line - if (dot != (end-1)) { + // on the last line of file don't move to prev line, + // handled in char_insert() if autoindent is enabled + if (dot != (end-1) && !autoindent) { dot_prev(); } } else if (c == 'd') { -- 2.35.1 From rmy at pobox.com Tue Mar 22 14:28:19 2022 From: rmy at pobox.com (Ron Yorston) Date: Tue, 22 Mar 2022 14:28:19 +0000 Subject: [PATCH] ash,hush: use HOME for tab completion and prompts Message-ID: <6239dd03.AY3Vl2QT7DOZEDAp%rmy@pobox.com> ash and hush correctly use the value of HOME for tilde expansion. However the line editing code in libbb obtains the user's home directory by calling getpwuid(). Thus tildes in tab completion and prompts may be interpreted differently than in tilde expansion. When the line editing code is invoked from a shell make it use the shell's interpretation of tilde. This is similar to how GNU readline and bash collaborate. function old new delta get_homedir_or_NULL 29 56 +27 optschanged 119 126 +7 hush_main 1204 1211 +7 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 3/0 up/down: 41/0) Total: 41 bytes Signed-off-by: Ron Yorston --- include/libbb.h | 11 +++-------- libbb/lineedit.c | 10 +++++++++- shell/ash.c | 7 +++---- shell/hush.c | 5 ++--- 4 files changed, 17 insertions(+), 16 deletions(-) diff --git a/include/libbb.h b/include/libbb.h index 6aeec249d..abbc9ac59 100644 --- a/include/libbb.h +++ b/include/libbb.h @@ -1924,6 +1924,7 @@ unsigned size_from_HISTFILESIZE(const char *hp) FAST_FUNC; # define MAX_HISTORY 0 # endif typedef const char *get_exe_name_t(int i) FAST_FUNC; +typedef const char *sh_get_var_t(const char *name) FAST_FUNC; typedef struct line_input_t { int flags; int timeout; @@ -1937,9 +1938,8 @@ typedef struct line_input_t { # if ENABLE_SHELL_ASH || ENABLE_SHELL_HUSH /* function to fetch additional application-specific names to match */ get_exe_name_t *get_exe_name; -# define EDITING_HAS_get_exe_name 1 -# else -# define EDITING_HAS_get_exe_name 0 + /* function to fetch value of shell variable */ + sh_get_var_t *sh_get_var; # endif # endif # if MAX_HISTORY @@ -1993,11 +1993,6 @@ int read_line_input(const char* prompt, char* command, int maxsize) FAST_FUNC; read_line_input(prompt, command, maxsize) #endif -#ifndef EDITING_HAS_get_exe_name -# define EDITING_HAS_get_exe_name 0 -#endif - - #ifndef COMM_LEN # ifdef TASK_COMM_LEN enum { COMM_LEN = TASK_COMM_LEN }; diff --git a/libbb/lineedit.c b/libbb/lineedit.c index 82624757e..2d991faa2 100644 --- a/libbb/lineedit.c +++ b/libbb/lineedit.c @@ -261,6 +261,14 @@ static NOINLINE const char *get_homedir_or_NULL(void) { if (!got_user_strings) get_user_strings(); +#if ENABLE_SHELL_ASH || ENABLE_SHELL_HUSH + if (state->sh_get_var) { + const char *home = state->sh_get_var("HOME"); + if (home != NULL && home[0] != '\0') { + return home; + } + } +#endif return home_pwd_buf; } #endif @@ -861,7 +869,7 @@ static NOINLINE unsigned complete_cmd_dir_file(const char *command, int type) continue; } # endif -# if EDITING_HAS_get_exe_name +# if ENABLE_SHELL_ASH || ENABLE_SHELL_HUSH if (state->get_exe_name) { i = 0; for (;;) { diff --git a/shell/ash.c b/shell/ash.c index ef4a47afe..d29de37b7 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -9720,7 +9720,7 @@ evalpipe(union node *n, int flags) } /* setinteractive needs this forward reference */ -#if EDITING_HAS_get_exe_name +#if ENABLE_FEATURE_EDITING static const char *get_builtin_name(int i) FAST_FUNC; #endif @@ -9757,9 +9757,8 @@ setinteractive(int on) #if ENABLE_FEATURE_EDITING if (!line_input_state) { line_input_state = new_line_input_t(FOR_SHELL | WITH_PATH_LOOKUP); -# if EDITING_HAS_get_exe_name line_input_state->get_exe_name = get_builtin_name; -# endif + line_input_state->sh_get_var = lookupvar; } #endif } @@ -10262,7 +10261,7 @@ find_builtin(const char *name) return bp; } -#if EDITING_HAS_get_exe_name +#if ENABLE_FEATURE_EDITING static const char * FAST_FUNC get_builtin_name(int i) { diff --git a/shell/hush.c b/shell/hush.c index ae81f0da5..051b123e7 100644 --- a/shell/hush.c +++ b/shell/hush.c @@ -8188,7 +8188,7 @@ static const struct built_in_command *find_builtin(const char *name) return find_builtin_helper(name, bltins2, &bltins2[ARRAY_SIZE(bltins2)]); } -#if ENABLE_HUSH_JOB && EDITING_HAS_get_exe_name +#if ENABLE_HUSH_JOB && ENABLE_FEATURE_EDITING static const char * FAST_FUNC get_builtin_name(int i) { if (/*i >= 0 && */ i < ARRAY_SIZE(bltins1)) { @@ -10668,9 +10668,8 @@ int hush_main(int argc, char **argv) # if ENABLE_FEATURE_EDITING G.line_input_state = new_line_input_t(FOR_SHELL); -# if EDITING_HAS_get_exe_name G.line_input_state->get_exe_name = get_builtin_name; -# endif + G.line_input_state->sh_get_var = get_local_var_value; # endif # if ENABLE_HUSH_SAVEHISTORY && MAX_HISTORY > 0 { -- 2.35.1 From rmy at pobox.com Thu Mar 24 12:17:25 2022 From: rmy at pobox.com (Ron Yorston) Date: Thu, 24 Mar 2022 12:17:25 +0000 Subject: [PATCH v2] ash,hush: use HOME for tab completion and prompts Message-ID: <623c6155.RK5VQqFj4WDcSJvy%rmy@pobox.com> ash and hush correctly use the value of HOME for tilde expansion. However the line editing code in libbb obtains the user's home directory by calling getpwuid(). Thus tildes in tab completion and prompts may be interpreted differently than in tilde expansion. When the line editing code is invoked from a shell make it use the shell's interpretation of tilde. This is similar to how GNU readline and bash collaborate. function old new delta get_homedir_or_NULL 29 72 +43 optschanged 119 126 +7 hush_main 1204 1211 +7 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 3/0 up/down: 57/0) Total: 57 bytes v2: Always check for HOME before trying the password database: this is what GNU readline does. Signed-off-by: Ron Yorston --- include/libbb.h | 11 +++-------- libbb/lineedit.c | 12 +++++++++++- shell/ash.c | 7 +++---- shell/hush.c | 5 ++--- 4 files changed, 19 insertions(+), 16 deletions(-) diff --git a/include/libbb.h b/include/libbb.h index 6aeec249d..abbc9ac59 100644 --- a/include/libbb.h +++ b/include/libbb.h @@ -1924,6 +1924,7 @@ unsigned size_from_HISTFILESIZE(const char *hp) FAST_FUNC; # define MAX_HISTORY 0 # endif typedef const char *get_exe_name_t(int i) FAST_FUNC; +typedef const char *sh_get_var_t(const char *name) FAST_FUNC; typedef struct line_input_t { int flags; int timeout; @@ -1937,9 +1938,8 @@ typedef struct line_input_t { # if ENABLE_SHELL_ASH || ENABLE_SHELL_HUSH /* function to fetch additional application-specific names to match */ get_exe_name_t *get_exe_name; -# define EDITING_HAS_get_exe_name 1 -# else -# define EDITING_HAS_get_exe_name 0 + /* function to fetch value of shell variable */ + sh_get_var_t *sh_get_var; # endif # endif # if MAX_HISTORY @@ -1993,11 +1993,6 @@ int read_line_input(const char* prompt, char* command, int maxsize) FAST_FUNC; read_line_input(prompt, command, maxsize) #endif -#ifndef EDITING_HAS_get_exe_name -# define EDITING_HAS_get_exe_name 0 -#endif - - #ifndef COMM_LEN # ifdef TASK_COMM_LEN enum { COMM_LEN = TASK_COMM_LEN }; diff --git a/libbb/lineedit.c b/libbb/lineedit.c index 82624757e..fd9377327 100644 --- a/libbb/lineedit.c +++ b/libbb/lineedit.c @@ -259,6 +259,16 @@ static const char *get_username_str(void) static NOINLINE const char *get_homedir_or_NULL(void) { + const char *home; + +#if ENABLE_SHELL_ASH || ENABLE_SHELL_HUSH + home = state->sh_get_var ? state->sh_get_var("HOME") : getenv("HOME"); +#else + home = getenv("HOME"); +#endif + if (home != NULL && home[0] != '\0') + return home; + if (!got_user_strings) get_user_strings(); return home_pwd_buf; @@ -861,7 +871,7 @@ static NOINLINE unsigned complete_cmd_dir_file(const char *command, int type) continue; } # endif -# if EDITING_HAS_get_exe_name +# if ENABLE_SHELL_ASH || ENABLE_SHELL_HUSH if (state->get_exe_name) { i = 0; for (;;) { diff --git a/shell/ash.c b/shell/ash.c index ef4a47afe..d29de37b7 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -9720,7 +9720,7 @@ evalpipe(union node *n, int flags) } /* setinteractive needs this forward reference */ -#if EDITING_HAS_get_exe_name +#if ENABLE_FEATURE_EDITING static const char *get_builtin_name(int i) FAST_FUNC; #endif @@ -9757,9 +9757,8 @@ setinteractive(int on) #if ENABLE_FEATURE_EDITING if (!line_input_state) { line_input_state = new_line_input_t(FOR_SHELL | WITH_PATH_LOOKUP); -# if EDITING_HAS_get_exe_name line_input_state->get_exe_name = get_builtin_name; -# endif + line_input_state->sh_get_var = lookupvar; } #endif } @@ -10262,7 +10261,7 @@ find_builtin(const char *name) return bp; } -#if EDITING_HAS_get_exe_name +#if ENABLE_FEATURE_EDITING static const char * FAST_FUNC get_builtin_name(int i) { diff --git a/shell/hush.c b/shell/hush.c index ae81f0da5..051b123e7 100644 --- a/shell/hush.c +++ b/shell/hush.c @@ -8188,7 +8188,7 @@ static const struct built_in_command *find_builtin(const char *name) return find_builtin_helper(name, bltins2, &bltins2[ARRAY_SIZE(bltins2)]); } -#if ENABLE_HUSH_JOB && EDITING_HAS_get_exe_name +#if ENABLE_HUSH_JOB && ENABLE_FEATURE_EDITING static const char * FAST_FUNC get_builtin_name(int i) { if (/*i >= 0 && */ i < ARRAY_SIZE(bltins1)) { @@ -10668,9 +10668,8 @@ int hush_main(int argc, char **argv) # if ENABLE_FEATURE_EDITING G.line_input_state = new_line_input_t(FOR_SHELL); -# if EDITING_HAS_get_exe_name G.line_input_state->get_exe_name = get_builtin_name; -# endif + G.line_input_state->sh_get_var = get_local_var_value; # endif # if ENABLE_HUSH_SAVEHISTORY && MAX_HISTORY > 0 { -- 2.35.1 From d+busybox at adaptive-enterprises.com Mon Mar 28 01:30:18 2022 From: d+busybox at adaptive-enterprises.com (David Leonard) Date: Mon, 28 Mar 2022 11:30:18 +1000 (AEST) Subject: [PATCH] find: implement -ok Message-ID: <9p395o38-9o30-q397-83nn-612r2orors5s@nqncgvir-ragrecevfrf.pbz> Implements POSIX's -ok primary for find. This is the same as -exec, execpt that the user is prompted before running the command. function old new delta do_exec 782 904 +122 parse_params 3333 3363 +30 packed_usage 34437 34464 +27 .rodata 119440 119448 +8 static.params 271 275 +4 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 5/0 up/down: 191/0) Total: 191 bytes -------------- next part -------------- A non-text attachment was scrubbed... Name: ok.patch Type: text/x-diff Size: 9754 bytes Desc: URL: From d+busybox at adaptive-enterprises.com Mon Mar 28 01:32:54 2022 From: d+busybox at adaptive-enterprises.com (David Leonard) Date: Mon, 28 Mar 2022 11:32:54 +1000 (AEST) Subject: [PATCH] find: implement -nouser, -nogroup Message-ID: Implement's POSIX's -nouser and -nogroup primaries for find. -------------- next part -------------- A non-text attachment was scrubbed... Name: nouser.patch Type: text/x-diff Size: 4492 bytes Desc: URL: From walter.lozano at collabora.com Mon Mar 28 15:18:52 2022 From: walter.lozano at collabora.com (Walter Lozano) Date: Mon, 28 Mar 2022 12:18:52 -0300 Subject: [PATCH v2] Improve support for long options to grep In-Reply-To: References: <20220126141415.1029575-1-walter.lozano@collabora.com> <59592e2f08fc45f8a972359dba04ef5f@AcuMS.aculab.com> <06f9d2c1-897f-10e3-9ede-3d6513b04c89@collabora.com> <86bc00ba-ae3e-5f45-0b33-28c7bdac8f56@collabora.com> Message-ID: Hi, On 2/18/22 12:33, Walter Lozano wrote: > > > On 1/26/22 16:12, Walter Lozano wrote: >> >> >> On 1/26/22 15:38, Xabier Oneca -- xOneca wrote: >>> Hi Walter, >>> >>> ???? > There is also unnecessary duplication of source code. >>> ???? > >>> ???? > Just use a #define and C string concatenation to add the extra >>> ???? > long option strings. >>> >>> ??? Yes, I totally agree you. However I used this approach since a >>> previous >>> ??? patch I submitted was rewritten in this way [1] when applying to >>> master. >>> >>> >>> Maybe a better approach is to always use getopt32long, as it is >>> converted to getopt32 if LONG_OPTS is not enabled. Maybe Denys forgot >>> about this. >>> See libbb.h: >>> https://git.busybox.net/busybox/tree/include/libbb.h#n1351 >>> >> >> Thank you for the pointer. Yes, it looks much cleaner to always use >> getopt32long, not sure if there was some reason I'm not aware to try >> to avoid it. >> > > Denys any preference in how to handle this to move things forwards? Any suggestions in how to move this forward? Thanks in advance, Walter -- Walter Lozano Collabora Ltd.