* ls *.mp4 → ls : invalid option -- 'M'
@ 2023-10-13 7:59 Denis Bitouzé
2023-10-13 8:15 ` sergio
2023-10-13 8:15 ` Mikael Magnusson
0 siblings, 2 replies; 17+ messages in thread
From: Denis Bitouzé @ 2023-10-13 7:59 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-13 7:59 ls *.mp4 → ls : invalid option -- 'M' Denis Bitouzé
@ 2023-10-13 8:15 ` sergio
2023-10-13 8:15 ` Mikael Magnusson
1 sibling, 0 replies; 17+ messages in thread
From: sergio @ 2023-10-13 8:15 UTC (permalink / raw)
To: zsh-users
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-13 7:59 ls *.mp4 → ls : invalid option -- 'M' Denis Bitouzé
2023-10-13 8:15 ` sergio
@ 2023-10-13 8:15 ` Mikael Magnusson
2023-10-13 11:38 ` Denis Bitouzé
2023-10-13 14:46 ` Ray Andrews
1 sibling, 2 replies; 17+ messages in thread
From: Mikael Magnusson @ 2023-10-13 8:15 UTC (permalink / raw)
To: Denis Bitouzé; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-13 8:15 ` Mikael Magnusson
@ 2023-10-13 11:38 ` Denis Bitouzé
2023-10-13 14:46 ` Ray Andrews
1 sibling, 0 replies; 17+ messages in thread
From: Denis Bitouzé @ 2023-10-13 11:38 UTC (permalink / raw)
To: zsh-users; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-13 8:15 ` Mikael Magnusson
2023-10-13 11:38 ` Denis Bitouzé
@ 2023-10-13 14:46 ` Ray Andrews
2023-10-13 15:13 ` Peter Stephenson
1 sibling, 1 reply; 17+ messages in thread
From: Ray Andrews @ 2023-10-13 14:46 UTC (permalink / raw)
To: zsh-users
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-13 14:46 ` Ray Andrews
@ 2023-10-13 15:13 ` Peter Stephenson
2023-10-13 15:58 ` Ray Andrews
2023-10-16 0:46 ` Bart Schaefer
0 siblings, 2 replies; 17+ messages in thread
From: Peter Stephenson @ 2023-10-13 15:13 UTC (permalink / raw)
To: zsh-users
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-13 15:13 ` Peter Stephenson
@ 2023-10-13 15:58 ` Ray Andrews
2023-10-16 0:46 ` Bart Schaefer
1 sibling, 0 replies; 17+ messages in thread
From: Ray Andrews @ 2023-10-13 15:58 UTC (permalink / raw)
To: zsh-users
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-13 15:13 ` Peter Stephenson
2023-10-13 15:58 ` Ray Andrews
@ 2023-10-16 0:46 ` Bart Schaefer
2023-10-16 4:17 ` Bart Schaefer
1 sibling, 1 reply; 17+ messages in thread
From: Bart Schaefer @ 2023-10-16 0:46 UTC (permalink / raw)
To: Peter Stephenson; +Cc: zsh-users
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.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-16 0:46 ` Bart Schaefer
@ 2023-10-16 4:17 ` Bart Schaefer
2023-10-16 4:25 ` Bart Schaefer
0 siblings, 1 reply; 17+ messages in thread
From: Bart Schaefer @ 2023-10-16 4:17 UTC (permalink / raw)
To: zsh-users
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 $*
}
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-16 4:17 ` Bart Schaefer
@ 2023-10-16 4:25 ` Bart Schaefer
2023-10-16 13:35 ` Ray Andrews
0 siblings, 1 reply; 17+ messages in thread
From: Bart Schaefer @ 2023-10-16 4:25 UTC (permalink / raw)
To: zsh-users
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-16 4:25 ` Bart Schaefer
@ 2023-10-16 13:35 ` Ray Andrews
2023-10-16 18:21 ` Bart Schaefer
0 siblings, 1 reply; 17+ messages in thread
From: Ray Andrews @ 2023-10-16 13:35 UTC (permalink / raw)
To: zsh-users
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-16 13:35 ` Ray Andrews
@ 2023-10-16 18:21 ` Bart Schaefer
2023-10-16 19:45 ` Ray Andrews
0 siblings, 1 reply; 17+ messages in thread
From: Bart Schaefer @ 2023-10-16 18:21 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-16 18:21 ` Bart Schaefer
@ 2023-10-16 19:45 ` Ray Andrews
2023-10-17 3:49 ` Bart Schaefer
0 siblings, 1 reply; 17+ messages in thread
From: Ray Andrews @ 2023-10-16 19:45 UTC (permalink / raw)
To: zsh-users
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-16 19:45 ` Ray Andrews
@ 2023-10-17 3:49 ` Bart Schaefer
2023-10-17 14:04 ` Ray Andrews
0 siblings, 1 reply; 17+ messages in thread
From: Bart Schaefer @ 2023-10-17 3:49 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-17 3:49 ` Bart Schaefer
@ 2023-10-17 14:04 ` Ray Andrews
2023-10-17 15:55 ` Bart Schaefer
0 siblings, 1 reply; 17+ messages in thread
From: Ray Andrews @ 2023-10-17 14:04 UTC (permalink / raw)
To: zsh-users
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-17 14:04 ` Ray Andrews
@ 2023-10-17 15:55 ` Bart Schaefer
2023-10-17 17:03 ` Ray Andrews
0 siblings, 1 reply; 17+ messages in thread
From: Bart Schaefer @ 2023-10-17 15:55 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ls *.mp4 → ls : invalid option -- 'M'
2023-10-17 15:55 ` Bart Schaefer
@ 2023-10-17 17:03 ` Ray Andrews
0 siblings, 0 replies; 17+ messages in thread
From: Ray Andrews @ 2023-10-17 17:03 UTC (permalink / raw)
To: zsh-users
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-10-17 17:04 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-13 7:59 ls *.mp4 → ls : invalid option -- 'M' Denis Bitouzé
2023-10-13 8:15 ` sergio
2023-10-13 8:15 ` Mikael Magnusson
2023-10-13 11:38 ` Denis Bitouzé
2023-10-13 14:46 ` Ray Andrews
2023-10-13 15:13 ` Peter Stephenson
2023-10-13 15:58 ` Ray Andrews
2023-10-16 0:46 ` Bart Schaefer
2023-10-16 4:17 ` Bart Schaefer
2023-10-16 4:25 ` Bart Schaefer
2023-10-16 13:35 ` Ray Andrews
2023-10-16 18:21 ` Bart Schaefer
2023-10-16 19:45 ` Ray Andrews
2023-10-17 3:49 ` Bart Schaefer
2023-10-17 14:04 ` Ray Andrews
2023-10-17 15:55 ` Bart Schaefer
2023-10-17 17:03 ` Ray Andrews
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).