Oops, that should befor f in argv\[{1..$#}\]do [[ $f = -* && -f $f ]] && f=./$f done command ls $* }Forgot about the special case for $1 et al. that makes them not directly referenceable.
Question: is this not the sort of issue that in principle cannot be solved in an air-tight way? If shells always expand arguments zealously, with the presumption that they are filenames, yet knowing full well that some might be switches ... sorry 'options' ... and whereas the standard answer is that the double dash ends options -- if someone has filenames that mimic de facto options when globbing is done, are they not a victim of their own liberty?
IOW, if Linux permits almost anything as a filename, and if some of those filenames look like options, and if shells diligently expand everything, and if various commands are free to make up their own syntax. [Sorry, this is a really badly framed question. ] ... can even the idea of a generic zsh fix be contemplated?
I sorta see that Bart's code would sorta work, but given the
inherent brokenness of Linux in this regard, might it be better
understood that the solution is for people to not give weird names
to files? Or to code something ad hoc if they crash into this
kind of thing? I understand that the Linux philosophy is that you
are free to do dumb things -- Unix was invented by hippies -- but
I'm questioning whether zsh should 'get involved' in even a
peripheral way. If I have files named '--' and '-M' it might be
legal but if 'ls' has trouble with it I don't think I'd expect zsh
to try to fix that for me 'officially' that would just be
condoning bad behavior. Or should she? Not sure. Philosophical
issue.