On Sun, 23 Jul 2023 16:17:54 +0200 "Roberto A. Foglietta" <[email protected]> wrote:
> On Sun, 23 Jul 2023 at 13:18, tito <[email protected]> wrote: > > > > On Sun, 23 Jul 2023 12:00:56 +0200 > > "Roberto A. Foglietta" <[email protected]> wrote: > > > > > > > > > 1) multiple file handling (a must i would dare to say) > > > > > > Which is not such a problem, after all > > > > > > for i in "$@"; do simply-strings "$i" | sed -e "s/^/$i:/"; done > > > > > > the sed will include also the file name in front of the string which > > > is useful for grepping. However, the single-file limitation brings to > > > personalize the approach: > > > > > > for i in "$@"; do simply-strings "$i" | grep -w "word" && break; done; > > > echo $i > > > > Don't cheat, this change would break other people's scripts. > > Other people are not anymore into the scene, since the moment that we > established that reinventing the wheel is not efficient nor useful. > > > > > > > Yes, strings has a lot of options and also busybox have several > > > options. This is the best critic about proceeding with an integration. > > > I will check if I can put an optimization into bb strings, just for my > > > own curiosity. > > > > This would be far better than reinventing the wheel. > > > > Reinventing the wheel is a good way to understand how the wheel works > and improve it. We just concluded that there is no reason to reinvent > the wheel completely. However, the simple-strings can be useful when > its deployment fixes fulfill a void better than replacing a > fundamental system component like busybox which can break future OTA. Ever thought about compiling a busybox copy with only one applet or few applets that need fixes or updates or new features ? This was done a lot in the first android roms. > In particular, it is fine as a service/rescue/recovery image in which > the space is limited and the full compatibility with strings or > busybox strings is not necessary and for everything else custom > scripts can easily compensate. > > About improving busybox strings and more in general its printf > performance, it is about this: > > setvbuf(stdout, (char *)stdout_buffer, _IOFBF, BUFSIZE); > > Obviously a large static buffer can impact the footprint but as long > as malloc() is used into the busybox - and in its library I remember > there were sanitising wrappers for it - then it would not be such a > big deal to use a dynamically allocated buffer. The tricky aspect is > about the applet forking. A topic that I do not know but I saw an > option "no fork" in the config. I did not even start to see the code, > therefore I am just wondering about. Yes busybox code is tricky. This NO_FORK stuff is a black magic I really haven't understood yet. > > > > > > > > 3) output compatible with original gnu strings > > > > > > > > > In attachment the new version with the test suite and the benchmark > > > > > suite in the header. The benchmark suite did not change with respect > > > > > to the script file I just sent. > > > > > > > > > > Best regards, R- > > > > > > > > BTW: there still seem to be corner-cases: > > > > list=`find /usr` > > > > for i in $list; do if test -f $i; then ./strings $i > out1.txt; > > > > strings $i > out2.txt; diff -q out1.txt out2.txt; fi; done > > > > Files out1.txt and out2.txt differ > > > > Files out1.txt and out2.txt differ > > > > Files out1.txt and out2.txt differ > > > > Files out1.txt and out2.txt differ > > > > > > > > test is still running.... > > > > > > ok, I will do a run. Can you please echo the finenames, instead? > > > > > > for i in $list; do if test -f $i; then ./strings $i > out1.txt; > > > strings $i > out2.txt; diff -q out1.txt out2.txt >/dev/null || echo > > > $i; fi; done > > > > > The version in attachment also solves the rest of the problem that my > /usr could have raised with the previous version. Moreover, I have > further developed the benchmark and the testing suites. You might find > interesting the new part of the benchmark suite about 'dd' used as an > alternative of /dev/null for giving us a transfer speed. As you can > see, if you wish to do strings on tmpfs then for each different file > you need to copy it into the tmpfs. For this reason, copying in tmpfs > + 100 strings run on the same file is like cheating <-- you started! > ;-) I will study it. > > > > > > if you hire me as beta tester....at least you own me a beer if we ever met > > in person. > > > > Sure, you are welcome. I live in Genoa, at the moment - you can easily > find my mobile telephone number by googling my name (well, to be > precise: it is a brand strongly based on my name). it is rather far, maybe one day to visit the aquarium. > > In another context, I saw that there is the policy of paying by paypal > & co. a small amount of money IMHO, it is a very bad marketing policy > which seriously impair the value of a professionist. However, when Forget about the money, I prefer beer anyway, > someone acts outside its professional sector like - blogging, > zero-hope commercial projects, end-users guides, et similia - then it > is fine to ask, IMHO. As long as it is clear what someone asks. > > More in general, my common attitude is to raise and save money to > start my own company and pay people to work for/with me. But everytime > my incoming or my company business is going well, the people around me > go mad and f*ck-up everything without any reasonable way to stop them. > Now, I got quita a clear picture about it but this is definitely > off-topic. > > Cheers, R- Ciao, Tito _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
