<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 21, 2020 at 3:06 AM Rob Landley <<a href="mailto:rob@landley.net">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"><br>
<br>
On 8/19/20 6:05 PM, enh wrote:<br>
> <br>
> On Wed, Aug 19, 2020 at 3:59 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>
> <br>
> <br>
>     On 8/19/20 4:51 PM, enh via Toybox wrote:<br>
>     > Allow -pd to work by changing -p from an option that takes an<br>
>     > argument to an option that implies there will be an argument (that<br>
>     > is, `-pd x` is `-p -d x` with x being the directory for -p, rather<br>
>     > than `-p d x` with d being the directory, as we previously interpreted<br>
>     > it).<br>
>     ><br>
>     > Fix -d (aka --make-directories) to not be a no-op. Previously we<br>
>     > acted as if this was always on.<br>
>     ><br>
>     > Accept --quiet and effectively just ignore it, since toybox cpio<br>
>     > doesn't seem to produce any output that --quiet would suppress.<br>
> <br>
>     $ echo yank | cpio out -pd<br>
>     cpio: You must specify one of -oipt options.<br>
>     Try `cpio --help' or `cpio --usage' for more information.<br>
>     It's not position independent, it uses Unix System 6 parsing logic like<br>
>     "tar cvfC file dir" does. Your fix doesn't make the semantics match, it works<br>
>     around a specific bug.<br>
<br>
No it doesn't. The gnu/dammit cpio is apparently using some horrible hand-rolled<br>
option parsing that's inconsistent between options:<br></blockquote><div><br></div><div>aristocrats! :-)</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">
  $ find . | cpio -Ho newc<br>
  cpio: invalid archive format `o'; valid formats are:<br>
  crc newc odc bin ustar tar (all-caps also recognized)<br>
  $ find . | cpio -oH newc<br>
  0707010490302E0000...<br>
<br>
  $ cpio -pHd newc sub<br>
  cpio: invalid archive format `d'; valid formats are:<br>
  crc newc odc bin ustar tar (all-caps also recognized)<br>
  $ cpio -pdH newc sub<br>
  cpio: Archive format is not specified in copy-pass mode (use --format option)<br>
  $ cpio -pdHnewc sub<br>
  cpio: Archive format is not specified in copy-pass mode (use --format option)<br>
  $ cpio -pdHnexc sub<br>
  cpio: invalid archive format `nexc'; valid formats are:<br>
  crc newc odc bin ustar tar (all-caps also recognized)<br>
<br>
so -H is parsed with modern collating style, and -p is parsed with unixv6<br>
collating style, IN THE SAME COMMAND LINE.<br>
<br>
I'm starting to lean back towards applying your patch verbatim. While I _can_<br>
teach lib/args.c how to do that, it's TOO STUPID FOR WORDS and I'd wait for a<br>
second outright broken command to need it before... ow?<br></blockquote><div><br></div><div>yeah, i'm assuming unless proven otherwise (a) nobody is actually trying to use it with arguments in the "wrong" order and (b) cpio is the only tool this silly. (well, maybe pax too, but you've been pretty clear about your opinion of pax, and i've never seen anyone use it in the wild and don't expect to.)</div><div><br></div><div>i think even for those of us who had to endure the days of commercial unixes, tar is just a weird special case. this possibility certainly never occurred to me when writing my test cases. i don't think you'd even realize it was a possibility from the POSIX or GNU man pages either...</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">
Rob<br>
</blockquote></div></div>