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
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
