listfiles() output is in anti-alphabetical order

classic Classic list List threaded Threaded
2 messages Options
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

listfiles() output is in anti-alphabetical order

Hello,

Seeing that

--> test_run graphics bug_3*
   TMPDIR = C:\path\SCI_TMP_3556_28568

   001/065 - [graphics] bug_3999................................passed
   002/065 - [graphics] bug_3991................................passed
   003/065 - [graphics] bug_3975................................passed
...

processes entries in anti-alphabetical order, and analysing it, i have found that listfiles() does the same since at least Scilab 4.1.2. In the listfiles() code, there is the instruction
filesi
= filesi($:-1:1);
post-processing the output from findfile().

May be this reversing was formerly needed after findfiles() whether findfiles() had this reversed order.
Such an effect was recently detected in linspace(), where the compensation of a wrong upstream order had not been canceled after fixing the upstream order.
Or maybe it was for another reason. By now, as far as we can test it, removing this reordering does not yield any trouble and makes listfiles() output more expected.

Does anyone know a reason for this reversion?
Does anyone have an objection against making listfiles() yielding its result in alphabetical order, as more expected?

Thanks
Samuel

PS: If anyone could spend some time to build a unique full-featured file-listing function replacing and extending listfiles() + findfiles() + ls() + dir().., i would vote for such a more radical solution.


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: listfiles() output is in anti-alphabetical order

Le 02/02/2019 à 18:28, Samuel Gougeon a écrit :

Hello,

Seeing that

--> test_run graphics bug_3*
   TMPDIR = C:\path\SCI_TMP_3556_28568

   001/065 - [graphics] bug_3999................................passed
   002/065 - [graphics] bug_3991................................passed
   003/065 - [graphics] bug_3975................................passed
...

processes entries in anti-alphabetical order, and analysing it, i have found that listfiles() does the same since at least Scilab 4.1.2. In the listfiles() code, there is the instruction
filesi
= filesi($:-1:1);
post-processing the output from findfile().

May be this reversing was formerly needed after findfiles() whether findfiles() had this reversed order.
Such an effect was recently detected in linspace(), where the compensation of a wrong upstream order had not been canceled after fixing the upstream order.
Or maybe it was for another reason. By now, as far as we can test it, removing this reordering does not yield any trouble and makes listfiles() output more expected.

Does anyone know a reason for this reversion?
Does anyone have an objection against making listfiles() yielding its result in alphabetical order, as more expected?

Thanks
Samuel

This sorting issue is now reported as bug 15955.
By the way, paths in the output list may mix relative and absolute ones. This somewhat breaks any attempt to sort the whole output list in a relevant way. This is reported as bug 15956.

Samuel


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev