From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6f3a846b60378b9339ea232558845a66@vitanuova.com> Date: Thu, 20 Apr 2006 16:59:28 +0100 From: rog@vitanuova.com To: 9fans@cse.psu.edu Subject: Re: [9fans] Install from CD fails In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 41ff77ea-ead1-11e9-9d60-3106f5b1d025 > i thought that in the inferno sh the bit inside the {} was parsed, and later converted > back to a string if passed to a command (uniform treatment of {} as in `{}, and you > discover your syntax errors in good time). i don't remember what es did. that's true, but es did exactly the same thing. the internal representation is the shell's syntax tree (which means that evaluation of sub-blocks is reasonably efficient, unlike tcl, which has to rescan the string each time through), but the string representation should generate exactly the same tree when parsed, so for most practical purposes, it can be treated as if it *was* verbatim (excess white space is removed, as are comments). i could have used a similar approach to your v7 "export a function containing the code", but it's nice to be able to pass code fragments around to unrelated processes, for instance to remotely execute some code on a file server. the other thing the inferno shell allows, which i thought quite neat at the time, is that a running program can load itself as a module into an instance of the shell, and define shell "builtins" that call back into the program, thus giving scriptability at little cost. for instance, the window manager does this for its initialisation script: the "menu" primitive adds a new item to the window manager menu (its argument is, of course, a shell command to run when the item is invoked).