<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 16, 2022 at 7:47 AM Yi-yo Chiang <<a href="mailto:yochiang@google.com">yochiang@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 16, 2022 at 1:20 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/15/22 16:32, enh wrote:<br>
> On Thu, Sep 15, 2022 at 1:45 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
> On 9/15/22 07:30, Yi-yo Chiang via Toybox wrote:<br>
> > grep is slow when the number of patterns is large.<br>
> ...<br>
> > xxd -p -c 0 -l 40 /dev/urandom<br>
> <br>
> Huh, WHY does that produce two lines of output?<br>
> <br>
> $ xxd -p -c 0 -l 40 /dev/urandom<br>
> 1fcf13e1b4844ba209fb9958bde26a13577c577744f1b1290240d03f4f8e<br>
> 644fd0687c39b1aa8a68<br>
> <br>
> Behavior is consistent between toybox xxd and debian's, but Elliott sent in the<br>
> xxd implementation and I don't use it much, so... Feeding in -c 40 and -c 80<br>
> make no difference?<br>
> <br>
> i think that's actually a bug caused by this:<br>
> <br>
> // Plain style is 30 bytes/line, no grouping.<br>
> <br>
> if (FLAG(p)) TT.c = TT.g = 30;<br>
> <br>
> should presumably be <br>
> <br>
> // Plain style is 30 bytes/line, no grouping.<br>
> if (FLAG(p)) {<br>
> if (!TT.c) TT.c = 30;<br>
> if (!TT.g) TT.g = 30;<br>
> }<br>
><br>
> ?<br>
<br>
Except we didn't set -g so it would still be set to 30, which is going to stick<br>
spaces into the output.<br>
<br>
And xxd_main() starts with if (!TT.c) TT.c = blah so it would never be zero at<br>
that point unless we reorder the code, and then once THAT'S fixed -c 0 is still<br>
!TT.c and if I switch that to if (FLAG(c)) to allow c = 0 through (which the<br>
range in the optstr is allowing) it's used to cap the length in readall()<br>
meaning the first read becomes EOF so no output gets produced.<br>
<br>
> certainly "real" xxd works for me on macos and debian, both of which have the<br>
> same version of xxd:<br>
> <br>
> ~$ xxd --version<br>
> xxd 2022-01-14 by Juergen Weigert et al.<br>
> ~$ xxd -p -c 0 -l 40 /dev/urandom<br>
> ac160632955aa9d938e60d3533cbcf0febb4decdd12f130e415913ff1fe6e2abcaf7c4a8e980de7a<br>
<br>
See, this is extra weird: nothing set -g so it should default to 2. Somehow it<br>
knows to set itself to... I'm guessing 0. Did -p -c 0 get special cased, or did<br>
-p change its default to avoid any breaks even without the -c 0? (Sounds like<br>
the latter is more likely, but I tried "yum install xxd" on my fedora 36 VM and<br>
yum doesn't know what an xxd is.<br>
<br></blockquote><div><br></div><div>(Tangent. Seems like xxd behavior is different everywhere, I should be careful and also note my expected output next time I use xxd as a random string generator.)</div><div><br></div><div>On my debian machine (with the same 2022-01-14 build as Elliott), `man xxd` says...</div><div>* -p: Plain text output, '-g' is ignored, '-c' defaults to 30, '-c 0' results in one long line (yes '-p -c 0' is a special case for "plain text no wraping no grouping")</div></div></div></blockquote><div><br></div><div>so replace</div><div><br></div><div> if (!TT.c) TT.c = FLAG(i) ? 12 : 16;<br><br> // Plain style is 30 bytes/line, no grouping.<br> if (FLAG(p)) TT.c = TT.g = 30;<br></div><div><br></div><div>with</div><div><br></div><div> if (FLAG(p)) {</div><div> // Plain style is 30 bytes/line, no grouping.<br></div><div> // -p -c 0 is a special case for "one long line".</div><div> if (!TT.c) TT.c = FLAG(c) ? LONG_MAX : 30;</div><div> TT.g = TT.c;</div><div> }</div><div> if (!TT.c) TT.c = FLAG(i) ? 12 : 16;</div><div><br></div><div>?</div><div><br></div><div>rob: let me know if you've _not_ been distracted by this already and i'll actually test that and send you a patch this afternoon, since it's friday!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>* doesn't say what would happen with '-c 0' otherwise</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> ah, but on another box with 2021-10-22 it's broken. so it looks like "real" xxd<br>
> had the same bug and fixed it recently?<br>
<br>
Eh, seems more like a design decision than a bug. Before -p was wordwrapping the<br>
hexdump output and now it isn't. I dunno if it always isn't, or just with -c 0?<br>
We didn't set -g and it has a nonzero default value (1, 2, or 4 depending on<br>
barometric pressure)...<br>
<br>
I also note that the man page says -g 0 switches off grouping, but does NOT say<br>
that -c 0 switches off columns? In the V1.10 version I have installed, -c 0<br>
seems to be a NOP:<br>
<br>
$ sha1sum < /dev/null | xxd -c 0<br>
00000000: 6461 3339 6133 6565 3565 3662 3462 3064 da39a3ee5e6b4b0d<br>
00000010: 3332 3535 6266 6566 3935 3630 3138 3930 3255bfef95601890<br>
00000020: 6166 6438 3037 3039 2020 2d0a afd80709 -.<br>
<br>
Once again: easy to change the behavior, hard to tell what the changed behavior<br>
should be. Easiest is to have -p force -g to 0 and -c to huge (stomping whatever<br>
else got set in both). I could also teach -c that 0 means infinite (well,<br>
sizeof(toybuf) implementation limit which is still bigger than the 256 directly<br>
settable limit that I have no idea why it's there) if that's actually a thing...?<br>
<br>
(Grumble grumble no standard and the reference implementation has version skew...)<br>
<br>
Rob<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><table width="90%" border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:0px;font-family:"Times New Roman";max-width:348px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td style="padding:0px"><table border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:20px 0px 0px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td valign="top" style="padding:0px 20px 0px 0px;vertical-align:top;border-right:1px solid rgb(213,213,213)"><img src="https://i.imgur.com/eGpkLls.png" width="200" height="64"><br></td><td style="padding:0px 0px 0px 20px"><table border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:0px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:1px 0px 5px;font-size:13px;line-height:13px;color:rgb(56,58,53);font-weight:700">Yi-yo Chiang</td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 5px;font-size:11px;line-height:13px;color:rgb(56,58,53)">Software Engineer</td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 5px;font-size:11px;line-height:13px;color:rgb(56,58,53)"><a href="mailto:yochiang@google.com" target="_blank">yochiang@google.com</a></td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 3px;font-size:11px;line-height:13px;color:rgb(3,112,248)"></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table><div><font size="1">I support flexible work schedules, and I’m sending this email now because it is within the hours I’m working today. Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine.</font><br></div></div></div></div>
</blockquote></div></div>