Denys, I have no word of complaint about you changing busybox... I think it's a great project, and I approve of the direction it's moving in.
I'm just highlighting the fact that no improvement you do to the current build can fix what I encounter on existing computers. On top of that I find that for simplicity I need a constant shell environment I really don't want to face trying to write scripts without functions.. and as far as I can see the ash syntax is incompatible with the bash one, and vice-versa. So at this moment I'm tempted to bundle busybox with my application, and get it to use only the bundled busybox. That gives me back the control I need. D In article <[email protected]>, [email protected] (Denys Vlasenko) wrote: > *From:* Denys Vlasenko <[email protected]> > *To:* [email protected], [email protected] > *CC:* [email protected], [email protected] > *Date:* Fri, 4 Feb 2011 23:24:25 +0100 > > On Thursday 03 February 2011 11:45, David Collier wrote: > > Denys, > > > > your suggestion above for fixing tar to work with stdin is > > wonderful - > > and I'm sure it will work. > > > > But it illustrates the different world-views that you and I have. > > In an > > illuminating way. > > > > You think/speak as if busybox is infinitely mutable, and an issue > > can be > > changed by improving it. > > Of course, that's what developers do: they change software. > > However, I do not change busybox in a random way. I generally try > to make > busybox tools more similar to tools available on "big Linux", > so that people can use the same scripts and expect the same > behavior. > > In this particular example, "tar -T -" is supported by GNU tar, > therefore I made busbox tar to do the same. > > > > I think of the busybox version I find on > > existing computers as part of the fixed background, and am > > looking at > > ways to work with any/all of them without changing them. > > > > If I need to do something to my application, I would like it to > > work on > > > > the systems I have in the field running feature-lite busybox > > 0.60 ( Good Lord ) > > the ATNGW-clones which run 1.13 non-desktop > > the dev sys on my desk running 1.17 desktop > > the PCEngines board which has Debian, > > but for some reason also has busybox 1.10 lying around. > > > > I have now understood that > > O different revisions of busybox have made different choices > > - the standard columns output by ps have changed over time. > > O even the same issue level of busybox may have been built with > > or without many options - so the ps command may, or may not, > > support the -o option to customise it's output. > > Therefore I can't depend on the field order, nor on the presence > > of an > > option to alter it > > I've solved that by poking around in /proc ... but heaven help > > us, that > > may not even exist on some computers, so I will need yet another > > level of > > complexity for full portability :-( > > Well, world is full of computer systems, and their upgrade cycles > can be wildly different (and sometimes really haphazard). > > > > Without risking breaking those boxes, which are sitting in fields > > in Peru > > and other places, and I CANNOT afford to go and reboot them. > > > > Now you might WELL say to me that I'm looking at it wrong. You > > may say > > that when I install my updated s/w I should also install a new > > busybox > > exe, on whatever machine, and use it. > > No, I understand you might have no control over that. > > > > You might even say that all of my s/w should use "busybox ps", or > > set a > > path at start-up so that busybox is preferred to any Debian > > utilities > > lying around. > > > > Maybe that is the right approach, and I should get used to the > > idea that > > busybox is actually part of my app, not part of the system. > > Except there > > are things in /etc/init.d that use busybox too. Maybe I need to > > download > > and update EVERY script on the system with my app. Better find > > them all > > first. > > And if anything else I don't update is doing system() calls I'd > > better > > pray the new busybox works the same. > > > > Perhaps I should set up myapp/sbin myapp/bin myapp/usr/bin and > > myapp/usr/sbin and stick those on the front of the path, and set > > links so > > my app sees my latest busybox, but any existing s/w on the > > machine sees > > the environment it was used to... > > > > Do you, or does anyone else here, know how to square this circle? > > You will need to test your scripts on every deployed config > and try to write scripts so that they work on all configs > you support. If this is impossible, sometimes you will need > to have several version of a script. > > To reduce amount of PITA, try to minimize the number > of deployed configurations. > > -- > vda > _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
