Dwalk filter text out
adds a large number of filters (predicates) from dfind to dwalk
Thanks for submitting this, @brockpalen . I should be able to take a look early next week.
Thanks again @brockpalen . Sorry that it took so long to get to this!
The --text-output option looks good, though let's flip the name to be --output-text to keep it close to --output under alphabetical listings. And we should keep the --text option active for a while for people who may have that option encoded into their scripts. We can deprecate -text, print a warning that points to the new option name, and then drop it in a future release. To be consistent, we'll want to add that option to each of the tools.
Would you be up for doing that?
I think the filtering looks fine. We could run into an explosion of options as we talked about before, especially if we decide other tools would also benefit from built-in filtering. Until we figure out how to deal with that, we could bring this into dwalk if you want as hidden functionality (supported in the source code, but undocumented in the help output and man pages). That would give you something that works until we can figure out if we want to go with this or come up with a different but equivalent approach.
One idea we talked about... I feel like there is probably a role to create a tool like dpipe that would parse and process a chained command like:
dpipe dfind --amin 60 /path/to/walk | dwalk --sort --output-text foo.txt
We'd probably want to pick something other than a | character so the user doesn't have to escape it in their shell command all of the time. To support this kind of structure easily, we'll need each tool to be implemented as a callable function. The tool function could take an input list (the pipe input) and produce an output list (the pipe output). This would be a lot of work, but it would let us keep a smaller number of options in each tool interface.
Adam,
Sorry just getting back to this. I'm ok with what your propose. I will likely keep my own branch where I keep the help options. I have not put much effort into this because this gave me waht I wanted for my https://github.com/brockpalen/archivetar/ tool and is working quite well. Though it would be nice if there was a python module that could parse mfu file lists, and that's way beyond my copy and pasting your work.
I never did changes to a pull request before so hopefully hitting those resolve buttons worked. If not let me know, and if there is github documentation for what to do you can point me to it.