From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22338 invoked from network); 16 Oct 2023 13:36:22 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2023 13:36:22 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1697463382; b=dDAnQFw0tOAb/jeo9lKuzYI5uhEuD3KTvTCiEZ/zcq8vTqzsCGydLVi8NR2XODRIC1C2ik0RY+ i9AdMlQdyP/Hwr7fhvX6akDXDJfgEXfGcsLBPuN9arK110j+u/eFzjYr0YuWOEYhUy8DediGnS R/UTiNENR4F0yaMLGq0OQLgz1W0v5LJrhYp3hPxVZ2bovY6xxL9rZw7QAT+KuF+KuTeSsinw0x wIrARff7ghItlkIPc0RWJ5ETP32r1qSiIRnhKJtrEE35s9IpvTHt7jLEfjw++CNTeiFqodEQIe jElubP7QPqGUuzpKl5VmNhIriGpvZUKHnygQIuiObRsduQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mta01.eastlink.ca) smtp.remote-ip=24.224.136.30; dmarc=none header.from=eastlink.ca; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1697463382; bh=8/T6eyIWEOGgwnJ4KYrQHOW0UA/EayztZPAT1d/iftc=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Content-Type:DKIM-Signature; b=SJQOWsRIJ7qSw/qzbdYxDXLWLEwDsgd2v2IXgv2RQjMhI+xIpwae0i/oXmGu5PW9V9dN7wozdf k1mUrTViwAMd1QsUArKgab7cQ0SYM7W65Iv8rKN8QQht6aHEfvRBFsxd3wLPZRo3e1bp2Kcy1d S7koef0CeF66As6WfAIkWehxMUF5bCJZrYJ1HYEPuKAhd8+Ocn7AK/l38sKGU+vrpPOhLSn/ei meE8gi9ROm0Ioz/JSL0ACnefP7MNlW5QXEFF6p8FNzciLhg3xrfWIpI7U2NPFPnmagFyV1DO6j vkDyGMXjShtat8mrYjhrShPU7MKQBA1x5Bmv6vwft5vWMg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:In-reply-to:From:References:To: Subject:MIME-version:Date:Message-id:Content-type:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=6U2M0+rhcmN2nQ09alzodGKJgwy6LOx+1/qvmNG53ug=; b=fVLseWf9DaNAuwALKpmmIc8SAt brpvYRoQHOISUVSvOytuyyvVIShGiR3YYKhsfkFVeuXnU7g2kS/9K/clvXr09DMhdkTGvc+0dHY/s 3QjqEjdUjXw3n1bgDoyh2mc2JCoF06slUBT9v+jL9vcCK+ini6eXA/5N6DbJuIKfXys4QMsJWUL+1 TUNGhWgZmxa6p07mNXxKd3ssLE6FNxhJ+u5mjL+CAojO0rW95/kgGEstiJe2XYQy4CB8IkEDsxqyo irWeHvqpC2E2MxCSVmNFm6Fq1uMweJGbANlg7jQGaYvfGd9mgsNS4paOc9cN+WTkjcyWNQZyHBbAb 78ITq/Yw==; Received: by zero.zsh.org with local id 1qsNlc-0000Wx-9q; Mon, 16 Oct 2023 13:36:20 +0000 Authentication-Results: zsh.org; iprev=pass (mta01.eastlink.ca) smtp.remote-ip=24.224.136.30; dmarc=none header.from=eastlink.ca; arc=none Received: from mta01.eastlink.ca ([24.224.136.30]:34745) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1qsNkU-000Pqn-Sg; Mon, 16 Oct 2023 13:35:11 +0000 Received: from csp02.eastlink.ca ([71.7.199.167]) by mta01.eastlink.ca ([24.224.136.30]) with ESMTPS id <0S2M2EDL6J27G2U0@mta01.eastlink.ca> for zsh-users@zsh.org; Mon, 16 Oct 2023 10:35:09 -0300 (ADT) Received: from [192.168.0.4] (host-24-207-18-108.public.eastlink.ca [24.207.18.108]) by csp02.eastlink.ca ([71.7.199.167]) with ESMTPSA id sNkSq4FYALNFQsNkTqUGZS (version=TLSv1_2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256); Mon, 16 Oct 2023 10:35:09 -0300 X-Authority-Analysis: v=2.4 cv=f9GORs+M c=1 sm=1 tr=0 ts=652d3c0d a=xN66ZtSbq5jdJYpBp7G/jQ==:117 a=xN66ZtSbq5jdJYpBp7G/jQ==:17 a=5KLPUuaC_9wA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=FRCEw1rI2b07EBGkp8wA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=Ezy2HTUtONHuhBze-SoA:9 a=ZV0uJcbBxox-vAXz:21 a=_W_S_7VecoQA:10 X-Vade-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrjedtgdeifecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfgtefuvffnkffpmfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpegtkfffgggfuffvfhfhjgesrgdtreertddvjeenucfhrhhomheptfgrhicutehnughrvgifshcuoehrrgihrghnughrvgifshesvggrshhtlhhinhhkrdgtrgeqnecuggftrfgrthhtvghrnhephfettefhveeguedvleeggfdvvedufeeuudffvdfgledvvdfgtdeigeeuueelieefnecukfhppedvgedrvddtjedrudekrddutdeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvdegrddvtdejrddukedruddtkedphhgvlhhopegludelvddrudeikedrtddrgegnpdhmrghilhhfrhhomheprhgrhigrnhgurhgvfihssegvrghsthhlihhnkhdrtggrpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepreerpdhrtghpthhtohepiihshhdquhhsvghrshesiihshhdrohhrghdpghgvthdqkghiphfrrghsshifugepthhruhgv X-Vade-Score: 0 X-Vade-State: 0 X-EL-AUTH: rayandrews@eastlink.ca Content-type: multipart/alternative; boundary="------------jW9XbE8YCnO7aBND2GsTvN0d" Message-id: <179314f9-333c-4baa-9dab-6fa397ab2f64@eastlink.ca> Date: Mon, 16 Oct 2023 06:35:08 -0700 MIME-version: 1.0 User-Agent: Mozilla Thunderbird Subject: =?UTF-8?Q?Re=3A_ls_*=2Emp4_=E2=86=92_ls_=3A_invalid_option_--_=27M?= =?UTF-8?Q?=27?= Content-language: en-US To: zsh-users@zsh.org References: <875y3bvtos.fsf@example.com> <1312746524.945376.1697209990281@mail.virginmedia.com> From: Ray Andrews In-reply-to: X-Seq: 29299 Archived-At: X-Loop: zsh-users@zsh.org Errors-To: zsh-users-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-users-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: This is a multi-part message in MIME format. --------------jW9XbE8YCnO7aBND2GsTvN0d Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. --------------jW9XbE8YCnO7aBND2GsTvN0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


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. 



--------------jW9XbE8YCnO7aBND2GsTvN0d--