On Thu, 21 Sept 2023 at 09:24, Roberto A. Foglietta
wrote:
>
> I consider this interface one of the brokest seen in the UNIX domain
> ever. Despite this, I am reluctant in wishing that it would be
> completely changed because breaking the back-compatibility with
> 30years old pro
On Sat, 23 Sept 2023 at 16:54, Roberto A. Foglietta
wrote:
>
> On Sat, 23 Sept 2023 at 16:30, Steffen Nurpmeso wrote:
> >
> > Roberto A. Foglietta wrote in
> > :
> > |On Thu, 21 Sept 2023 at 20:05, Steffen Nurpmeso
> > wrote:
> > |>|
On Sat, 23 Sept 2023 at 16:30, Steffen Nurpmeso wrote:
>
> Roberto A. Foglietta wrote in
> :
> |On Thu, 21 Sept 2023 at 20:05, Steffen Nurpmeso wrote:
> |>|IMHO, I vote for /sys rather than /proc/debug. The capability to
>
> There already _is_ a debugfs i
On Thu, 21 Sept 2023 at 20:05, Steffen Nurpmeso wrote:
> |IMHO, I vote for /sys rather than /proc/debug. The capability to
>
> There is /proc/sys/kernel/random.
>
> |directly handle the system entropy pool should be an Admin privilege
> |even before being a debug option. As well as disable
On Thu, 21 Sept 2023 at 02:35, Steffen Nurpmeso wrote:
>
> Steffen Nurpmeso wrote in
> <20230919222910.pn44y%stef...@sdaoden.eu>:
> |Laurent Bercot wrote in
> | :
> ||>|IIRC writing to /dev/urandom doesn't do what you want it to do.
> ||>|You have to use an ioctl() to actually set entropy.
>
On Wed, 20 Sept 2023 at 18:52, Didier Kryn wrote:
>
> It is the rationale of everything /run to be lost on reboot.
>
Thanks Didier, for having highlighted this. Currently, everything is
on RAM in the embedded system I am working on.
___
busybox
On Wed, 20 Sept 2023 at 07:06, Roberto A. Foglietta
wrote:
> Finally, repeat one more time all together: ioctls() are bad because
> they are a trick to workaround the limitation of "in UNIX everything
> is a file" principle and like every principle it establish some
>
On Tue, 19 Sept 2023 at 16:20, Laurent Bercot wrote:
>
>
> Oh boy. Is it that time of the year again already?
Vote for me, it will be Christmas all the days of the year! *ROTFL*
On Tue, 19 Sept 2023 at 23:58, Laurent Bercot wrote:
>
> >|IIRC writing to /dev/urandom doesn't do what you want
On Tue, 19 Sept 2023 at 14:06, Roberto A. Foglietta
wrote:
>
> On Tue, 19 Sept 2023 at 13:30, Rob Landley wrote:
> As the first init instruction or as the last kernel boot operation, is
> THE general answer also when it is not the solution. Some systems need
> a more d
On Tue, 19 Sept 2023 at 14:06, Roberto A. Foglietta
wrote:
>
> On Tue, 19 Sept 2023 at 13:30, Rob Landley wrote:
> dmesg | sha512sum > /dev/urandom
Oops, sorry because the sha512sum command-line prints a human readable
16 chars based string
dmesg | pigz -4c | dd bs=64 skip=1 &g
On Tue, 19 Sept 2023 at 13:30, Rob Landley wrote:
>
> Modern "software" entropy collection is mostly timing jitter collected very
> slowly as the system runs. The theory for embedded devices was if you have
> some
> writeable space in the device you save a few hundred bytes of /dev/urandom
>
On Tue, 19 Sept 2023 at 03:25, Michael Conrad
wrote:
> On 9/18/23 06:14, Guillermo Rodriguez Garcia wrote:
>
> everything is compressed with gzip -7. This is the worst scenario.
>> However, even in the worst scenario due to gzip one single bit of
>> difference in the input generates a completely
On Mon, 18 Sept 2023 at 11:20, Guillermo Rodriguez Garcia
wrote:
>
>> # RAF: seeding the urandom device with some data and a few bits of
>> randomness.
>> # The randomness is put at the beginning of some text data, which is
>> going
>> # to be compressed. It is expected that the whole
On Mon, 18 Sept 2023 at 10:11, Jeff Pohlmeyer wrote:
>
> On Mon, Sep 18, 2023 at 2:42 AM Roberto A. Foglietta
> wrote:
>
> > In case the /dev/urandom initialisation is a necessity (or a best
> > practice), does it make sense to add it into busybox as an option
Hi all,
I am investigating the Android init procedure (one version, one
device, not in general) and I found an interesting line about the
initialization of the /dev/urandom (seeding, I suppose).
cat /proc/cmdline > /dev/urandom
Therefore, I developed a more sophisticated way to do that
Hi,
I found this option in hdparm which is not supported by busybox hdparm
-F Flush the on-drive write cache buffer (older drives may
not implement this).
I did not verify the internals of hdparm -F but relying on the man
hdparm, I think that it is an interesting
On Wed, 6 Sept 2023 at 18:59, Roberto A. Foglietta
wrote:
> comw_pid()
> {
> local str
> # RAF: the /proc/$pid/comm contains the first 15 chars + ending \n
> str=$(echo -n $*| tr ' ' '\n'| sed -e "s,\(.\{15\}\).*,^\\1$,"| tr '\n'
> '|')
> str=$(grep
On Sat, 9 Sept 2023 at 17:14, Bastian Bittorf wrote:
>
> I tried to replicate your findings, but my slow embedded OpenWRT
> system (with musl libc) is so fast, that your tests always produce
> 0 seconds execution time. You are talking about nofork and cpu affinity:
About the system speed, I took
On Sun, 10 Sept 2023 at 15:07, Roberto A. Foglietta
wrote:
> Notice that the O(1, grep) vs O(N, pidof) is always present but to see
> a big difference N >> 1, like 8 or 10 for example. Using 2 for seeing
> the difference also works, but the difference can be more easily
>
On Sun, 10 Sept 2023 at 11:51, Roberto A. Foglietta
wrote:
>
> On Sun, 10 Sept 2023 at 11:41, Roberto A. Foglietta
> wrote:
> >
> > On Sat, 9 Sept 2023 at 17:14, Bastian Bittorf wrote:
> > >
> > > I tried to replicate your findings, but my slow embedd
On Sun, 10 Sept 2023 at 11:41, Roberto A. Foglietta
wrote:
>
> On Sat, 9 Sept 2023 at 17:14, Bastian Bittorf wrote:
> >
> > I tried to replicate your findings, but my slow embedded OpenWRT
> > system (with musl libc) is so fast, that your tests always produce
>
On Sat, 9 Sept 2023 at 17:14, Bastian Bittorf wrote:
>
> I tried to replicate your findings, but my slow embedded OpenWRT
> system (with musl libc) is so fast, that your tests always produce
> 0 seconds execution time.
Shows the test shell code and the results.
redfishos:/rootfs # time date
On Fri, 8 Sept 2023 at 03:46, Roberto A. Foglietta
wrote:
> The two ways to take measures showed a difference of 7 - 18% when
> n(args) = 1 and 0.7 - 1.7% when n(args) = 10. This clearly a linear
> regression which tells us that the main source of error stays in the
> accuracy of th
On Thu, 7 Sept 2023 at 09:44, Bastian Bittorf wrote:
> I understand your commands, but i do not understand
> how you are measuring the time,
The busybox time does not work for functions. A function is needed to
replicate the pidof basic behaviour otherwise the comparison can be
considered
On Wed, 6 Sept 2023 at 14:16, Roberto A. Foglietta
wrote:
>
> On Wed, 6 Sept 2023 at 12:09, Roberto A. Foglietta
> wrote:
>
> > However, execution time does not change so much
>
> Instead when multiple processes names are passed as arguments, the
> execution time gap
On Wed, 6 Sept 2023 at 12:09, Roberto A. Foglietta
wrote:
> However, execution time does not change so much
Instead when multiple processes names are passed as arguments, the
execution time gap increases even more because pidof execution time
depends on the number of arguments wh
On Wed, 6 Sept 2023 at 11:38, Roberto A. Foglietta
wrote:
> Moreover the execution of this function (preloaded into the
> environment) gives the same time consumption of the grep -E command
> without any appreciable delay.
To be fair the function should return the status like pidof
On Wed, 6 Sept 2023 at 02:38, Roberto A. Foglietta
wrote:
>
> I did not verify the code yet. However, I think that it is necessary
> to introduce a test in the NOFORK code for which as long as busybox is
> running on a single CPU, it forks otherwise follow the default pol
On Mon, 4 Sept 2023 at 21:52, Roberto A. Foglietta
wrote:
>
> Just few facts:
>
> - moving from local var=$(command) to local var; car=$(commad)
> - avoid to use pidof and pgrep but grep over /proc
> - source instead of calling a script
>
> The script time to be ready
On Mon, 4 Sept 2023 at 22:54, Roberto A. Foglietta
wrote:
>
> On Mon, 4 Sept 2023 at 21:52, Roberto A. Foglietta
> wrote:
> >
> > On Mon, 4 Sept 2023 at 18:53, Bastian Bittorf wrote:
> > >
> > > can you please give us a hint,
> > > what mak
On Mon, 4 Sept 2023 at 21:52, Roberto A. Foglietta
wrote:
>
> On Mon, 4 Sept 2023 at 18:53, Bastian Bittorf wrote:
> >
> > can you please give us a hint,
> > what makes your system special?
> > maybe several 1000 processes?
>
> Hi Bastian,
>
> on that s
On Mon, 4 Sept 2023 at 18:53, Bastian Bittorf wrote:
>
> can you please give us a hint,
> what makes your system special?
> maybe several 1000 processes?
Hi Bastian,
on that system there are 8 Arm 64bit cores 4x1.8GHz + 4x2.0Ghz put
under conservative frequency governors usually sleeping but
Hi,
just for your information:
pidof $string
pgrep $string
are sensitively slower than this one
fgrep "$string" /proc/[1-9]*/comm | cut -d/ -f3
in particular when taskset -pc 0 $$ is used, but also in general.
I can accept that my system is the root cause of this issue. Moreover,
it is not
On Thu, 10 Aug 2023 at 06:20, Roberto A. Foglietta
wrote:
> Unfortunately, this dilemma cannot be solved by simply choosing -Os
> rather than -O3 compilation flags. However, in some cases, a #define
> set from .config can decide to privilege speed versus size.
About this above, I wish
On Thu, 10 Aug 2023 at 06:20, Roberto A. Foglietta
wrote:
> Someone can update me on this part of the code, please?
By the way, there is another place in which the same choice has been taken:
->
https://github.com/robang74/tinycore-editor/blob/main/busybox/patches/busybox-1.34.0-do-not
Hi,
I am checking the status of applying these patches in the 1.36.1 version:
-> https://github.com/robang74/tinycore-editor/tree/main/busybox/patches
In particular, I found this one where the first trunk has been applied
but not the second one. Even if the second one has been evaluated.
*
Hi all,
I am dealing with busybox udhcpd and I discovered that there is not
an option that makes this daemon - especially in combination with -f
option - wait until the interface receives an IP. Something like -w,
for example.
At the moment, I solved in this way:
ExecStartPre=/bin/sh -c
On Sun, 23 Jul 2023 at 16:38, tito wrote:
>
> On Sun, 23 Jul 2023 16:17:54 +0200
> "Roberto A. Foglietta" wrote:
>
> > On Sun, 23 Jul 2023 at 13:18, tito wrote:
> > >
> > > On Sun, 23 Jul 2023 12:00:56 +0200
> > > "Roberto A. Fogliett
On Sun, 23 Jul 2023 at 13:18, tito wrote:
>
> On Sun, 23 Jul 2023 12:00:56 +0200
> "Roberto A. Foglietta" wrote:
> > >
> > > 1) multiple file handling (a must i would dare to say)
> >
> > Which is not such a problem, after all
> >
>
On Sun, 23 Jul 2023 at 11:42, tito wrote:
>
> On Sun, 23 Jul 2023 00:36:09 +0200
> "Roberto A. Foglietta" wrote:
>
> > On Sat, 22 Jul 2023 at 21:29, tito wrote:
> > >
> > > On Sat, 22 Jul 2023 19:31:28 +0200
> > > "Roberto A. Fogliet
On Sat, 22 Jul 2023 at 21:29, tito wrote:
>
> On Sat, 22 Jul 2023 19:31:28 +0200
> "Roberto A. Foglietta" wrote:
>
> > On Sat, 22 Jul 2023 at 15:40, tito wrote:
> >
> > > Hi,
> > >
> > > I'm not the maintainer so I can say nothing a
On Sat, 22 Jul 2023 at 15:40, tito wrote:
> Hi,
>
> I'm not the maintainer so I can say nothing about integration,
> I can just point out things that look strange to me and my limited knowledge.
> When I read that this code is faster vs other code as I'm a curious
> person I just try to see how
On Sat, 22 Jul 2023 at 08:02, tito wrote:
>
> Hi,
> I just adopted the test in the PERFORMANCE section of your source
>
> ** PERFORMANCES
> ***
> *
> * gcc -Wall -O3 strings.orig.c -o strings && strip strings
> * rm -f [12].txt
> *
On Sat, 22 Jul 2023 at 03:36, Roberto A. Foglietta
wrote:
>
> On Fri, 21 Jul 2023 at 22:37, tito wrote:
> >
> > On Fri, 21 Jul 2023 21:39:57 +0200
> > "Roberto A. Foglietta" wrote:
[...]
ERRATA CORRIGE
> rm -f 1.txt; cmd="cat /usr/bin/busybox
On Fri, 21 Jul 2023 at 22:37, tito wrote:
>
> On Fri, 21 Jul 2023 21:39:57 +0200
> "Roberto A. Foglietta" wrote:
>
> > To the maintainers and everyone else whom can be interested,
> >
[...]
>
> Hi,
> seems to me that the current strings busybox impl
in GPLv2, like busybox. In
its header just a raw estimation of its performance that can vary from
system to system and among different platforms but at least comparable
with the original from binutils.
Best regards, R-
/*
* (C) 2023, Roberto A. Foglietta
* Released under the GPLv2 license
Il Sab 12 Feb 2022, 14:13 David Laight ha scritto:
> From: Michael Conrad
> > Sent: 12 February 2022 12:59
> >
> > On 2/12/22 07:38, Michael Conrad wrote:
> > > Correctly using pidfd *still* requires that you be the parent process,
> > > else the child could get reaped and replaced before the
Rob.
Best regards,
--
Roberto A. Foglietta
+39.349.33.30.697
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Il giorno lun 14 feb 2022 alle ore 17:00 Roberto A. Foglietta
ha scritto:
>
> Il giorno sab 12 feb 2022 alle ore 02:41 Raffaello D. Di Napoli
> ha scritto:
> >
> >
> > On 2/11/22 16:22, Rob Landley wrote:
> > > On 2/9/22 11:12 AM, Baruch Siach wrote:
> &g
utils/timeout.c
This is the code under inspection:
grandchild:
/* Just sleep(HUGE_NUM); kill(parent) may kill wrong process! */
while (1) {
sleep(1);
if (--timeout <= 0)
break;
if (kill(parent, 0)) {
/* process is gone */
return EXIT_SUCCESS;
}
}
kill
d stand any chance of being merged
> into busybox.
>
> I'll start with my first patch which implements the netns feature to
> iplink.c.
>
Could you send the others patches in such a way we can have the whole picture?
Thanks
--
Rober
Il mar 14 set 2021, 22:01 Denys Vlasenko ha
scritto:
> On Tue, Sep 14, 2021 at 3:45 PM Roberto A. Foglietta
> wrote:
> > Il giorno mar 14 set 2021 alle ore 12:24 Denys Vlasenko
> > ha scritto:
> > > > > I am going to replace every raise_e
Il mar 14 set 2021, 20:14 Harald van Dijk ha scritto:
> On 14/09/2021 19:01, Roberto A. Foglietta wrote:
> > I got what you are saying. The unwind means the code executed after
> > setjmp returns true and that's the enviroment.
> >
> > It Is useless to unwind. No
Il mar 14 set 2021, 19:52 Harald van Dijk ha scritto:
> On 14/09/2021 17:06, Roberto A. Foglietta wrote:
> > Il giorno mar 14 set 2021 alle ore 18:01 Harald van Dijk
> > ha scritto:
> >>
> >> On 14/09/2021 11:24, Denys Vlasenko wrote:
> >>> On Tue,
Il giorno mar 14 set 2021 alle ore 18:01 Harald van Dijk
ha scritto:
>
> On 14/09/2021 11:24, Denys Vlasenko wrote:
> > On Tue, Sep 14, 2021 at 10:04 AM Roberto A. Foglietta
> > wrote:
> >> Il giorno dom 12 set 2021 alle ore 18:55 Roberto A. Foglietta
> >>
) could be replaced by exitshell() as suggested for
FUNCNAME inclusion.
As soon as EXEXIT and EXEND will be replaced by exitshell(), I will
prepare a patch to remove all references to these two exceptions.
Best regards,
--
Roberto A. Foglietta
+39.349.33.30.697
Il giorno mar 14 set 2021 alle ore 12:24 Denys Vlasenko
ha scritto:
>
> On Tue, Sep 14, 2021 at 10:04 AM Roberto A. Foglietta
> wrote:
> > Il giorno dom 12 set 2021 alle ore 18:55 Roberto A. Foglietta
> > ha scritto:
> >
> > > I am going to replace every ra
Il giorno dom 12 set 2021 alle ore 18:55 Roberto A. Foglietta
ha scritto:
> I am going to replace every raise_exception(EXEXIT) with exitshell()
> and to remove the EXEXIT altogether. It seems to me that EXEXIT does
> not add any value but complicates things. What's your opinion on t
Il giorno dom 12 set 2021 alle ore 13:37 Roberto A. Foglietta
ha scritto:
>
> Il giorno dom 12 set 2021 alle ore 13:31 Harald van Dijk
> ha scritto:
> >
> > On 12/09/2021 11:21, Ron Yorston wrote:
> > > When the user tries to exit an interactive shell with stoppe
topped, the shell does not detect this. bash, ksh, yash do pick up on
> it and prevent the shell from exiting. (zsh is special and notifies that
> cat was suspended as it happens.)
I suggest this change:
exitcmd(int argc UNUSED_PARAM, char **argv)
{
if
Il giorno dom 12 set 2021 alle ore 09:15 Ron Yorston ha
scritto:
>
> Roberto A. Foglietta wrote:
> > I found a case in which IMHO the ash does not behave as expected by a shell.
> > When there is a stopped job the exit command is ignored but it should not.
> > At le
lines responsible for the issue
// if (stoppedjobs())
// return 0;
I suggest removing those two lines of code.
In attachment to this email the test I did with the results for bash
and busybox ash.
Best regards,
--
Roberto A. Foglietta
+39.349.33.30.697
## TEST B
Il giorno mar 7 set 2021 alle ore 21:43 Denys Vlasenko
ha scritto:
>
> On Tue, Sep 7, 2021 at 6:26 PM Roberto A. Foglietta
> wrote:
> >
> > Thus, using zero the busybox test suite needs to be updated.
>
> If you send a patch with "lineno = 0", this patc
keep coherent with the current busybox ash
output then the patch above should be cleaned by some .rights changes.
Best Regards,
--
Roberto A. Foglietta
+39.349.33.30.697
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Il giorno dom 5 set 2021 alle ore 23:52 Roberto A. Foglietta
ha scritto:
>
> Il giorno dom 5 set 2021 alle ore 21:40 Denys Vlasenko
> ha scritto:
> >
> > IIRC you want to fix other LINENO problems anyway,
> > like incorrect handling of it in functions?
>
>
Hi all,
in some configurations the busybox ash print-out on stderr a message
regarding suid drop.
Unfortunately, this message is trapped by the tests handler run-all
and all tests fails.
The attached patch fixes the problem.
Best regards,
--
Roberto A. Foglietta
+39.349.33.30.697
busybox
nstead of 0 [*]
evalstring(minusc, EV_EXIT);
}
[*] bash has zero, original ash has one.
Best regards,
--
Roberto A. Foglietta
+39.349.33.30.697
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
egression in my ash error management branch.
Best regards,
--
Roberto A. Foglietta
+39.349.33.30.697
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Il giorno dom 5 set 2021 alle ore 21:40 Denys Vlasenko
ha scritto:
>
> On Sun, Sep 5, 2021 at 5:53 PM Roberto A. Foglietta
> wrote:
> > Il giorno dom 5 set 2021 alle ore 17:03 Denys Vlasenko
> > ha scritto:
> >
> > > @@ -468,7 +470,11 @@ struct globa
C.
> > For sure the first one is needed to have exitshell().
>
> All LINENO problems are to be fixed in a separate patch -
ok
> IIRC you want to fix other LINENO problems anyway,
> like incorrect handling of it in functions?
Nope, at the moment all problems are fixed. AFAIK. Patch v021 is my
final one, IMHO.
Unless, you show unacceptable downsides in replacing raise_exception()
with exitshell().
I hope this helps,
--
Roberto A. Foglietta
+39.349.33.30.697
exit_VS_exce.diff
Description: Binary data
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Il giorno dom 5 set 2021 alle ore 17:03 Denys Vlasenko
ha scritto:
> @@ -468,7 +470,11 @@ struct globals_misc {
> /* indicates specified signal received */
> uint8_t gotsig[NSIG - 1]; /* offset by 1: "signal" 0 is meaningless */
> uint8_t may_have_traps; /* 0: definitely
Il giorno dom 5 set 2021 alle ore 14:57 Roberto A. Foglietta <
roberto.foglie...@gmail.com> ha scritto:
>
> PATCH UPDATE + TEST SUITE
>
> Here in attachment the patch v020 with the changes suggested with its
> integrated test suite in a separate patch
>
Sorry, there was
Il giorno dom 5 set 2021 alle ore 04:05 Denys Vlasenko <
vda.li...@googlemail.com> ha scritto:
> On Sat, Sep 4, 2021 at 8:39 PM Roberto A. Foglietta <
> roberto.foglie...@gmail.com> wrote:
> >
> > > Can this be reasonably split up, or it is too interrelated?
Il giorno sab 4 set 2021 alle ore 16:36 Denys Vlasenko <
vda.li...@googlemail.com> ha scritto:
> On Mon, Aug 30, 2021 at 8:55 AM Roberto A. Foglietta
> wrote:
> > Hi Denis,
> >
> > supported by the experience of Harald, I developed this patch far
> e
Il giorno lun 30 ago 2021 alle ore 20:24 Angelo Dureghello <
ang...@kernel-space.org> ha scritto:
> Hi Roberto,
>
> On 30/08/21 7:43 PM, Roberto A. Foglietta wrote:
> > Hi Angelo,
> >
> > try these two, they do halt and reboot by-passing the busybox
>
these two, they do halt and reboot by-passing the busybox
https://github.com/robang74/tinycore-editor/blob/main/tinycore/changes/shutdown.sh
https://github.com/robang74/tinycore-editor/blob/main/tinycore/changes/reboot.sh
Best regards,
--
Roberto A. Foglietta
+39.349.33.30.697
___
. Both could be also
retrieved at this link
https://github.com/robang74/tinycore-editor/tree/main/busybox/patches
busybox-1.33.1-error-management-extension-for-ash-v019.patch
https://github.com/robang74/tinycore-editor/tree/main/busybox/tests
Best regards,
--
Roberto A. Foglietta
This thread is moved on the next: shell script error management in ash
(ready for integration).
Please join the new thread.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Il giorno mar 24 ago 2021 alle ore 23:42 Harald van Dijk
ha scritto:
> On 24/08/2021 11:10, Roberto A. Foglietta wrote:
> > Thanks again for your insightfulness.
> >
> > I reverted back to the previous situation when I was resetting the
> > recursive fla
Il giorno mar 24 ago 2021 alle ore 00:00 Harald van Dijk
ha scritto:
> On 23/08/2021 11:50, Roberto A. Foglietta wrote:
> > Il giorno lun 23 ago 2021 alle ore 11:15 Harald van Dijk
> > mailto:har...@gigawatt.nl>> ha scritto:
> >
> > On 23/08/2021
Il giorno lun 23 ago 2021 alle ore 02:37 Denys Vlasenko <
vda.li...@googlemail.com> ha scritto:
>
> Fixed in git. Thank you for the bug report.
>
I confirm you that it fixed and behaves like supposed to be.
Sorry, ignore my last message.
Thank you,
--
Roberto A. Foglietta
+3
Il giorno lun 23 ago 2021 alle ore 11:15 Harald van Dijk
ha scritto:
> On 23/08/2021 10:09, Roberto A. Foglietta wrote:
> > Il giorno lun 23 ago 2021 alle ore 10:45 Harald van Dijk
> > mailto:har...@gigawatt.nl>> ha scritto:
> >
> > On 23/08/2021 09:16, Robe
Il giorno lun 23 ago 2021 alle ore 10:45 Harald van Dijk
ha scritto:
> On 23/08/2021 09:16, Roberto A. Foglietta wrote:
> > IMHO, syntax error should be an exit condition either.
>
> I would not have a problem with you changing the shell to ensure syntax
> errors always t
Il giorno lun 23 ago 2021 alle ore 10:16 Roberto A. Foglietta <
roberto.foglie...@gmail.com> ha scritto:
>
> For the moment we can still assume that in busybox all exceptions are
> deadly.
>
>
More specifically, we do not need to assume that every exception are deadly
Il giorno lun 23 ago 2021 alle ore 02:55 Harald van Dijk
ha scritto:
> On 22/08/2021 01:23, Harald van Dijk wrote:
> > On 22/08/2021 00:31, Roberto A. Foglietta wrote:
> >> Il giorno sab 21 ago 2021 alle ore 23:33 Harald van Dijk
> >> mailto:har...@gigawatt.nl>&g
to ro it is fine
otherwise not.
>
> Fixed in git. Thank you for the bug report.
>
Please consider my patch as-is for what I wrote above.
Thank you,
--
Roberto A. Foglietta
+39.349.33.30.697
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Il giorno dom 22 ago 2021 alle ore 16:33 Roberto A. Foglietta <
roberto.foglie...@gmail.com> ha scritto:
> Il giorno dom 22 ago 2021 alle ore 15:53 Roberto A. Foglietta <
> roberto.foglie...@gmail.com> ha scritto:
>
>> Hi Harald and Denys,
>>
>> - it add
Il giorno dom 22 ago 2021 alle ore 15:53 Roberto A. Foglietta <
roberto.foglie...@gmail.com> ha scritto:
> Hi Harald and Denys,
>
> - it add a printf to highlight a possible memory leak in a not-exit
> condition (**)
>
The patch without printf can be found here:
https:
and code analysis then before applying it in
production the printf line should be replaced with a void line It is
easy to find: grep -n printf $patch
Thank you Harald for your support and thank you Denis in advance for your
code analysis.
Cheers,
--
Roberto A. Foglietta
+39.349.33.30.697
Il giorno dom 22 ago 2021 alle ore 02:23 Harald van Dijk
ha scritto:
> On 22/08/2021 00:31, Roberto A. Foglietta wrote:
> > Il giorno sab 21 ago 2021 alle ore 23:33 Harald van Dijk
> > mailto:har...@gigawatt.nl>> ha scritto:
> >
> > Hi again,
> &g
Il giorno sab 21 ago 2021 alle ore 23:33 Harald van Dijk
ha scritto:
> Hi again,
>
> Another bug: the exit status is not preserved.
>
> Consider
>
>busybox ash -c 'trap "echo ERR" ERR; false; echo $?'
>
> This prints ERR, and then 0, because the echo command completed
> successfully. It is
Il giorno dom 22 ago 2021 alle ore 00:12 Denys Vlasenko <
vda.li...@googlemail.com> ha scritto:
> Roberto, please send the patches as a series, not all in one email.
> It's difficult to review them otherwise.
Denys, as soon as I completed the work in tandem with Harald I will send a
single
is prints nothing. With your patches, this prints ERR. That
> is, the ERR action is executed when it should not be. The command that
> failed here is one that had its exit status tested.
The 10th patch reworks the trap ERR in such a way which is compliant with
bash for both these cases.
Thank yo
Il giorno sab 21 ago 2021 alle ore 14:38 Harald van Dijk
ha scritto:
> Hi,
>
> In bash, the ERR trap is documented as triggering in under the exact
> same conditions that 'set -e' would cause the shell to abort. This is
> not what you have implemented, you have implemented it as triggering
>
Il giorno ven 20 ago 2021 alle ore 18:46 Roberto A. Foglietta <
roberto.foglie...@gmail.com> ha scritto:
> Il giorno ven 20 ago 2021 alle ore 17:49 Harald van Dijk <
> har...@gigawatt.nl> ha scritto:
>
>> On 20/08/2021 16:31, Roberto A. Foglietta wrote:
>> > I
Il giorno ven 20 ago 2021 alle ore 17:49 Harald van Dijk
ha scritto:
> On 20/08/2021 16:31, Roberto A. Foglietta wrote:
> > Il giorno ven 20 ago 2021 alle ore 16:36 Harald van Dijk
> > mailto:har...@gigawatt.nl>> ha scritto:
> >
Il giorno ven 20 ago 2021 alle ore 16:36 Harald van Dijk
ha scritto:
>
>cat >shrc <:
>:
>:
>EOF
>ENV=shrc ./busybox ash -ic 'echo LINENO=$LINENO'
>3
>
> I can understand (and would
> personally prefer) outputting 1 / 2 for the first case and 1 for the
> second case.
Il giorno ven 20 ago 2021 alle ore 15:21 Harald van Dijk
ha scritto:
> On 20/08/2021 13:48, Roberto A. Foglietta wrote:
> >
> > Il giorno ven 20 ago 2021 alle ore 14:05 Harald van Dijk
> > mailto:har...@gigawatt.nl>> ha scritto:
> >
> > Hi,
> >
&g
Il giorno ven 20 ago 2021 alle ore 14:05 Harald van Dijk
ha scritto:
> Hi,
>
> Replying to the new thread as requested.
>
> About the global LINENO: having thought about it more, I don't think it
> makes sense to special-case trap actions. This is something that should
> be done for all
Il giorno gio 19 ago 2021 alle ore 09:09 Bernhard Reutner-Fischer <
rep.dot@gmail.com> ha scritto:
> On Thu, 19 Aug 2021 03:12:17 +0200
> "Roberto A. Foglietta" wrote:
>
> > Hi all,
> >
> > I want to compile menuconfig with ncursesw in /usr/loc
1 - 100 of 173 matches
Mail list logo
