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, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18058 invoked from network); 20 Nov 2022 16:27:47 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 20 Nov 2022 16:27:47 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1668961667; b=qEuBCtcuhKATD69NWY67VMyd1PP6hfHY6byhdTZkrE2a4HpIzXbZDmmaADFo0fBiThVo03Kh/N 3Zj1DAhi3A6OJ8bfKMu/xzN6m/wfDbQTnR0y/8RlVgJZcyce8QbNakkpSdq50J6ZZr3pjeJfiQ eJ1u1IU6eK6JKbETpBZJmyqP+HaG3e3I1gSi+mrQ+fzlXKXAexBoERuOhQqqNhZHElP5nB2bGE pYGqTnpcm3lAf9GPK3LEZ+0LkGd2VOTJG2z1rTlNfx76XHbvN4k22Exx5PVuY3PhAj6W0PZ7NK 2sU4Ctqkb7hkb4bGSI9ZeUNT2/thNT48fDuplpjLLZqiqg==; 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=1668961667; bh=ieZku3E2bap0laHM0ImXYkeogXE68Es/VPGgwrPTMRc=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID:DKIM-Signature; b=Wv+hbjplSfvAgY6KA375rcwKaZZ3EcYLTaP/+FH4dBrkpO0HrkP8wVZ5ktcLe4Cl99Q2VaNxxu 0aCdE263SQQVtkcx/cVpvSGaTXXsDPrDYPiGsd50lHs4E51VA7jM4ouJEfPYQSNjZPZWVUQU/s MkXL87HrVTb8oPXB+YD1zKid0o14Qj4uKpi7sS5EDuweau9oA3S8m5Sy/wwOkSS04evS8dfWTz A/+I32vJSnweH76eLS3M8g4lT4v7WGCIFHwf+7TYBmdNe7CNzWM+wRdPtu2PPH9puI3gYJpUmo 3Iyog7lAvRiEuwPEPGvC2taDxP2zkkTPKgytiVFBENG80Q==; 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:Content-transfer-encoding: Content-type:In-reply-to:From:References:To:Subject:MIME-version:Date: Message-id:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=pDmQAK2JhkoAjH0HXYay2Uc/OHPDAqaBqP/09rDuG+g=; b=FB5ZeXiECLTHdOe3L90DIVSkTN aX6CEzE9pvi4YZLUEZ2jrZbX32UTZuadKW9MOSnbgC9D2Eoo723kSA8ir97VDVVE8R8yyR6wJpYSA x68Raw0fEtSJrlX21jDcCbH8nbhT9h22iul2gj9GrBRs5EUm6LviJnutcKM4clqTp4jTEoN9INgOG vk33Wy2fLgDIX9DPb0oDNL1EbFq4T5f5Vhi5NY5VprQRoGB5gy9WJkXJtjdtg0dd8n/Ou71S9Khyz 6FISGtt/GhTks7/Rc9DmUYe19zXqUknJ04jiBirWr1MQ3lr0A49c5IYHbbKddB0PFHTiwxlUta0hQ 0sw5Xshg==; Received: by zero.zsh.org with local id 1ownAY-000Oam-Hy; Sun, 20 Nov 2022 16:27:46 +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]:53635) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1own9r-000NtE-Me; Sun, 20 Nov 2022 16:27:04 +0000 Received: from csp01.eastlink.ca ([71.7.199.166]) by mta02.eastlink.ca (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPS id <0RLN000IPMFQVBH0@mta02.eastlink.ca> for zsh-users@zsh.org; Sun, 20 Nov 2022 12:27:02 -0400 (AST) Received: from [192.168.0.4] ([24.207.18.108]) by Eastlink with ESMTPSA id wn9poQPNrkffJwn9qoxowr; Sun, 20 Nov 2022 12:27:02 -0400 X-Authority-Analysis: v=2.4 cv=Lbf6qBTi c=1 sm=1 tr=0 ts=637a5556 a=xN66ZtSbq5jdJYpBp7G/jQ==:117 a=xN66ZtSbq5jdJYpBp7G/jQ==:17 a=IkcTkHD0fZMA:10 a=Ye9q-bpsAAAA:8 a=mDV3o1hIAAAA:8 a=RhW9aty8wJ_pxFmc2SsA:9 a=QEXdDO2ut3YA:10 a=2CVlzlkFvZ0A:10 a=ZS9Lk02LDZ8A:10 a=_FVE-zBwftR9WsbkzFJk:22 X-Vade-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrheeggdeigecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfgtefuvffnkffpmfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeftrgihucetnhgurhgvfihsuceorhgrhigrnhgurhgvfihssegvrghsthhlihhnkhdrtggrqeenucggtffrrghtthgvrhhnpeelleefgeeifedvueeutddtkeefhfeigfdvueegheelffejiedvffejjeeukedvhfenucffohhmrghinhepshhtrggtkhgvgigthhgrnhhgvgdrtghomhdpghhnuhdrohhrghenucfkphepvdegrddvtdejrddukedruddtkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvgedrvddtjedrudekrddutdekpdhhvghloheplgduledvrdduieekrddtrdegngdpmhgrihhlfhhrohhmpehrrgihrghnughrvgifshesvggrshhtlhhinhhkrdgtrgdpnhgspghrtghpthhtohepvddprhgtphhtthhopeerredprhgtphhtthhopeiishhhqdhushgvrhhsseiishhhrdhorhhgpdhgvghtqdgkihhprfgrshhsfigupehtrhhuvg X-Vade-Score: 0 X-Vade-State: 0 X-EL-AUTH: rayandrews@eastlink.ca Message-id: Date: Sun, 20 Nov 2022 08:27:01 -0800 MIME-version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: why is eval needed? Content-language: en-US To: zsh-users@zsh.org References: <20221119164852.hwujmufa6hn5lotr@chazelas.org> <352823cc-954a-fa79-d830-d69d593b1c02@eastlink.ca> <3fa3f7ff-1733-4730-a62f-dd0e138c3b72@app.fastmail.com> <20221120085519.szudhyg5ewrw3b4o@chazelas.org> <20221120150848.74di3mpjwnfcul34@chazelas.org> From: Ray Andrews In-reply-to: <20221120150848.74di3mpjwnfcul34@chazelas.org> Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 8bit X-Seq: 28422 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: On 2022-11-20 07:08, Stephane Chazelas wrote: > zsh doesn't impose anything. "-L 2" is a string made of 4 > characters in any shell or programming language. There's no > programming language where "-L 2" means 2 strings -L and 2. But that's the thing, I'd naively thought the variable could be inserted in the command string and be 'just' a string of characters, but zsh imposes that 'tree' must see '-L 2' as a single entity, yes?  As shown, we need word splitting to solve the problem and show tree what it wants to see. Or, as I was speculating, some way of just flattening the string back to nothing more than a string of characters -- but then again, probably tree wouldn't like that either, perhaps the string is always 'packaged' into words?  If so, then there's no avoiding that we must word-split '-L 2' into two words and there's nothing to wish for. > That is a very weird feature from a language design point of > view. Anybody who doesn't know what the shells looked like > before the Bourne shell would think Stephen Bourne was out of > his mind. > It's what happens when functionality expands by accretion -- simple structures no longer suffice but they are tweaked rather than rethought.  It's like the difference between the layout of Paris vs. London. > My understanding is that the Bourne shell's bizarre IFS handling > and the fact that globbing was performed upon parameter > expansion was an attempt to keep some level of backward > compatibility with that Thompson shell. You see similar things > hapenning in csh from the same era. The dilemma of compatibility!  No easy answers.  I myself tend towards a 'garage to the dump' mentality but it's not that simple. > The Korn shell (from the early 80s) kept most of that with the > exception that it only did IFS-splitting upon expansions, not on > literal text. Holy cow!  IFS splitting in text?? > The fact that in sh/ksh/bash: > > arg='-L 1' > tree $arg > > Calls tree with "-L" and "1" as arguments is not that bash > doesn't do some sort of magic "grouping" that zsh would be > doing, but that ksh/bash contrary to zsh does that extra layer > of $IFS-splitting from the Bourne shell on top of the syntax > parsing as the default value of $IFS happens to contain the > space character. Ah!  So my little issue is a zsh exclusive?  Not complaining tho, I don't like zsh doing things I didn't ask it to do so if in this case I need to request a word split that's just fine.  After all it's tree that's being difficult so the problem is rare and easily solved. > That's why in sh/bash/ksh you almost always need to quote > parameter expansions if you intend to pass the contents of a > variable as an argument to a command. > > See > https://unix.stackexchange.com/questions/171346/security-implications-of-forgetting-to-quote-a-variable-in-bash-posix-shells > for the kind of thing that can happen if you forget. Heavy.  That's the closest I've come to understanding those vulnerabilities. > > If you want to assemble a string, and that string to be > evaluated as shell code, that's what eval is for. eval evaluate > code written in the shell language. That's a way to dynamically > invoke the language interpreter. Ok, so I understood that correctly.  At least partially. > What are you doing there?  I have no 'nm' command here.  No such command in > Debian repository. > nm is a standard development command (though not -D which AFAIK > is a GNU extension). Part of GNU binutils on GNU systems. Ah, that's why I can't find it.  It's hard to find commands so packaged. > Note that tree is not part of the GNU project, it's just a > utility written by some guy and shared to the world. There is > *some* level of consistency among utilities in the GNU > toolchest. There is even such a thing as published GNU coding standards. > See for instance > https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces Yeah, tides of organization wash here and there.  No overall commander tho, so a bit of chaos is unavoidable. > I'll agree with you that the lack of consistency in API between the > different tools that are available out there can be annoying > (nothing to do with GNU or Linux) You know, half of it is just cultural adaptation.  When I first started with Linux the first thing I did was decide between zsh and bash and I'm basically assuming that Linux will be like DOS but slightly more powerful and zsh will be like C and that all Linux OS apps will be as flawless as WordPerfect 5.1.  CRASH!  Now that I'm used to being in a bazaar not a monastery it's easier to get around.  One does get mud on one's shoes. > eval evaluates shell code. I struggle to understand what you > don't understand. Maybe you're thinking too much or too little > of what a "command line string" is. A "command line string" > like: I think at this level of my education it's enough to say that eval looks at it's arguments as if they were typed on the command line.  I haven't really 'understood' anything, I use eval ad hoc when it seems to solve problems.  Using it with real understanding is a future goal. > For that string to be passed as code to the shell language > interpreter for it to interpret. Right, I get that: 2 /aWorking/Zsh/Source/Wk 0 $ var="echo howdy" 2 /aWorking/Zsh/Source/Wk 0 $ eval $var howdy > Again, tree has nothing to do with the GNU project. I dunno, I get it all from Debian and Debian is a GNU/Linux OS so I don't know more than that. Thanks for a most educational post!  I love these history lessons, they inform my entire outlook.  You can't understand where you are unless you understand where you've been.