On 12/09/2011 04:27 PM, Amr Ali wrote: > Purpose is what drives my modifications towards shred. If you do work on > multiple files (and that *does* have a high probability), with a simple > command > line regular expression (e.g. './*') you are in fact recursing over files of > the > first level of depth of the current directory node, which conditionally, > having > it recurse on all directory nodes on multiple levels is only an expected > behavior
If you want to recurse over multiple layers, your first thought should be to use 'find', not '-r' - by having 'find' at the forefront of your toolbox, you will be able to solve your recursion issues for a LOT more tools, not just limited to shred, and in a manner portable to POSIX (and thus usable on more systems) rather than relying on GNU extensions. Furthermore, have you not been listening to our arguments that shred on files is worthless on most modern file systems? It doesn't destroy data unless you do it over entire partitions. Making shred recursive would be a bad move, because it would give users a false sense of security (oh, I can shred lots of files in one command line), when in reality, doing a recursive shred is just disk churn. If you want lots of files properly shredded, it is faster, and more reliable, to run something like 'shred /dev/sdb2' over the entire partition, than it is to try to recurse over the files on /dev/sdb2 and shred each in turn. But that still means you have to plan ahead - if you anticipate needing to shred lots of files, create a disk partition for those files. > Before taking a dive at coreutils source code, which was my very first time, I > always enjoyed just using the *functionalities* it does provide, I knew how > they > do work at very low level details, but this is not the drive behind using > them. > It's simply the desired quantifiable result. The low level technical > particularities are almost always expected to be abstracted away from usage. The beauty of free software is that you are free to make your patch, and use it yourself, even if we don't take it upstream. I'm glad it was a positive learning experience for you, even if we don't take this contribution. And hopefully you will still find other things to contribute that do fit in with the coreutils philosophy. >> >> Finally, if you DO manage to convince me, then we would need copyright >> assignment before your patch could be applied. >> > Should I use `assign.change.manual`? if so which email I should be sending > this > to, after signing it? That of course if I did convince you. http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING#n454 Use request-assign.future, and send the initial coordination mail to assign AT gnu DOT org. From there, they will help you with the additional paperwork, and if you are a US resident, it is now possible to do things electronically instead of snail mail. -- Eric Blake [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
