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

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

[Denis Bitouzé]

Hi,

my configuration is the following:

- GNU/Linux Mageia 9
- zsh 5.9
- oh my zsh (last version)

The trouble I'm facing is the following:

- `ls *.tex` gives the intended output,
- `ls *.mp4` returns the following message: “ls : invalid option --
  'M'”.

Do you understand what's going on?

Thanks.
-- 
Denis

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

[sergio]

On 13/10/2023 10:59, Denis Bitouzé wrote:

> Do you understand what's going on?

Possible, you have a file that starts with `-M`?

ls -- *.mp4

-- 
sergio.

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

[Mikael Magnusson]

On 10/13/23, Denis Bitouzé <dbitouze@wanadoo.fr> wrote:
> Hi,
>
> my configuration is the following:
>
> - GNU/Linux Mageia 9
> - zsh 5.9
> - oh my zsh (last version)
>
> The trouble I'm facing is the following:
>
> - `ls *.tex` gives the intended output,
> - `ls *.mp4` returns the following message: “ls : invalid option --
>   'M'”.
>
> Do you understand what's going on?

One (or more) of your files start with the string "--M", you want
either ls -- * or ls ./* (or print -rl - *)

-- 
Mikael Magnusson

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

[Denis Bitouzé]

Le 13/10/23 à 10h15, Mikael Magnusson a écrit :

> One (or more) of your files start with the string "--M",

Indeed.

> you want either ls -- * or ls ./* (or print -rl - *)

That does the trick: thanks to both of you!
-- 
Denis

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

[Ray Andrews]

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


On 2023-10-13 01:15, Mikael Magnusson wrote:
> One (or more) of your files start with the string "--M", you want
> either ls -- * or ls ./* (or print -rl - *)
I understand the answer and it was courteously given, but just 
technically speaking, is that a zsh issue?  I'm seeing it as the 
internal problem of ls.  Remembering that the shell will do the 
expansion of the argument, is it in any way up to zsh to parse any 
'--M*' as special?  In other words, Denis' question seems to suppose 
that it IS somehow up to zsh to handle that, and I'm wondering if that's 
correct.

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

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

[Peter Stephenson]

> On 13/10/2023 15:46 Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 2023-10-13 01:15, Mikael Magnusson wrote:
> 
> > One (or more) of your files start with the string "--M", you want
> > either ls -- * or ls ./* (or print -rl - *)
>
> I understand the answer and it was courteously given, but just
> technically speaking, is that a zsh issue? I'm seeing it as the
> internal problem of ls. Remembering that the shell will do the
> expansion of the argument, is it in any way up to zsh to parse any
> '--M*' as special? In other words, Denis' question seems to suppose
> that it IS somehow up to zsh to handle that, and I'm wondering if
> that's correct.

It's more that it's up to the zsh user, and if they don't know what to
do, they're going to ask the zsh users mailing list.  It's a very
generic Unix shell issue; you can argue whether shells should work like
this but it's way too late now.

So no, it's not up to zsh to do anything different, but yes, it is
up to zsh users on the mailing list to help out with questions like
this.

pws

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

[Ray Andrews]

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


On 2023-10-13 08:13, Peter Stephenson wrote:
> So no, it's not up to zsh to do anything different, but yes, it is
> up to zsh users on the mailing list to help out with questions like
> this.
>
> pws
I like it.  I have noticed objections in the past when a question was 
asked that was not strictly a zsh issue, but I myself prefer the broader 
goal of helping each other more generally.
> you can argue whether shells should work like
> this but it's way too late now.
Yeah, that's the honest answer, some things are now written in stone.  
It would shut-up some of my own objections/questions too -- historical 
cultural precedents are sometimes too deep to change and that's the way 
it is.

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

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

[Bart Schaefer]

On Fri, Oct 13, 2023 at 8:13 AM Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> It's more that it's up to the zsh user, and if they don't know what to
> do, they're going to ask the zsh users mailing list.  It's a very
> generic Unix shell issue; you can argue whether shells should work like
> this but it's way too late now.

It would be pretty easy to add a setopt that would prefix any glob
result that begins with '-' or Dash with "./".  (Or I suppose any glob
that doesn't start with '.' or '/' if that's more generic.)

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

[Bart Schaefer]

On Sun, Oct 15, 2023 at 5:46 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> It would be pretty easy to add a setopt that would prefix any glob
> result that begins with '-' or Dash with "./".

Or with some inaccuracy if there are files named the same as valid
options to "ls", something like this:

ls () {
  emulate -L zsh
  local i
  for i in {1..$#}
  do
    [[ ${(P)i} = -* && -f ${(P)i} ]] && : ${(P)i::=./${(P)i}}
  done
  command ls $*
}

Or in the current dev build with named references:

ls () {
  emulate -L zsh
  local -n f
  for f in {1..$#}
  do
    [[ $f = -* && -f $f ]] && f=./$f
  done
  command ls $*
}

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

[Bart Schaefer]

On Sun, Oct 15, 2023 at 9:17 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Or in the current dev build with named references:
>
> ls () {
>   emulate -L zsh
>   local -n f
>   for f in {1..$#}

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.

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

[Ray Andrews]

[-- 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 --]

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

[Bart Schaefer]

On Mon, Oct 16, 2023 at 6:35 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Question:  is this not the sort of issue that in principle cannot be solved in an air-tight way?

It is in the same category as filenames containing newlines and
assorted globbing characters in that it mostly comes up in contexts
where the user doesn't see the string before it's processed.  However,
it's a little more insidious because other "unusual" characters can be
handled with appropriate quoting, and globbing is the most likely
place for leading hyphens to crop up because globbing is more common
in interactive use than things like "find | xargs".

>  If shells always expand arguments zealously

I'm not sure that's the right characterization, but anyway ...

> with the presumption that they are filenames

Only true of globbing.

> if someone has filenames that mimic de facto options when globbing is done, are they not a victim of their own liberty?

They might be a "victim" of file sharing from a different operating system.

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

[Ray Andrews]

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


On 2023-10-16 11:21, Bart Schaefer wrote:

> with the presumption that they are filenames
> Only true of globbing.
So I understand.  Otherwise there's nothing to do and zsh has nothing to 
say about the matter.
>
>> if someone has filenames that mimic de facto options when globbing is done, are they not a victim of their own liberty?
> They might be a "victim" of file sharing from a different operating system.

True, but then mere anarchy is loosed upon the world and zsh can hardly 
be asked to salvage it.  I leave a resolution to wiser people, I'm just 
sharing my philosophical take on the thing.  Me, I thought that when 
Windows started allowing spaces in filenames that was the beginning of 
the downfall of the West.  The laws of information theory scream against 
it.  But here we are.  Dunno, but it seems to me like that EDITOR 
setting thing you just cleaned up -- too much helpfulness when what was 
needed was a direct and explicit imperative.  zsh should 'officially' 
fix only that which is robustly fixable and also zsh's natural 
responsibility.  My two cents.


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

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

[Bart Schaefer]

On Mon, Oct 16, 2023 at 12:46 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Dunno, but it seems to me like that EDITOR setting thing you just cleaned up -- too much helpfulness when what was needed was a direct and explicit imperative.

On the other had we have plenty of people requesting that completions
offer either more, or more contextually specific, matches.  Those
people certainly want assistance rather than imperatives, and the
EDITOR/VISUAL checks have never prevented anyone from being explicit
instead.

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

[Ray Andrews]

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


On 2023-10-16 20:49, Bart Schaefer wrote:
> On the other had we have plenty of people requesting that completions
> offer either more, or more contextually specific, matches.
Isn't that a different issue?  One can't have too much control.
>    Those
> people certainly want assistance rather than imperatives,
Pardon?  How do the two conflict?
>   and the
> EDITOR/VISUAL checks have never prevented anyone from being explicit
> instead.

True, it's a  philosophical thing, but the majority commented that they 
found it either confusing or even confounding.  I favor things like that 
having one point of control which is an explicit imperative:

bindkey -vi

I tell the shell what I want.  No guessing, no wondering, no conflicts.  
Personal thing of course, but I myself consider simplicity to be a very 
strong value.  I'd even go as far as calling the EDITOR thing a bug.  
Complexity that adds power is one thing, but complexity that just adds 
lines of code while offering zero improvement in control is another.  
I'm probably a bit of an extremist in this tho.


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

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

[Bart Schaefer]

On Tue, Oct 17, 2023 at 7:06 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-10-16 20:49, Bart Schaefer wrote:
>
> On the other had we have plenty of people requesting that completions
> offer either more, or more contextually specific, matches.
>
> Isn't that a different issue?

Seems to me everything discussed so far is a case of wanting the shell
to "do what I mean" without having to explicitly tell it how.

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

[Ray Andrews]

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


On 2023-10-17 08:55, Bart Schaefer wrote:
> Isn't that a different issue?
> Seems to me everything discussed so far is a case of wanting the shell
> to "do what I mean" without having to explicitly tell it how.

Interesting perspective.  I'd say the exact opposite.  The shell should 
not presume to know what you mean without explicit instruction.  Mind 
... there can of course be defaults, like 'bindkey -e' I think  everyone 
agrees would be the default.  But if I want vi bindings I hafta be 
explicit about that -- no extrapolations from EDITOR or anything else.  
There should be exactly one way to make that change because only one way 
is needed.  My smartphone drives me mental, it's always trying to be 
helpful whether I want the help or not.  So it changes things that I 
don't want changed and God knows how to change them back.  But, with 
something as powerful as zsh, asking for 'simplicity' is always going to 
be a bit naive, naturally.   My perspective is hardly the only one.



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