[lug] Using Pipes w/ find exec Or find xargs

[Jeffrey S. Haemer]

>
> FYI, bash is necessary for portability reasons across architectures and to
> possibly have "snippets" placed in related bash software.


Plus it's hard to argue against using a language that lets you do it in a
simple one-liner. :-)

--
Jeffrey Haemer <jeffrey.haemer at gmail.com>
720-837-8908 [cell], http://seejeffrun.blogspot.com [blog],
http://www.youtube.com/user/goyishekop [vlog]
*פרייהייט? דאס איז יאַנג דינען וואָרט.*

On Tue, Mar 24, 2015 at 4:48 PM, <stimits at comcast.net> wrote:

> ...
>  > Just to make sure we're all trying to solve the same problem, could
> you post the easy bash solution?
>
> The concept is easy, the actual code under bash is a bit of a nightmare
> since file names and symbolic links and their targets can contain any kind
> of whitespace or control characters. The "easy" version comes down to using
> find with printf to insert a record separator character (hex 0x1E) between
> each unquoted file/directory/link name; this results in a huge string which
> can be iterated over 1 character at a time, building file names until the
> 0x1d is encountered. At this point the name is echoed through a pipe to
> base64 -wrap=0, and stored as an associative array key...the value is taken
> from slicing and dicing of ls -ld. In the case of symbolic links the
> slicing and dicing results in an extra parameter which is the base64
> encoding of the link target. End result: One array base64 key which bash
> works well with, and an attribute for the value (permissions, ownership,
> major/minor numbers, link dereferences, hard file checksums).
>
> Profiling shows that producing the initial find string is fairly quick,
> but looping through it one character at a time to build file names from it
> costs exponentially more as the string grows. Bash does not have pointers
> or iterators, so referencing a character at index 1000 isn't
> bad...referencing one at index 100,000 is terrible; each character
> extracted this way is in a loop from 0 to n. Cutting large strings into
> smaller strings helps, but trimming the low order indices of large strings
> also goes up exponentially as string size grows. Ahh, my kingdom for a
> pointer or iterator!
>  FYI, bash is necessary for portability reasons across architectures and
> to possibly have "snippets" placed in related bash software.
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20150324/682fe7c3/attachment.html>