kill builtin in ash might behave like killall

r now, I'm doing a local patch to always check char3. This is probably suboptimal yet I cannot see a better solution for this specific issue. Does any of you have a better idea? Best regards, -- Emmanuel Deloget ___ busybox mailing list busybox@bu

Re: kill builtin in ash might behave like killall

Hello, On Fri, Mar 3, 2017 at 1:44 PM, Tito wrote: > > > On 03/03/2017 01:01 PM, Emmanuel Deloget wrote: >> >> Hello, >> >> I'm using BB 1.26.2 with an heavily modified LEDE where I added >> procps-ng and sysvinit. Given that setup, I'm using

Re: kill builtin in ash might behave like killall

Hi, On Fri, Mar 3, 2017 at 3:17 PM, Kang-Che Sung wrote: > On 03/03/2017 01:01 PM, Emmanuel Deloget wrote: >> >> Hello, >> >> I'm using BB 1.26.2 with an heavily modified LEDE where I added >> procps-ng and sysvinit. Given that setup, I'm using /usr/

Re: [PATCH] add lsscsi implementation

ring to lsusb instead of lsscsi. > > >> BR, > >> //Markus - The panama-hat hacker > >> Best regards, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 1/1] makedevs: set path size to match linux

95 > should I add a comment to the affect we're assuming PATH_MAX is at > least 4096? Maybe a check is also needed? > ​Alternatively you may use the m modifier, when implemented, to auto-allocate the name pointer. ​This way you don't have to hardcode anything in the ss

Re: [PATCH] Silence misguided GCC warning about alignment issues

be an instance of the bug (according to the bug report, it's no longer reproducible in GCC trunk). Anyway, it might be a good idea to avoid unsetting the warning for one buggy GCC version :) Best regards, -- Emmanuel Deloget [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 [2] ht

Re: [PATCH] Silence misguided GCC warning about alignment issues

dian0() which in turn takes an > `uint32_t *` as first parameter. And that's where the type-punning is > broken. > > ​This would be quite weird - the static function is by definition local to the compilation unit, and the compiler cannot know about ​the content of decompress_unxz.c from xz_dec_stream.c. BR, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Silence misguided GCC warning about alignment issues

On Mon, Aug 7, 2017 at 10:37 PM, Emmanuel Deloget wrote: > > > > On Mon, Aug 7, 2017 at 9:46 PM, Johannes Schindelin > wrote: >> >> Hi Denys, >> >> On Mon, 7 Aug 2017, Denys Vlasenko wrote: >> >> > On Mon, Aug 7, 2017 at 12:09 PM,

Re: [PATCH] Silence misguided GCC warning about alignment issues

Hi Johannes On Tue, Aug 8, 2017 at 1:19 PM, Johannes Schindelin < johannes.schinde...@gmx.de> wrote: > Hi Emmanuel, > > On Mon, 7 Aug 2017, Emmanuel Deloget wrote: > > > And yes, its seems that the get_le32() macro in xz_private.h is a bit > > illegal with respect t

Re: bbox: musl versus uclibc

e the GNU counterpart implements both forward and backward regex search). I can submit that if the community is interested. BR, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.

unsvdir dies, the children are reparented to /bin/init which is, AFAIK, reaping them. I won't disagree with you (you say you have zombies all over the place) but maybe the problem - and the right fix - lies somewhere else. Best regards, -- Emmanuel Deloget _

Re: Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.

children > themselves of runsvdir. > Any process of pid 1 is expected to be the ultimate child reaper, so once runsvdir dies its children are bound to be reaped by init. That's how unix has worked for decades :) ​BR, -- Emmanuel Deloget​ ___ busybox

Re: [**EXTERNAL**] Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.

f the delivered signal is SIGCHLD - unless you install a handler for this signal. Since busybox' init does not do that, then no, sleep() will not be interrupted in that case (and you face the problem Laurent describes). > > -- Jim > > ​Best regards, -- Emmanuel Deloget​ ​[1] h

Re: [PATCH] ash: make bash_source command search current directory after PATH

many (for instance, I) expect . and source to behave the same way :) Having them behaving differently would somewhat violate the principle of least surprise :) BR, -- Emmanuel Deloget​ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: printf can't handle the '+' char in front of an integer

; long double can be very slow (emulated) and complex to support, which > might not be of concern here though. > But first and foremost nobody complained yet AFAIK. > Maybe keep it as is? Actively reject values too large for plain double > in printf(1) for now? >

Re: Regarding [PATCH] sysklogd: add -Z option to adjust message timezones

Hi Venkat, But i didn't get where *timezone *is defined and what it is contained, Can > you help us where it is defined and what it is contained. > timezone is defined in time.h and is documented in man 3 timezone. Best regards, -- Emman

Re: [PATCH] libbb/last_char_is: rewrite for smaller and faster code

) ? (char *)s : NULL; > } > In favor of const-correctness, wouldn't it be better to return a const char*? It's quite strange to promote a string to const and to a part of it that is non-const (not to mention that if you feed the function with a real const char* then the cast is not a good thing to do). > > > Fun to play with you. > > > > Cheers, > > > > Xabier Oneca_,,_ Best regards, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 4/5] httpd_indexcgi.c: Remove new lines in HTML

ity of the generated HTML for a few bytes. Of course, you're free to ignore my opinion :) Best regards, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] chrt: support for musl C library

t; if (!argv[0]) /* "-p PRIO PID [...]" */ > > > I looked at it several times, but this looks not so good. > These direct syscalls are less maintainable. > > OTOH... by the looks of it, there is no alternative? Maybe define a function or even a static inline that does the job? That should not cause any issue and it should be easier to maintain (not to mention that it could be added to libbb if needed in order to be reused in other places). On a side note, instead of checking for __linux__ only, one can also check for !__GLIBC__ as well in order to limit the use case to libraries that are not the glibc (yes, I link busybox with the glibc, which more or less defeat the purpose of busybox). #if defined(__linux__) && defined(SYS_sched_setscheduler) && !defined(__GLIBC__) > I'll probably apply it. Best regards, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: six patches from tinycore linux

Hello, On Thu, Aug 12, 2021 at 4:01 PM Ron Yorston wrote: > > Roberto A. Foglietta wrote: > >Hi Ron, > > > > what's about the other five? > * busybox-1.33.0_skip-loop-control.patch makes get_free_loop() behave as if there was no free loop devices (unconditionnaly). It would help to have some bac

Re: shell function name length, question

identifier names). [1] https://lists.gnu.org/archive/html/bug-bash/2018-11/msg00069.html [2] https://pubs.opengroup.org/onlinepubs/9699919799/ > -- > Roberto A. Foglietta > +39.349.33.30.697 Best regards, -- Emmanuel Deloget ___ busybox mailing lis

Re: [PATCH] ash: fix command name of shell scripts

I'm not sure why it does ; maybe the condition is not correct and we are not in the case where we always get comm == "exe". I did not investigate that much. Best regards, -- Emmanuel Deloget Le lun. 11 oct. 2021 à 14:24, a écrit : > > I forgot to mention that the issue isn'

Re: Question about isolating and re-using code from busybox

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

Re: [PATCH v2] seedrng: limit poolsize to 256 bytes and document flock() and fsync() usage

ing whether the random pool in in a correct state (in which case I'm not sure you shall trust this security-oriented process in the first place) the goal of seedrng is not to protect all reads from /dev/urandom, but to make sure that we have enough entropy to do the Real Work. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales) It seems to me that one might want to add a CONFIG_FAVOR_SIZE_OVER_SECURITY configuration flag. I wish to say that I'm not sure it's a good idea. Having a small busybox is a good thing, but having a too small busybox that breaks products because of bad security choices is not. Best regards, -- Emmanuel Deloget [1] https://github.com/systemd/systemd/blob/d9338387d94ad611233cf0753801eefccfda432a/src/udev/udev-watch.c#L102 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH v2] seedrng: limit poolsize to 256 bytes and document flock() and fsync() usage

Le lun. 2 mai 2022 à 03:31, Denys Vlasenko a écrit : > > On Sun, May 1, 2022 at 6:35 PM Emmanuel Deloget wrote: > > > > - RNG is seeded and credited using file A. > > > > - File A is unlinked but not fsync()d. > > > > - TLS connection does something

Re: [PATCH v2] seedrng: limit poolsize to 256 bytes and document flock() and fsync() usage

Hi, Le lun. 2 mai 2022 à 11:37, Denys Vlasenko a écrit : > > On Mon, May 2, 2022 at 8:26 AM Emmanuel Deloget wrote: > > Le lun. 2 mai 2022 à 03:31, Denys Vlasenko a > > écrit : > > > > I beg to differ, and especially on some embedded systems where the RNG >

Re: [PATCH] pw_encrypt: Add option to enable bcrypt support

e the amount of time taken. > + > INSERT > > endmenu > diff --git a/loginutils/chpasswd.c b/loginutils/chpasswd.c > index a032abbed..74673fa6f 100644 > --- a/loginutils/chpasswd.c > +++ b/loginutils/chpasswd.c > @@ -17,7 +17,8 @@ > //config: default "des" > //config: depends on PASSWD || CRYPTPW || CHPASSWD > //config: help > -//config: Possible choices are "d[es]", "m[d5]", "s[ha256]" or > "sha512". > +//config: Possible choices are "d[es]", "m[d5]", "s[ha256]", > +//config: "sha512" or "b[crypt]" (when enabled). > //applet:IF_CHPASSWD(APPLET(chpasswd, BB_DIR_USR_SBIN, BB_SUID_DROP)) > > -- > 2.34.1 Best regards, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox