tags 33943 notabug close 33943 merge 33942 thanks This message generated a new bug ticket. I merged it with the previous bug ticket.
westlake wrote: > I have omitted that I recently downgraded my coreutils to doublecheck > behaviour for ls, and noticed immediately the same behaviour was occuring, It was still occurring because this is not a new behavior of 'ls'. This is the Unix has operated since the beginning. It seems that you missed seeing Assaf's explanation of it. Let me repeat some of it. > $touch 0 ./--a ./-a ./-_a ./-- > $ ls -lad -* [^-]* Here the first example nicely uses ./ in front of the problematic characters. But the second one did not have ./ there. If it did then there would be no problem. But instead the "-*" above is trouble. Don't do it! Always put ./ in front of file globs (wildcards) like that. It should be: $ ls -lad ./-* ./[^-]* > .. however a period of time the behaviour is no longer exhibiting the same, It was not a period of time. It was the contents of the directory upon which the commands were used. It is data dependent. It depends upon the file names that exist. If there are no file names that start with a '-' then none will be mistaken for an option. As you knew when you created the test case using touch above. > I suppose I did not wait long enough for the new "ls" or whatever it is to > come into effect... It is not a time issue. It is only a matter of file glob wildcard expansion as done by the command line shell. Using 'echo' to see a preview of the command will show this. > but there's still oddities with ls, I guess it is the unprediction of > "getopt".. and so I guess I should address any further concerns with the > developers of getopt. This is also not a getopt issue. The best practice is to prefix all wildcards with ./ such as ./*.txt so that the resulting text string will not be confused with an option starting with a '-' even if the file name starts with a '-' as the result will be "./-something" but the resulting argument to ls will start with "./" instead of "-". Bob