On 10/16/19 10:47 AM, enh wrote: > On Tue, Oct 15, 2019 at 10:56 PM Rob Landley <[email protected]> wrote: >> I could just do that. (This is _supposed_ to be iobound, what are they doing >> that -P 8 helps? Invoking perl. Oh JOY. More perl to remove from the kernel >> build! And the -n1 means THEY DON'T KNOW HOW TO USE FIND... sigh.) > > yeah, i sent you that patch too the other day if you do want to go the > easy route. like i said, as far as i could find from searching, most > uses of -P were to explicitly set it to 1.
This morning I had 28 open email reply windows of the "right click -> deal with this later" variety. Now I'm down to 10! > this is one reason why i like that toybox --help tries to be nice and > clear about what the defaults are. i suspect the folks who wrote -P1 > learned xargs from --help and were worried by > > -P, --max-procs=MAX-PROCS run at most MAX-PROCS processes at a time > > but didn't bother/know how to experiment. One person did it and the rest copied them on the assumption "they're doing it, so it must do something, and may be needed". My "I'm going to read the libc source, drill down into the kernel if necessary, check git history back to 0.0.1, ask the author (up to and including http://lkml.iu.edu/hypermail/linux/kernel/0207.2/1182.html)" approach to figuring out _why_ is apparently unusual. And then people treat stuff like https://www.osnews.com/story/25556/understanding-the-bin-sbin-usrbin-usrsbin-split/ as news worthy becuase nobody else bothered to _ask_... >> https://perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators >> >> g is the same as sed s///g >> >> s means "treat string as single line" and m means "treat string as multiple >> lines"...? Seriously, perl? This is your idea of documentation? > > basically, this is about ^ and $, and whether they match start/end of > _line_ or start/end of _input_. (one sad thing about Android's switch > to OpenJDK is that my docs for java.util.regex.Pattern were lost. IMHO > they were the clearest concise Perl-compatible regex docs around.) Your docs as in "I had a copy" or your docs as in "I wrote them"? I think I know what the current stuff does, I just haven't got a "not match parenthetical", and properly handling multiline stuff involves the "append repeatedly to hold space" trick (ala https://github.com/landley/toybox/blob/master/scripts/mkstatus.py#L24 ). But in the current kernel tree all the SPDX comments are single line so /SPDX/b; at the start peels those off, then it's just a question of /* to */ dropping out which is easy to do if you sed 's@/\*@\n/*@;s@\*/@*/\n' | sed '/\/\*/,/\*\//d' But I'd _prefer_ something that doesn't require two sed invocations. (And that could break lines that have a /* */ in them so I'd want to peel those out first...) It's not _hard_, it's just ugly. But I guess that's sed for you. I want something that's a clear improvement over using perl for it, and they _do_ have a much bigger regex implementation with 37 bells and whistles. (And then there's submitting it to linux-kernel. I haven't even resubmitted https://lkml.org/lkml/2017/9/13/651 yet, let alone the patch to make tmpfs the initramfs default... Linux-kernel ain't no fun anymore. Dowanna go on the cart.) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
