Re: [Toybox] mkroot works again, pending release.

2020-10-25 Thread Patrick Oppenlander
On Mon, Oct 26, 2020 at 12:56 PM Rob Landley  wrote:
>
> On 10/25/20 7:57 PM, Patrick Oppenlander wrote:
> > On Mon, Oct 26, 2020 at 11:46 AM Rob Landley  wrote:
> >>
> >> On 10/25/20 6:39 PM, Patrick Oppenlander wrote:
> >>> On Sat, Oct 24, 2020 at 12:43 PM Rob Landley  wrote:
> 
>  On 10/20/20 11:19 PM, Rob Landley wrote:
> > On 10/20/20 10:03 PM, Patrick Oppenlander wrote:
> >> On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
> >>> So yeah, allyesconfig throws #warnings during the build for a reason. 
> >>> I forgot
> >>> people test like that.
> >>
> >> Well that was a lucky coincidence then.
> >>
> >> I initially observed the issue on my ARMv7-M NOMMU target.
> >> "allyesconfig" was the closest hammer to get a toybox build with sh on
> >> my host, and just happened to also show the same behaviour.
> >>
> >> Thanks for looking into it.
> >
> > I do need to fix nommu subshells, yes. Good bug report. But fixing it 
> > might be
> > out of scope for this release.
> 
>  It was specifically a -c bug, nommu subshells worked fine in other 
>  contexts but
>  when nommu toysh was relaunching itself it didn't NOT parse -c so it ran 
>  that
>  same command again in the new subshell, which spawned ANOTHER subshell, 
>  which...
> 
>  Try now?
> >>>
> >>> Looks like it still isn't working.
> >>
> >> $ ./sh -c 'echo $(echo hello)'
> >> hello
> >>
> >> It is for me, with nommu support enabled? What's your test and what are 
> >> you seeing?
> >
> > Yep, with nommu support enabled, here's the steps I took:
> >
> > % git describe --tags
> > 0.8.4
> > % make defconfig
> > % make menuconfig
> >
> > switch on pending/sh
> > switch on Toybox global settings/Enable nommu...
> > save
> >
> > % make
> > % ./toybox sh -c 'echo $(echo hello)'
> >
> > gives a blank result.
>
> And does not for me, as I said, so this is insufficient reproduction sequence
> for me to see your issue.

Sorry, didn't realise that was the case.

> Architecture? Toolchain? libc? Attach your .config?

x86_64
Arch Linux
gcc 10.2.0 glibc (distro default)

I can give you a shell account on a machine running that setup if it helps.

.config attached.

Patrick


.config
Description: Binary data
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-25 Thread Rob Landley



On 10/25/20 7:57 PM, Patrick Oppenlander wrote:
> On Mon, Oct 26, 2020 at 11:46 AM Rob Landley  wrote:
>>
>> On 10/25/20 6:39 PM, Patrick Oppenlander wrote:
>>> On Sat, Oct 24, 2020 at 12:43 PM Rob Landley  wrote:

 On 10/20/20 11:19 PM, Rob Landley wrote:
> On 10/20/20 10:03 PM, Patrick Oppenlander wrote:
>> On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
>>> So yeah, allyesconfig throws #warnings during the build for a reason. I 
>>> forgot
>>> people test like that.
>>
>> Well that was a lucky coincidence then.
>>
>> I initially observed the issue on my ARMv7-M NOMMU target.
>> "allyesconfig" was the closest hammer to get a toybox build with sh on
>> my host, and just happened to also show the same behaviour.
>>
>> Thanks for looking into it.
>
> I do need to fix nommu subshells, yes. Good bug report. But fixing it 
> might be
> out of scope for this release.

 It was specifically a -c bug, nommu subshells worked fine in other 
 contexts but
 when nommu toysh was relaunching itself it didn't NOT parse -c so it ran 
 that
 same command again in the new subshell, which spawned ANOTHER subshell, 
 which...

 Try now?
>>>
>>> Looks like it still isn't working.
>>
>> $ ./sh -c 'echo $(echo hello)'
>> hello
>>
>> It is for me, with nommu support enabled? What's your test and what are you 
>> seeing?
> 
> Yep, with nommu support enabled, here's the steps I took:
> 
> % git describe --tags
> 0.8.4
> % make defconfig
> % make menuconfig
> 
> switch on pending/sh
> switch on Toybox global settings/Enable nommu...
> save
> 
> % make
> % ./toybox sh -c 'echo $(echo hello)'
> 
> gives a blank result.

And does not for me, as I said, so this is insufficient reproduction sequence
for me to see your issue.

Architecture? Toolchain? libc? Attach your .config?

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-25 Thread Patrick Oppenlander
On Mon, Oct 26, 2020 at 11:46 AM Rob Landley  wrote:
>
> On 10/25/20 6:39 PM, Patrick Oppenlander wrote:
> > On Sat, Oct 24, 2020 at 12:43 PM Rob Landley  wrote:
> >>
> >> On 10/20/20 11:19 PM, Rob Landley wrote:
> >>> On 10/20/20 10:03 PM, Patrick Oppenlander wrote:
>  On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
> > So yeah, allyesconfig throws #warnings during the build for a reason. I 
> > forgot
> > people test like that.
> 
>  Well that was a lucky coincidence then.
> 
>  I initially observed the issue on my ARMv7-M NOMMU target.
>  "allyesconfig" was the closest hammer to get a toybox build with sh on
>  my host, and just happened to also show the same behaviour.
> 
>  Thanks for looking into it.
> >>>
> >>> I do need to fix nommu subshells, yes. Good bug report. But fixing it 
> >>> might be
> >>> out of scope for this release.
> >>
> >> It was specifically a -c bug, nommu subshells worked fine in other 
> >> contexts but
> >> when nommu toysh was relaunching itself it didn't NOT parse -c so it ran 
> >> that
> >> same command again in the new subshell, which spawned ANOTHER subshell, 
> >> which...
> >>
> >> Try now?
> >
> > Looks like it still isn't working.
>
> $ ./sh -c 'echo $(echo hello)'
> hello
>
> It is for me, with nommu support enabled? What's your test and what are you 
> seeing?

Yep, with nommu support enabled, here's the steps I took:

% git describe --tags
0.8.4
% make defconfig
% make menuconfig

switch on pending/sh
switch on Toybox global settings/Enable nommu...
save

% make
% ./toybox sh -c 'echo $(echo hello)'

gives a blank result.

Patrick
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-25 Thread Rob Landley
On 10/25/20 6:39 PM, Patrick Oppenlander wrote:
> On Sat, Oct 24, 2020 at 12:43 PM Rob Landley  wrote:
>>
>> On 10/20/20 11:19 PM, Rob Landley wrote:
>>> On 10/20/20 10:03 PM, Patrick Oppenlander wrote:
 On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
> So yeah, allyesconfig throws #warnings during the build for a reason. I 
> forgot
> people test like that.

 Well that was a lucky coincidence then.

 I initially observed the issue on my ARMv7-M NOMMU target.
 "allyesconfig" was the closest hammer to get a toybox build with sh on
 my host, and just happened to also show the same behaviour.

 Thanks for looking into it.
>>>
>>> I do need to fix nommu subshells, yes. Good bug report. But fixing it might 
>>> be
>>> out of scope for this release.
>>
>> It was specifically a -c bug, nommu subshells worked fine in other contexts 
>> but
>> when nommu toysh was relaunching itself it didn't NOT parse -c so it ran that
>> same command again in the new subshell, which spawned ANOTHER subshell, 
>> which...
>>
>> Try now?
> 
> Looks like it still isn't working.

$ ./sh -c 'echo $(echo hello)'
hello

It is for me, with nommu support enabled? What's your test and what are you 
seeing?

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-25 Thread Patrick Oppenlander
On Sat, Oct 24, 2020 at 12:43 PM Rob Landley  wrote:
>
> On 10/20/20 11:19 PM, Rob Landley wrote:
> > On 10/20/20 10:03 PM, Patrick Oppenlander wrote:
> >> On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
> >>> So yeah, allyesconfig throws #warnings during the build for a reason. I 
> >>> forgot
> >>> people test like that.
> >>
> >> Well that was a lucky coincidence then.
> >>
> >> I initially observed the issue on my ARMv7-M NOMMU target.
> >> "allyesconfig" was the closest hammer to get a toybox build with sh on
> >> my host, and just happened to also show the same behaviour.
> >>
> >> Thanks for looking into it.
> >
> > I do need to fix nommu subshells, yes. Good bug report. But fixing it might 
> > be
> > out of scope for this release.
>
> It was specifically a -c bug, nommu subshells worked fine in other contexts 
> but
> when nommu toysh was relaunching itself it didn't NOT parse -c so it ran that
> same command again in the new subshell, which spawned ANOTHER subshell, 
> which...
>
> Try now?

Looks like it still isn't working.

Patrick
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-23 Thread Rob Landley
On 10/20/20 11:19 PM, Rob Landley wrote:
> On 10/20/20 10:03 PM, Patrick Oppenlander wrote:
>> On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
>>> So yeah, allyesconfig throws #warnings during the build for a reason. I 
>>> forgot
>>> people test like that.
>>
>> Well that was a lucky coincidence then.
>>
>> I initially observed the issue on my ARMv7-M NOMMU target.
>> "allyesconfig" was the closest hammer to get a toybox build with sh on
>> my host, and just happened to also show the same behaviour.
>>
>> Thanks for looking into it.
> 
> I do need to fix nommu subshells, yes. Good bug report. But fixing it might be
> out of scope for this release.

It was specifically a -c bug, nommu subshells worked fine in other contexts but
when nommu toysh was relaunching itself it didn't NOT parse -c so it ran that
same command again in the new subshell, which spawned ANOTHER subshell, which...

Try now?

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-20 Thread Patrick Oppenlander
On Wed, Oct 21, 2020 at 3:09 PM Rob Landley  wrote:
>
> On 10/20/20 10:03 PM, Patrick Oppenlander wrote:
> > On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
> >> So yeah, allyesconfig throws #warnings during the build for a reason. I 
> >> forgot
> >> people test like that.
> >
> > Well that was a lucky coincidence then.
> >
> > I initially observed the issue on my ARMv7-M NOMMU target.
> > "allyesconfig" was the closest hammer to get a toybox build with sh on
> > my host, and just happened to also show the same behaviour.
> >
> > Thanks for looking into it.
>
> I do need to fix nommu subshells, yes. Good bug report. But fixing it might be
> out of scope for this release.

No problem, happy to wait as I have a working shell.

But I do get excited whenever you mention toysh. It will allow me to
throw away another external dependency, simplify build systems,
improve build times, reduce maintenance overhead, etc. etc.

So, thanks again for working on it!

Patrick
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-20 Thread Rob Landley
On 10/20/20 10:03 PM, Patrick Oppenlander wrote:
> On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
>> So yeah, allyesconfig throws #warnings during the build for a reason. I 
>> forgot
>> people test like that.
> 
> Well that was a lucky coincidence then.
> 
> I initially observed the issue on my ARMv7-M NOMMU target.
> "allyesconfig" was the closest hammer to get a toybox build with sh on
> my host, and just happened to also show the same behaviour.
> 
> Thanks for looking into it.

I do need to fix nommu subshells, yes. Good bug report. But fixing it might be
out of scope for this release.

Thanks,

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-20 Thread Patrick Oppenlander
On Wed, Oct 21, 2020 at 1:38 PM Rob Landley  wrote:
>
>
>
> On 10/20/20 7:14 PM, Patrick Oppenlander wrote:
> > On Wed, Oct 21, 2020 at 11:02 AM Rob Landley  wrote:
> >>
> >>
> >>
> >> On 10/20/20 5:23 PM, Patrick Oppenlander wrote:
> >>> On Tue, Oct 20, 2020 at 10:58 AM Rob Landley  wrote:
> 
>  I got toysh implementing all the bits that mkroot's init script needs, 
>  so I
>  expect to cut a release in the next couple days. There's still a zillion
>  dangling threads but I should be able to park it for now.
> 
>  If anybody wants to holler about something I should fix now, this would 
>  be a
>  good time. I'm back in tokyo working on $DAYJOB again, and am likely to 
>  down
>  tools on toybox after the release for at least a couple months.
> 
>  I note that except for a couple large holes (lack of $((math)) and 
>  function()
>  support, haven't finished trap/signal/jobs, needs command line editing 
>  and
>  history) toysh is... sort of working now? Several known bugs (test suite
>  failures), but it's actually starting to be actually run real scripts. 
>  Needs
>  auditing for memory leaks, and the largest script I've thrown at it _is_ 
>  the
>  mkroot init, but... it's advanced from "don't bother" to "object of 
>  curiosity".
> 
>  Right now, useful bug reports would come in the form of "thing I could 
>  add to
>  tests/sh.test and get to later", and keep in mind I've got...
> 
>    $ wc sh.tests
>    845  3791 20673 sh.tests
> 
>  One or two of those already, not yet properly formatted into runnable 
>  regression
>  tests. (And one of the current sh.test entries HANGS because a
>  subshell-plus-redirection test fails to hand off a filehandle properly 
>  and we
>  wait forever reading from nothing, so I need to teach tests to time 
>  out...)
> 
>  Rob
> >>>
> >>> Hi Rob,
> >>>
> >>> first, thanks for all the hard work!
> >>>
> >>> I had a go at using toysh instead of busybox ash and immediately ran into 
> >>> this:
> >>>
> >>> % ./toybox sh
> >>> $ for i in $(./toybox); do echo $i; done
> >>> $
> >>
> >> It ran for me?
> >>
> >>   $ ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
> >> 211 2111355
> >>
> >>> That seems to start an interactive subshell somehow (takes two ^D's to
> >>> quit) instead of looping.
> >>
> >> Hmmm, how do I reproduce this...
> >>
> >> Rob
> >
> > Something strange is happening.
> >
> > % ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
> >   0   0   0
> >
> > Also, it takes a long time.
> >
> > % time ./toybox sh -c 'for i in $(./toybox); do echo $i; done'
> > ./toybox sh -c 'for i in $(./toybox); do echo $i; done'  0.00s user
> > 0.00s system 0% cpu 1.387 total
> >
> > Here's a what I'm doing on my end:
> >
> > % git describe --tags
> > 0.8.3-197-g9c8b4051
> >
> > % make allyesconfig
>
> Um. I haven't tested that in a couple months. (I should add a
> "CONFIG_BREAK_THE_BUILD" to that so people don't just blindly allyesconfig but
> have to switch something OFF to make it work.) Let's see...
>
> .toys/lsb/md5sum.c:86:25: fatal error: openssl/md5.h: No such file or 
> directory
>
> Doesn't compile for me, of course. I don't have the openssl libraries
> installed... The "ar.c" in my pending is half-finished, so is hd.c, mkdosfs,
> strace, I have a typo in my readelf...
>
> Ok, I have repeated your hang.
>
> Ah, of course, you enabled TOYBOX_FORCE_NOMMU which is using the "vfork, exec
> yourself, and send state data through a pipe" path because nommu systems 
> haven't
> got fork(). I haven't tested that path since June, it's conceptually all there
> but hasn't been regression tested and has like 3 pending TODO items.
>
> The problem here is it's sending the whole -c line and not the contents of the
> $(./toybox) to the child process, so it's  looping forking off another child
> process lots of times. :)
>
> So yeah, allyesconfig throws #warnings during the build for a reason. I forgot
> people test like that.

Well that was a lucky coincidence then.

I initially observed the issue on my ARMv7-M NOMMU target.
"allyesconfig" was the closest hammer to get a toybox build with sh on
my host, and just happened to also show the same behaviour.

Thanks for looking into it.

Patrick
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-20 Thread Rob Landley



On 10/20/20 7:14 PM, Patrick Oppenlander wrote:
> On Wed, Oct 21, 2020 at 11:02 AM Rob Landley  wrote:
>>
>>
>>
>> On 10/20/20 5:23 PM, Patrick Oppenlander wrote:
>>> On Tue, Oct 20, 2020 at 10:58 AM Rob Landley  wrote:

 I got toysh implementing all the bits that mkroot's init script needs, so I
 expect to cut a release in the next couple days. There's still a zillion
 dangling threads but I should be able to park it for now.

 If anybody wants to holler about something I should fix now, this would be 
 a
 good time. I'm back in tokyo working on $DAYJOB again, and am likely to 
 down
 tools on toybox after the release for at least a couple months.

 I note that except for a couple large holes (lack of $((math)) and 
 function()
 support, haven't finished trap/signal/jobs, needs command line editing and
 history) toysh is... sort of working now? Several known bugs (test suite
 failures), but it's actually starting to be actually run real scripts. 
 Needs
 auditing for memory leaks, and the largest script I've thrown at it _is_ 
 the
 mkroot init, but... it's advanced from "don't bother" to "object of 
 curiosity".

 Right now, useful bug reports would come in the form of "thing I could add 
 to
 tests/sh.test and get to later", and keep in mind I've got...

   $ wc sh.tests
   845  3791 20673 sh.tests

 One or two of those already, not yet properly formatted into runnable 
 regression
 tests. (And one of the current sh.test entries HANGS because a
 subshell-plus-redirection test fails to hand off a filehandle properly and 
 we
 wait forever reading from nothing, so I need to teach tests to time out...)

 Rob
>>>
>>> Hi Rob,
>>>
>>> first, thanks for all the hard work!
>>>
>>> I had a go at using toysh instead of busybox ash and immediately ran into 
>>> this:
>>>
>>> % ./toybox sh
>>> $ for i in $(./toybox); do echo $i; done
>>> $
>>
>> It ran for me?
>>
>>   $ ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
>> 211 2111355
>>
>>> That seems to start an interactive subshell somehow (takes two ^D's to
>>> quit) instead of looping.
>>
>> Hmmm, how do I reproduce this...
>>
>> Rob
> 
> Something strange is happening.
> 
> % ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
>   0   0   0
> 
> Also, it takes a long time.
> 
> % time ./toybox sh -c 'for i in $(./toybox); do echo $i; done'
> ./toybox sh -c 'for i in $(./toybox); do echo $i; done'  0.00s user
> 0.00s system 0% cpu 1.387 total
> 
> Here's a what I'm doing on my end:
> 
> % git describe --tags
> 0.8.3-197-g9c8b4051
> 
> % make allyesconfig

Um. I haven't tested that in a couple months. (I should add a
"CONFIG_BREAK_THE_BUILD" to that so people don't just blindly allyesconfig but
have to switch something OFF to make it work.) Let's see...

.toys/lsb/md5sum.c:86:25: fatal error: openssl/md5.h: No such file or 
directory

Doesn't compile for me, of course. I don't have the openssl libraries
installed... The "ar.c" in my pending is half-finished, so is hd.c, mkdosfs,
strace, I have a typo in my readelf...

Ok, I have repeated your hang.

Ah, of course, you enabled TOYBOX_FORCE_NOMMU which is using the "vfork, exec
yourself, and send state data through a pipe" path because nommu systems haven't
got fork(). I haven't tested that path since June, it's conceptually all there
but hasn't been regression tested and has like 3 pending TODO items.

The problem here is it's sending the whole -c line and not the contents of the
$(./toybox) to the child process, so it's  looping forking off another child
process lots of times. :)

So yeah, allyesconfig throws #warnings during the build for a reason. I forgot
people test like that.

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-20 Thread Patrick Oppenlander
On Wed, Oct 21, 2020 at 11:02 AM Rob Landley  wrote:
>
>
>
> On 10/20/20 5:23 PM, Patrick Oppenlander wrote:
> > On Tue, Oct 20, 2020 at 10:58 AM Rob Landley  wrote:
> >>
> >> I got toysh implementing all the bits that mkroot's init script needs, so I
> >> expect to cut a release in the next couple days. There's still a zillion
> >> dangling threads but I should be able to park it for now.
> >>
> >> If anybody wants to holler about something I should fix now, this would be 
> >> a
> >> good time. I'm back in tokyo working on $DAYJOB again, and am likely to 
> >> down
> >> tools on toybox after the release for at least a couple months.
> >>
> >> I note that except for a couple large holes (lack of $((math)) and 
> >> function()
> >> support, haven't finished trap/signal/jobs, needs command line editing and
> >> history) toysh is... sort of working now? Several known bugs (test suite
> >> failures), but it's actually starting to be actually run real scripts. 
> >> Needs
> >> auditing for memory leaks, and the largest script I've thrown at it _is_ 
> >> the
> >> mkroot init, but... it's advanced from "don't bother" to "object of 
> >> curiosity".
> >>
> >> Right now, useful bug reports would come in the form of "thing I could add 
> >> to
> >> tests/sh.test and get to later", and keep in mind I've got...
> >>
> >>   $ wc sh.tests
> >>   845  3791 20673 sh.tests
> >>
> >> One or two of those already, not yet properly formatted into runnable 
> >> regression
> >> tests. (And one of the current sh.test entries HANGS because a
> >> subshell-plus-redirection test fails to hand off a filehandle properly and 
> >> we
> >> wait forever reading from nothing, so I need to teach tests to time out...)
> >>
> >> Rob
> >
> > Hi Rob,
> >
> > first, thanks for all the hard work!
> >
> > I had a go at using toysh instead of busybox ash and immediately ran into 
> > this:
> >
> > % ./toybox sh
> > $ for i in $(./toybox); do echo $i; done
> > $
>
> It ran for me?
>
>   $ ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
> 211 2111355
>
> > That seems to start an interactive subshell somehow (takes two ^D's to
> > quit) instead of looping.
>
> Hmmm, how do I reproduce this...
>
> Rob

Something strange is happening.

% ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
  0   0   0

Also, it takes a long time.

% time ./toybox sh -c 'for i in $(./toybox); do echo $i; done'
./toybox sh -c 'for i in $(./toybox); do echo $i; done'  0.00s user
0.00s system 0% cpu 1.387 total

Here's a what I'm doing on my end:

% git describe --tags
0.8.3-197-g9c8b4051

% make allyesconfig

% make

% ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
  0   0   0

Maybe an strace will help?

% strace ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
execve("./toybox", ["./toybox", "sh", "-c", "for i in $(./toybox); do
echo $i"...], 0x7ffce2875758 /* 72 vars */) = 0
brk(NULL)   = 0x55ec73215000
arch_prctl(0x3001 /* ARCH_??? */, 0x7fff376bc750) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=282302, ...}) = 0
mmap(NULL, 282302, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8135308000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\23\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=14440, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f8135306000
mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8135301000
mmap(0x7f8135302000, 4096, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f8135302000
mmap(0x7f8135303000, 4096, PROT_READ,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f8135303000
mmap(0x7f8135304000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f8135304000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libcrypt.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0
\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=186112, ...}) = 0
mmap(NULL, 221736, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81352ca000
mmap(0x7f81352cc000, 73728, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f81352cc000
mmap(0x7f81352de000, 102400, PROT_READ,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7f81352de000
mmap(0x7f81352f7000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2c000) = 0x7f81352f7000
mmap(0x7f81352f9000, 29224, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81352f9000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libresolv.so.2", O_RDONLY|O_CLOEXEC) 

Re: [Toybox] mkroot works again, pending release.

2020-10-20 Thread Rob Landley



On 10/20/20 5:23 PM, Patrick Oppenlander wrote:
> On Tue, Oct 20, 2020 at 10:58 AM Rob Landley  wrote:
>>
>> I got toysh implementing all the bits that mkroot's init script needs, so I
>> expect to cut a release in the next couple days. There's still a zillion
>> dangling threads but I should be able to park it for now.
>>
>> If anybody wants to holler about something I should fix now, this would be a
>> good time. I'm back in tokyo working on $DAYJOB again, and am likely to down
>> tools on toybox after the release for at least a couple months.
>>
>> I note that except for a couple large holes (lack of $((math)) and function()
>> support, haven't finished trap/signal/jobs, needs command line editing and
>> history) toysh is... sort of working now? Several known bugs (test suite
>> failures), but it's actually starting to be actually run real scripts. Needs
>> auditing for memory leaks, and the largest script I've thrown at it _is_ the
>> mkroot init, but... it's advanced from "don't bother" to "object of 
>> curiosity".
>>
>> Right now, useful bug reports would come in the form of "thing I could add to
>> tests/sh.test and get to later", and keep in mind I've got...
>>
>>   $ wc sh.tests
>>   845  3791 20673 sh.tests
>>
>> One or two of those already, not yet properly formatted into runnable 
>> regression
>> tests. (And one of the current sh.test entries HANGS because a
>> subshell-plus-redirection test fails to hand off a filehandle properly and we
>> wait forever reading from nothing, so I need to teach tests to time out...)
>>
>> Rob
> 
> Hi Rob,
> 
> first, thanks for all the hard work!
> 
> I had a go at using toysh instead of busybox ash and immediately ran into 
> this:
> 
> % ./toybox sh
> $ for i in $(./toybox); do echo $i; done
> $

It ran for me?

  $ ./toybox sh -c 'for i in $(./toybox); do echo $i; done' | wc
211 2111355

> That seems to start an interactive subshell somehow (takes two ^D's to
> quit) instead of looping.

Hmmm, how do I reproduce this...

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] mkroot works again, pending release.

2020-10-20 Thread Patrick Oppenlander
On Tue, Oct 20, 2020 at 10:58 AM Rob Landley  wrote:
>
> I got toysh implementing all the bits that mkroot's init script needs, so I
> expect to cut a release in the next couple days. There's still a zillion
> dangling threads but I should be able to park it for now.
>
> If anybody wants to holler about something I should fix now, this would be a
> good time. I'm back in tokyo working on $DAYJOB again, and am likely to down
> tools on toybox after the release for at least a couple months.
>
> I note that except for a couple large holes (lack of $((math)) and function()
> support, haven't finished trap/signal/jobs, needs command line editing and
> history) toysh is... sort of working now? Several known bugs (test suite
> failures), but it's actually starting to be actually run real scripts. Needs
> auditing for memory leaks, and the largest script I've thrown at it _is_ the
> mkroot init, but... it's advanced from "don't bother" to "object of 
> curiosity".
>
> Right now, useful bug reports would come in the form of "thing I could add to
> tests/sh.test and get to later", and keep in mind I've got...
>
>   $ wc sh.tests
>   845  3791 20673 sh.tests
>
> One or two of those already, not yet properly formatted into runnable 
> regression
> tests. (And one of the current sh.test entries HANGS because a
> subshell-plus-redirection test fails to hand off a filehandle properly and we
> wait forever reading from nothing, so I need to teach tests to time out...)
>
> Rob

Hi Rob,

first, thanks for all the hard work!

I had a go at using toysh instead of busybox ash and immediately ran into this:

% ./toybox sh
$ for i in $(./toybox); do echo $i; done
$

That seems to start an interactive subshell somehow (takes two ^D's to
quit) instead of looping.

Patrick
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


[Toybox] mkroot works again, pending release.

2020-10-19 Thread Rob Landley
I got toysh implementing all the bits that mkroot's init script needs, so I
expect to cut a release in the next couple days. There's still a zillion
dangling threads but I should be able to park it for now.

If anybody wants to holler about something I should fix now, this would be a
good time. I'm back in tokyo working on $DAYJOB again, and am likely to down
tools on toybox after the release for at least a couple months.

I note that except for a couple large holes (lack of $((math)) and function()
support, haven't finished trap/signal/jobs, needs command line editing and
history) toysh is... sort of working now? Several known bugs (test suite
failures), but it's actually starting to be actually run real scripts. Needs
auditing for memory leaks, and the largest script I've thrown at it _is_ the
mkroot init, but... it's advanced from "don't bother" to "object of curiosity".

Right now, useful bug reports would come in the form of "thing I could add to
tests/sh.test and get to later", and keep in mind I've got...

  $ wc sh.tests
  845  3791 20673 sh.tests

One or two of those already, not yet properly formatted into runnable regression
tests. (And one of the current sh.test entries HANGS because a
subshell-plus-redirection test fails to hand off a filehandle properly and we
wait forever reading from nothing, so I need to teach tests to time out...)

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net