Re: Determination of file lists from selected folders without returning directory names

[SF Markus Elfring]

>>> why should a simple `basename` or ${name##*/} hurt the performance?
>>
>> Such data deletion causes also corresponding processing costs, doesn't it?
>> Would it be nicer to avoid them if the initial input data could be provided
>> as “basenames” already?
> 
> Sorry, it seems I missed the most important question:
> What is your exact use case?

You might be looking for more information than I suggest so far.

Possible use cases:
* The reduced names can belong to known directories.

* File name usage can be analysed across the folder hierarchy.



> We need numbers and commands to reproduce it.

I propose to take another look at the applied data processing style.

* When is it more efficient to work only with the required data at
  the beginning of an algorithm?

* Under which circumstances will you tolerate that more data can be
  provided than are needed for an action?


> Otherwise, this is all just guesswork, and we could spend years to discuss
> what could maybe be considered, etc.

How much will it matter to compare consequences from eager and lazy evaluation?


> You already got the ideal answer for probably 99.9% of the cases - "use 
> find(1)"

This tool is already usable for various file searches.


> - so unless you describe your outstanding edge case in more detail,
> I'm afraid there's nothing more we could help you with.

I imagine that there can be a target conflict between the flexibility of
a known program and a search task with special constraints.

How much will data processing for the parameter “-printf” influence
rum time characteristics in undesired ways when the output function
could be a fixed one like “basename()”?

Regards,
Markus