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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,MIME_QP_LONG_LINE, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4398 invoked from network); 30 Mar 2023 12:05:54 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 30 Mar 2023 12:05:54 -0000 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:To:References:Message-Id:Date:Cc: In-Reply-To:From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID; bh=x5lH9L1u7HSGJvBcblkf3z3SBiNwPjGhuJly/bwdpXQ=; b=kfykMazd8qcP2Cl5P+PyjdcRWP ZdaNVHENtyKMC0JaBWr4u9RgIGfLdzaDrKquaPTu6+kRdMllXf7wf2Z9FV0a5EmIDbmagf2WxtcGe GslWZ3ABP+JmdogbV5Q9xzdzAqwqOoX/e8zZBamQxuMly5g+niwMkv/Tpmq59q1+QF9mNjaP9cJvY f9XBKQbkw+62UzJm32iLyDI+EaoXPxqEzt7YACxM05icRrhjV6f5oko9+/DdvjjAfM9rwG6/J0+5p k5wVNR8OJqrQAlUFD8+7fxTOwMBLheQ3zdchPHQXexiGnLQDWEqQRvRzXRQjN3vLS9z5wl4/Q5wKo PGBH6JLQ==; Received: by zero.zsh.org with local id 1phr2P-0007ke-KC; Thu, 30 Mar 2023 12:05:53 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1phr1o-00073u-6Q; Thu, 30 Mar 2023 12:05:16 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 3377C27C0054; Thu, 30 Mar 2023 08:05:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 30 Mar 2023 08:05:14 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdehkedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfgggfuhfgjveffkfhfvffosegrjehmrehhtdejnecuhfhrohhmpefnrgif rhgvnhgtvgcugggvlhojiihquhgviicuoehlrghrrhihvhesiihshhdrohhrgheqnecugg ftrfgrthhtvghrnhepheejgfehfeejudelgfejkeevtdfgudfgjeetffegjeehgedtjeeu tdffhfeltedunecuffhomhgrihhnpehophgvnhhgrhhouhhprdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgrrhhrhihvodhmvghs mhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudehudekjeejtdegqdduudelvdejfe ekhedqlhgrrhhrhihvpeepiihshhdrohhrghesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: iaa214773:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 30 Mar 2023 08:05:13 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D6062506-CD2F-4CC9-8837-6FC89BAAECB8 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: Discrepancy in IFS handling (zsh is POSIX compliant) From: =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= In-Reply-To: Cc: Zsh Users Date: Thu, 30 Mar 2023 08:05:10 -0400 Message-Id: References: To: Felipe Contreras X-Mailer: iPhone Mail (19H307) X-Seq: 28996 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: --Apple-Mail-D6062506-CD2F-4CC9-8837-6FC89BAAECB8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Mar 30, 2023, at 7:13 AM, Felipe Contreras = wrote: > =EF=BB=BFHowever, this is what POSIX says: >=20 > 3.b. Each occurrence in the input of an IFS character that is not > IFS white space, along with any adjacent IFS white space, shall > delimit a field, as described previously. >=20 > We ignore all the white space stuff (since we are not using white > spaces), and thus: >=20 > Each occurrence in the input of an IFS character shall delimit a field.= >=20 > In zsh each occurrence of a comma does delimit a field (4 commas, 5 > fields), which to me is what POSIX says should happen. >=20 > So in this particular case it seems zsh is complying with POSIX (even > in zsh mode), and all other shells are not. Before the excerpt you quoted, XCU 2.6.5 says: =E2=80=9CThe shell shall trea= t each character of the IFS as a delimiter and use the delimiters as field t= erminators to split the results of parameter expansion, command substitution= , and arithmetic expansion into fields.=E2=80=9D The bash/dash/ksh behavior is not unreasonable if the phrase =E2=80=9Cfield t= erminators=E2=80=9D is interpreted strictly. In any case, I believe the standard intends to describe the ksh behavior: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag= _23_02_06_05 --=20 vq Sent from my iPhone= --Apple-Mail-D6062506-CD2F-4CC9-8837-6FC89BAAECB8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
On Mar 30, 2023, at 7:13 AM, Felip= e Contreras <felipe.contreras@gmail.com> wrote:

=EF=BB=BFHowever, this i= s what POSIX says:

   3.b. E= ach occurrence in the input of an IFS character that is not
= IFS white space, along with any adjacent IFS white space, shall
delimit a field, as described previously.

We ignore all the white space stuff (since we are not using white<= br>spaces), and thus:

  &n= bsp;Each occurrence in the input of an IFS character shall delimit a field.<= /span>

In zsh each occurrence of a comma does deli= mit a field (4 commas, 5
fields), which to me is what POSIX s= ays should happen.

So in this particular ca= se it seems zsh is complying with POSIX (even
in zsh mode), a= nd all other shells are not.

Before the excerpt you quoted, XCU 2.6.5 says: =E2= =80=9CThe shell shall treat each character of the IFS as a delimiter and use= the delimiters as field terminators to split the results of parameter expan= sion, command substitution, and arithmetic expansion into fields.=E2=80=9D

if the phrase =E2=80=9Cfield terminators=E2=80=9D is interp= reted strictly.

In any case, I believe the standard= intends to describe the ksh behavior:

-- 
vq
Sent from m= y iPhone
= --Apple-Mail-D6062506-CD2F-4CC9-8837-6FC89BAAECB8--