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,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22260 invoked from network); 4 Aug 2021 07:20:18 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2021 07:20:18 -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=7M3pVDOlfMkfosum9HPrqCKXS4E7lvCC7yeHQtw4myA=; b=LRILRwDsYSAsLEMIdPwOGyUbPN 06kIrQ3ELOIXKsVghYgmxOt2VFj/B8qp1bgUyexeJSOJcZ6x7GrxuP+21am/1zhMu1t7AIbHZsfdL ymmuRvqA/GPbH5jdLVYWStmlLfjDuNWBmu4LDazwr0jheY5jQKMQ5oULOzoMx3fV2g+l0wYrpGfMT rFO6JcZVi6xl4Lpnn4HaAJ7NJv65HhimQyxQxcBVczzo0LBM3gWNQXddMmeYWPFYk60ReYBSi2Pvf yPeupzZBXt2yNZQFqLf9IMN87symq9JYEb6tGHlfQG9F1A2KFTJGnxZj5jCMOmO/28t9bSt69IV90 s5uW1Okg==; Received: from authenticated user by zero.zsh.org with local id 1mBBCL-0001pK-MT; Wed, 04 Aug 2021 07:20:17 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1mBBBo-0001SF-Cm; Wed, 04 Aug 2021 07:19:44 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id C1C5727C0054; Wed, 4 Aug 2021 03:19:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 04 Aug 2021 03:19:42 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieehgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfgggfuhfgjfffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepnfgrfihr vghntggvpgggvghljoiiqhhuvgiiuceolhgrrhhrhihvseiishhhrdhorhhgqeenucggtf frrghtthgvrhhnpeefveeigeeghfeuteefieegieetieegueeujeejgefgueffueetleej ffefudfhueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehlrghrrhihvhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduhedu keejjedtgedqudduledvjeefkeehqdhlrghrrhihvheppeiishhhrdhorhhgsehfrghsth hmrghilhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 Aug 2021 03:19:42 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] Increase $COLUMNS when generating long option completions From: =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= In-Reply-To: Cc: Bart Schaefer , Zsh hackers list Date: Wed, 4 Aug 2021 03:19:41 -0400 Message-Id: References: To: Marlon Richert X-Mailer: iPhone Mail (18G82) X-Seq: 49239 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: > On Aug 4, 2021, at 2:53 AM, Marlon Richert wrot= e: > =EF=BB=BFOn Wed, Aug 4, 2021 at 4:12 AM Lawrence Vel=C3=A1zquez wrote: >>=20 >> On Tue, Aug 3, 2021, at 10:05 AM, Marlon Richert wrote: >>> On Mon, Aug 2, 2021 at 2:07 AM Bart Schaefer = wrote: >>>> I'm puzzled, doesn't this imply that the value of $COLUMNS is >>>> incorrect on entry to the function? >>> No, the problem results from _call_program being connected to a pipe: >>> _call_program $lflag options ${~words[1]} --help 2>&1 | >>> while IFS=3D read -r opt; do >>> When ${~words[1]} is an external command, it will then not see >>> $COLUMNS, unless $COLUMNS has been exported. >>=20 >> Isn't that the case in general? External commands *never* see >> COLUMNS if it isn't in the environment. The pipe is a red herring. >>=20 >>> For example, compare the output of the following: >>> % pip3 --help >>> % _call_program tst pip3 --help >>> % _call_program tst pip3 --help | cat >>> % print -r -- "$( pip3 --help )" >>=20 >> Seems like pip is behaving differently depending on whether it's >> outputting to a tty or not. >=20 > I feel that cannot be the whole story, because if I do any of the > following, I get terminal-width output, instead of 80 columns: >=20 > % COLUMNS=3D$COLUMNS pip3 --help | cat > % print -r -- "$( COLUMNS=3D$COLUMNS pip3 --help )" Yes, these commands are explicitly setting COLUMNS in pip=E2=80=99s environm= ent. As Bart said, the tty vs. not-tty distinction probably only matters whe= n COLUMNS is not in pip=E2=80=99s environment. > % _call_program tst COLUMNS=3D$COLUMNS pip3 --help | cat >=20 > And pip isn't the only command that works that way. For example: >=20 > % ls -x / > Applications Library System Users Volumes bin cores dev etc home > opt private sbin tmp usr var > % ls -x / | cat > Applications Library System Users Volumes > bin cores dev etc home > opt private sbin tmp usr > var > % COLUMNS=3D$COLUMNS ls -x / | cat > Applications Library System Users Volumes bin cores dev etc home > opt private sbin tmp usr var > % Same thing here. You are explicitly setting COLUMNS in the environment of ls= , and ls is respecting it. --=20 vq Sent from my iPhone=