From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: from zero.zsh.org (zero.zsh.org [IPv6:2a02:898:31:0:48:4558:7a:7368]) by inbox.vuxu.org (Postfix) with ESMTP id 4613822008 for ; Sat, 20 Apr 2024 01:27:19 +0200 (CEST) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1713569239; b=FhwkDyfOp/G+gW1/8mQEAYe0VF/Nybl7wcHTxa5aTBRf6SBMvLzETrz1hqye6jyBlJZewDpXh/ PIEUIv1B0Jp9pifCvf6c3OlZGwXzqmyUrb+ykyHtGHB2jbgVQGI90eKoEftozo6fx1gHWE4B1W wareMfc4thur+m9p9DCHXYpZ/0APRXQptPKscdzgmz5l9TZTz1GX2Xc0K7EdWboGg0utK0udgw A8FviJWP214UoYkZh4eke3Amqy3Sg6eCC3Whbi2mbEnvrb0vH2tJc8ahQNQaMMucVIBKaoieXv TTnrqv3MP3MWsdkxc/wrUkNkeD50xs7f4XC+DVBr0aL1Dg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mta02.eastlink.ca) smtp.remote-ip=24.224.136.13; 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=1713569239; bh=mAogd1yT3jp3wb2ks2pIRH+/+3tBc6M8l+KzCLrIT0c=; 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=Rmo2poleUmeAdguzbALV8/v0U4ENo8FKKsOpmpUNbpsfwD/dJBlh9M0sExhRaSikf+pgJ6t1Wa Fj5elbWkNYay6TBOrNqajOrES3H0iHkndvXnubyS5jixglSNYQX2Dq2shFFQJVNoBEqXhEedFC WUGnxQDQqGAoTdu2wZghRobO297OLSlH3+qFeszcN6GcGDIHpuo1KXNkxDayd4Fhd6bqvXbSzs L7BjaOfWXrFipb10jwWOCSPBXqMSWWGYYZARg6yLtLD/z61lpPePoHsJbwxFAh40CcDLHeCPjD 0NGiJNXFaMcyAfezyMMWnLpb7G7duWw1XBYSIDan9o4c9A==; 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=n5O6jXfq62yTUub5DJV26W29yJoFBxnV2wmCjMamN8U=; b=BaNGWbGMrwOMQSXMNF1GyR72P7 oijsu8+gpgOJbOR0eGPMgeQd8s8emg8ydZNZ1nHJo6HhCQrbG4Nik3dghX0IN1EsMSERDKxVYuElx Fu3F3NLhuO56nXsxnStT8yG2dUL0u1uvLGY0TYCcFfIDll1bmI3BtyWROLwypfeaT4jrhHThVS9hR drnSNwEt1X8bi9HiOyChSAO62UrcN/aTicWvziib/4xRsAqYpzY0yZpnlyEQ2VS15hdSL8/fpopUI AgBtDbL/yEmp8WbguJzt1P2j8nRjPeJNPp0y2K7FsqwHs6stcvpciOcw1BHzJ8ds3wcAVmz57/EoE /z+T9HQQ==; Received: by zero.zsh.org with local id 1rxxdX-0000NU-8l; Fri, 19 Apr 2024 23:27:19 +0000 Authentication-Results: zsh.org; iprev=pass (mta02.eastlink.ca) smtp.remote-ip=24.224.136.13; dmarc=none header.from=eastlink.ca; arc=none Received: from mta02.eastlink.ca ([24.224.136.13]:55103) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1rxxbp-000PU6-LA; Fri, 19 Apr 2024 23:25:35 +0000 Received: from csp02.eastlink.ca ([71.7.199.167]) by mta02.eastlink.ca ([24.224.136.13]) with ESMTPS id <0SC71VDD9QCU27Q0@mta02.eastlink.ca> for zsh-users@zsh.org; Fri, 19 Apr 2024 20:25:32 -0300 (ADT) Received: from [192.168.0.11] (host-24-207-19-13.public.eastlink.ca [24.207.19.13]) by csp02.eastlink.ca ([71.7.199.167]) with ESMTPSA id xxbnrzi9V5TsrxxborHhsA (version=TLSv1_2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256); Fri, 19 Apr 2024 20:25:32 -0300 X-Authority-Analysis: v=2.4 cv=deIj3mXe c=1 sm=1 tr=0 ts=6622fd6c a=e7T7DzMKK1R988ZCg0wLyw==:117 a=e7T7DzMKK1R988ZCg0wLyw==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=EDFHhcvvfKlzv9rg5XQA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=ZLGELXoPAAAA:8 a=lV9sTGVHDQU4b-0Kfc8A:9 a=lIwqB5LVourLrDMt:21 a=_W_S_7VecoQA:10 a=CFiPc5v16LZhaT-MVE1c:22 X-Vade-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudekfedgvddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecugfetuffvnffkpffmpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurheptgfkffggfgfuvfhfhfgjsegrtderredtvdejnecuhfhrohhmpeftrgihucetnhgurhgvfihsuceorhgrhigrnhgurhgvfihssegvrghsthhlihhnkhdrtggrqeenucggtffrrghtthgvrhhnpefhteethfevgeeuvdelgefgvdevudefueduffdvgfelvddvgfdtieegueeuleeifeenucfkphepvdegrddvtdejrdduledrudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvdegrddvtdejrdduledrudefpdhhvghloheplgduledvrdduieekrddtrdduudgnpdhmrghilhhfrhhomheprhgrhigrnhgurhgvfihssegvrghsthhlihhnkhdrtggrpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepreerpdhrtghpthhtohepiihshhdquhhsvghrshesiihshhdrohhrghdpghgvthdqkghiphfrrghsshifugepthhruhgv X-Vade-Score: 0 X-Vade-State: 0 X-EL-AUTH: rayandrews@eastlink.ca Content-type: multipart/alternative; boundary="------------VEkgZI68OEav2ZCHC001aPYq" Message-id: <9058005a-6d7b-40f5-bdf0-f59d72ff3821@eastlink.ca> Date: Fri, 19 Apr 2024 16:25:31 -0700 MIME-version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: optimal expansions? To: zsh-users@zsh.org References: <53fab6be-26d7-4de5-844f-ffc295d9a494@eastlink.ca> Content-language: en-US From: Ray Andrews In-reply-to: X-Seq: 29841 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. --------------VEkgZI68OEav2ZCHC001aPYq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2024-04-19 13:40, Lawrence Velázquez wrote: > On Fri, Apr 19, 2024, at 3:22 PM, Ray Andrews wrote: >> That's my preferred way to look at 'apt-file search' output (Debian and >> derivatives only of course). It works fine and I think I understand >> all the expansions and splitting. One you get used to it the nested >> expansions aren't so scary, just read them from inside out, one step at >> a time and it's easy. But is it optimal? > How is anyone supposed to answer this question, when you haven't > deigned to mention what your code is supposed to DO? I thought I was crystal clear what it is supposed to do: reformat 'apt-file search' output.  The code runs, if you have a Debian derivative fire it up. > You seem to > colorize certain portions of the output by bracketing them with > escape sequences, but which portions, exactly? What does > "apt-file search" typically output? I wasn't expecting anyone but Debian users to comment.  Unless there are issues that are apparent just from scanning the code. > You don't check the exit status of "apt-file", so if it happens to > fail for any reason It's taken care of, just not within that minimal code I showed. > ((i=1; i<=$#var; i++ )); do > Since you only ever use "i" in the expansion "${=var[i]}", there > is no reason to use this form of "for". You can just use the usual > > for x in "$var[@]"; do Ah!  Now there's a good idea.  I tend to use the above only on  the command line, and the more 'formal' for loop in code -- seems more like C. > and subsequently "$x" instead of "$var[i]". Right!  Simpler. >> if [[ "$targ" != "${${=var[i]}[1]}" ]]; then >> targ="${${=var[i]}[1]}" >> var2+="\n${grn}${${=var[i]}[1]}${nrm}" # Copy first word of >> line. > You're doing that thing again, where you use a literal backslash-n > and rely on "print" to interpret it as a newline. This is bad > practice here because the rest of the string is the arbitrary output > of an external command, which you do not control. It could easily > contain substrings that are meaningful to "print". I've come to appreciate the problem!  Now for healthy solutions. > To insert an empty line in your output, just add an empty element > to "var2" in the desired position. > > % var=(a) > % var+= > % var+=b > % typeset -p var > typeset -a var=( a '' b ) > % print -rC1 -- "$var[@]" Very good, I'll implement that. > You should store the result of "${=var[i]}" in a temporary variable > and use that, instead of repeatedly word-splitting the same string > over and over and over. Right.  Three uses, so a temporary var would earn it's keep. >> print -l "$var2[@]" > Use "print -r" to prevent "print" from interpreting escape sequences > in its arguments. ... and that meshes with getting rid of the '\n's, yes? Thanks.  It's the difference between something that merely works, with something that's genuinely well coded. --------------VEkgZI68OEav2ZCHC001aPYq Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 2024-04-19 13:40, Lawrence Velázquez wrote:
On Fri, Apr 19, 2024, at 3:22 PM, Ray Andrews wrote:

That's my preferred way to look at 'apt-file search' output (Debian and 
derivatives only of course).  It works fine and I think I understand 
all the expansions and splitting.  One you get used to it the nested 
expansions aren't so scary, just read them from inside out, one step at 
a time and it's easy.  But is it optimal?

How is anyone supposed to answer this question, when you haven't
deigned to mention what your code is supposed to DO?
I thought I was crystal clear what it is supposed to do: reformat 'apt-file search' output.  The code runs, if you have a Debian derivative fire it up.

You seem to
colorize certain portions of the output by bracketing them with
escape sequences, but which portions, exactly?  What does
"apt-file search" typically output?
I wasn't expecting anyone but Debian users to comment.  Unless there are issues that are apparent just from scanning the code.

You don't check the exit status of "apt-file", so if it happens to
fail for any reason
It's taken care of, just not within that minimal code I showed.

((i=1; i<=$#var; i++ )); do

Since you only ever use "i" in the expansion "${=var[i]}", there
is no reason to use this form of "for".  You can just use the usual

	for x in "$var[@]"; do
Ah!  Now there's a good idea.  I tend to use the above only on  the command line, and the more 'formal' for loop in code -- seems more like C.  
and subsequently "$x" instead of "$var[i]".
Right!  Simpler. 
        if [[ "$targ" != "${${=var[i]}[1]}" ]]; then
            targ="${${=var[i]}[1]}"
            var2+="\n${grn}${${=var[i]}[1]}${nrm}" # Copy first word of 
line.

You're doing that thing again, where you use a literal backslash-n
and rely on "print" to interpret it as a newline.  This is bad
practice here because the rest of the string is the arbitrary output
of an external command, which you do not control.  It could easily
contain substrings that are meaningful to "print".
I've come to appreciate the problem!  Now for healthy solutions.
To insert an empty line in your output, just add an empty element
to "var2" in the desired position.

	% var=(a)
	% var+=
	% var+=b
	% typeset -p var
	typeset -a var=( a '' b )
	% print -rC1 -- "$var[@]"
Very good, I'll implement that.  

You should store the result of "${=var[i]}" in a temporary variable
and use that, instead of repeatedly word-splitting the same string
over and over and over.
Right.  Three uses, so a temporary var would earn it's keep.  
    print -l "$var2[@]"

Use "print -r" to prevent "print" from interpreting escape sequences
in its arguments.
... and that meshes with getting rid of the '\n's, yes?

Thanks.  It's the difference between something that merely works, with something that's genuinely well coded.

--------------VEkgZI68OEav2ZCHC001aPYq--