Re: ls *.mp4 → ls : invalid option -- 'M'

[Ray Andrews <rayandrews@eastlink.ca>]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]


On 2023-10-15 21:25, Bart Schaefer wrote:
> Oops, that should be
>    for 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.



[-- Attachment #2: Type: text/html, Size: 2571 bytes --]