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
<http://bugzilla.scilab.org/show_bug.cgi?id=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
<http://bugzilla.scilab.org/show_bug.cgi?id=15956>.
Samuel
_______________________________________________
dev mailing list
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
