[bug #51506] Better support for data processing with basenames

Follow-up Comment #16, bug #51506 (project findutils): > I agree with James - there's no need to add yet more knobs to findutils' configure. How can any patch make a difference for which you would care also (despite of concerns for special program configurations) then? > …, you'll still be free

[bug #51506] Better support for data processing with basenames

Follow-up Comment #15, bug #51506 (project findutils): Submit patches, and we'll review them. Until then, you are wasting more developer time arguing for the theoretical, than you are saving by optimizing any programs. I agree with James - there's no need to add yet more knobs to findutils' conf

[bug #51506] Better support for data processing with basenames

Follow-up Comment #14, bug #51506 (project findutils): > Every additional option is a burden in maintenance … A few parameters can cause also run time effects which may be unwanted for special use cases. I would find it nicer if known settings (besides the default one) could be selected to adjust

[bug #51506] Better support for data processing with basenames

Update of bug #51506 (project findutils): Severity: 3 - Normal => 1 - Wish Status:None => Wont Fix Assigned to:None => jay Open/Closed:

[bug #51506] Better support for data processing with basenames

Follow-up Comment #12, bug #51506 (project findutils): > … warrants a separate ~200k binary. I imagine that there are further build configuration possibilities to reduce the size of the executable file. > exec find "$@" -printf "%f\n" Thanks for your suggestion. Such a command can also occasi

[bug #51506] Better support for data processing with basenames

Follow-up Comment #11, bug #51506 (project findutils): > I suggest to consider the choice between additional variants for the program “find”. I don't think this marginal feature to fall back to basenames for -print (or when no other action is specified) warrants a separate ~200k binary. I propos

[bug #51506] Better support for data processing with basenames

Follow-up Comment #10, bug #51506 (project findutils): > You mean to change the behavior of the default -print action (or when omitted) > to strip off leading directories? Yes. > This would break almost all existing scripts, Not directly. I suggest to consider the choice between additional va

[bug #51506] Better support for data processing with basenames

Follow-up Comment #9, bug #51506 (project findutils): > [...] introduce a corresponding build configuration parameter ... You mean to change the behavior of the default -print action (or when omitted) to strip off leading directories? This would break almost all existing scripts, and future scrip

[bug #51506] Better support for data processing with basenames

Follow-up Comment #8, bug #51506 (project findutils): > ... because no one ever complained about a performance / resource issue with the directories part not stripped off > (because there is the "%f" option), … * Is the software situation still different for called commands? * How do you think ab

[bug #51506] Better support for data processing with basenames

Follow-up Comment #7, bug #51506 (project findutils): > How many test cases check already run time consequences for > handling directory specifications there? Most probably Zero ... because no one ever complained about a performance / resource issue with the directories part not stripped off (bec

[bug #51506] Better support for data processing with basenames

Follow-up Comment #6, bug #51506 (project findutils): > … a new action like e.g. -printbase makes any difference in any case * I imagine that such a “parameter alias” could be easier to remember. * But it would also mean that there is an additional string which would need a corresponding check in

[bug #51506] Better support for data processing with basenames

Follow-up Comment #5, bug #51506 (project findutils): > So the specification of such a command line parameter would also be > a bit too much extra data ... I heavily doubt that abbreviating the 14 bytes of "-printf '%f\n'" on the command line to a new action like e.g. -printbase makes _any_ diffe

[bug #51506] Better support for data processing with basenames

Follow-up Comment #4, bug #51506 (project findutils): >For optimization issues, people usually come with a certain, reproducible case to point out a bottleneck. I suggest a software adjustment where I can also imagine that you might not interpret its impact in significant ways because a specific

[bug #51506] Better support for data processing with basenames

Follow-up Comment #3, bug #51506 (project findutils): > Which system test would be representative to show that reduced file names > can result in nicer run time characteristics because of less data transfer? Whom do you ask? For optimization issues, people usually come with a certain, reproducib

[bug #51506] Better support for data processing with basenames

Follow-up Comment #2, bug #51506 (project findutils): >What resources are you envisioning that '-printf %f\\n' uses that would not be used by adding a new option, … A bit of parsing could also be omitted for a string like “-printf %f\\n” if the desired output function could be selected by a build

[bug #51506] Better support for data processing with basenames

Follow-up Comment #1, bug #51506 (project findutils): What resources are you envisioning that '-printf %f\\n' uses that would not be used by adding a new option, when balanced against the pain of adding, documenting, and maintaining a new option, for something that is already such a corner case th

[bug #51506] Better support for data processing with basenames

URL: Summary: Better support for data processing with basenames Project: findutils Submitted by: elfring Submitted on: Wed 19 Jul 2017 03:06:47 PM CEST Category: find S