On Mon, Sep 23, 2019 at 3:53 PM Chet Ramey <chet.ra...@case.edu> wrote:
>
> On 9/23/19 5:29 AM, Ilkka Virta wrote:
> > On 22.9. 21:15, Chet Ramey wrote:
> >> On 9/20/19 10:24 PM, hk wrote:
> >>
> >>> Description:
> >>> On the section 3.2.6(GNU Parallel, page 16 in the pdf) of Bash
> >>> Reference Manual. The manual uses `find' command to illustrate
> >>> possible use cases of `parallel' as examples. but the option `-depth'
> >>> does not accept any argument, I think it means `-maxdepth` option
> >>> instead.
I think you are right. The goal is to emulate 'ls'.
As you can see from GNU Parallel's manual I would use printf instead:
printf '%s\0' * | parallel -0 mv {} destdir
but I feel you are right that -depth should simply be replaced with -maxdepth.
> >> -depth n
> >> True if the depth of the file relative to the starting point of
> >> the traversal is n.
> >>
> >> It's not in POSIX, and maybe GNU find doesn't implement it.
> >
> > That seems to raise a question.
> >
> > Isn't Bash a GNU project? Would it be prudent to use other GNU tools in
> > examples, if standard POSIX features aren't sufficient?
I seem to recall when I became a GNU maintainer that it was a higher
priority to integrate nicely with other GNU tools than to integrate
with non-GNU tools. I cannot find the exact wording now, so it may
have changed.
I understood that such that in examples it would be encouraged to
prioritize GNU find over FreeBSD find, but that it would be fine to
include both. So it would go against my understanding of that if the
Bash manual promoted FreeBSD find over GNU find. This also strengthens
my belief that what is really meant is -maxdepth.
But if the GNU find people do not mind and FreeBSD find does not have
-maxdepth, then I would suggest simply using
printf '%s\0' *
instead. It is shorter and IMHO easier to understand.
> > I can see that
> > FreeBSD find has '-depth n' (as well the standard '-depth', somewhat
> > confusingly) but should the reader of the manual be assumed to know the
> > options supported by BSD utilities?
If I recall the guidelines correctly: No.
/Ole
