[kwlug-disc] Reminder: bash's find has option -exec

[D. Hugh Redelmeier]

> From: Ron <ron at bclug.ca>

> If one would prefer everything found to be passed at once, finish the
> statement with \+

See also -print or, better, -print0, with find's output piped to
xargs(1).  \+ appears to be a GNU hack/convenience make xargs-like
behaviour more convenient.

find(1) has perhaps the ugliest arguments of the old style Unix
command.  Others say dd(1), but I more often have to look at the man
page of find.  Find is older than the - vs -- flag convention.

The exec option's format has in-band punctuation -- UGH. ";" is bad
enough but "+" is sometimes a meaningful argument for the subject
command.  They should not have overloaded -exec but instead added
something with a legible name, something like -batch-exe.

(I'm old enough to still resent BSD's ham-fisted extensions to UNIX.
I often don't even know about GNU's extensions; they too are sometimes
badly designed.  Note: the extensions are often useful but are too often
sloppily designed.)

> Unless... there's a whole bunch of stuff being found, then it gets buffered
> and passed to the -exec'd program when the buffer is full, not just when the
> `find` is done.
> 
> How big is the buffer? Who knows, good luck.

One of the important ideas of xargs was to do this batching.  It was
necessary because there is a limit on the size of the argument list
that exec(2) and friends allows.  Notice the (2): this is a system
call and hence the limitation is in the kernel.  POSIX specifies
things about this limit but I've not needed to know it since xargs
handles it for me in most cases.

Batching is awkward to get right so xargs is exactly the right place
to take care of it.

> My final answer:
> 
> find $mount_point -printf "%TY-%Tm-%Td %TH:%TM:%TS %p\0"  \
>     | sort --zero-terminated \
>     | tr '\0' '\n'           \
>     | sed -n -e 1p -e '$p'
> 
> Probably contains subtle errors still.

If I'm not mistaken, the first version only prints the oldest.
Your version prints the oldest and the newest.  A feature, not a bug.

It is possible to have filenames containing newline.  Yuck.  This
would muck up you script.

There might be a simple fix.  The GNU sed seems to have the option -z
or --null-data.  I infer that it causes SED to treat (only?) NUL as a
line separator.  The manual is unclear.  The name --null-data is
pretty poor.