From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20612 invoked by alias); 20 Sep 2015 05:41:26 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20606 Received: (qmail 20243 invoked from network); 20 Sep 2015 05:41:25 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=yo3RmIyOCZDLZ9mUNifN+ybwjti+Bs9XWCvqwbC+Y1M=; b=A5BX9yV3qy+9ZOI7+Q4mVCjSORNgn6dPFEu9VkKTmmnGortiPQp0RMpRF13zxMlPTi 5NV7vpJnCsnsiFUeJCvoE7I9TkbC9gwoujsPfPC8PT31T1zkwum/KZjm35ec8xvc6Pf4 Izdv4IrIafmsEa4oLf/ll7F0KO3C1PL1Of4Ek65wHs6vJ24MtabEfXJy4ZlSqvY+qXNu +YZdhNfr84hUWZOkB7d03xlN7zznHDo0SRzC1DQu9EF4hVTwakhwBRK7alGwRJxj0UcS T9cbHdcjDoaRcBQ9p70k/aWSFlZDlLVqmZ2lp9mm0dobz1r0uRaF3AI8I1H76CPmeqYL hvJA== X-Gm-Message-State: ALoCoQmCuyntdOzZ10Znlo+mfpbXHL5SagsJ6SoM42WDLrfbcwryZ9fYZ0FOHRmmGmtIs4bX3r59 X-Received: by 10.182.205.200 with SMTP id li8mr8514504obc.18.1442727683502; Sat, 19 Sep 2015 22:41:23 -0700 (PDT) From: Bart Schaefer Message-Id: <150919224120.ZM4736@torch.brasslantern.com> Date: Sat, 19 Sep 2015 22:41:20 -0700 In-Reply-To: <55FE04AD.1070304@eastlink.ca> Comments: In reply to Ray Andrews "Re: autoload" (Sep 19, 5:58pm) References: <55FAE223.2080502@eastlink.ca> <150917103419.ZM10067@torch.brasslantern.com> <150918171441.ZM27212@torch.brasslantern.com> <55FD7982.9030505@eastlink.ca> <150919092922.ZM28214@torch.brasslantern.com> <55FDA5D3.9020304@eastlink.ca> <150919142243.ZM23634@torch.brasslantern.com> <55FE04AD.1070304@eastlink.ca> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: autoload MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 19, 5:58pm, Ray Andrews wrote: } } By gum it works if you get it exactly right: } } -"zcompile ... (N-.:t)" ... or it barfs if there's a directory on the } same path. Fussy fussy. You *really* don't want that :t in there. } -"autoload +X -w ..." works with Sebastian's, but not with mine (which } are all functions). This is either because (a) you needed "zcompile -k ..." with yours, or (b) you have multiple functions per file, which we've already discussed at length with respect to autoload. [More on this below.] } -"autoload -w ..." works with mine but not Sebastian's. I think "autoload" is entirely superfluous in this case, because: } -"source miscfunctions" *before* calling an autoloaded function to have } it work the first time. Er, no. In that case it's 99% certain the function isn't autoloaded at all, rather it's simply been fully defined during the "source" command. The "source" command is probably reading miscfunctions.zwc, though. } -Append new dirs to FPATH or other things break. I have no idea whether that means "the FPATH has to contain some new stuff" or also "... and the new stuff has to go at the end, it can't be put anywhere else". Either could be true or false depending on the context. } I guess the zcompile of my dreams would be able to process both } scripts and functions in one go This has nothing to do with zcompile output and everything to do with how the result is read back. Scripts you want to "source ..." and functions you want to define (and possibly also call, if defining is happening as part of deferred loading). (Maybe we should never have created the "autoload" command, because that name just muddles up the act of creating a placeholder for deferred loading with the actual deferred loading event itself.) [I just noticed that the doc for zcompile refers to "execution of scripts". This is misleading, it should say "sourcing of scripts". Execution (as in spawning a new shell to run a file that has execute mode bit set) does not involve loading .zwc files; only "source" and "." do that.] Also zcompile has no way to guess if the file it's being used on is a source-able script or a function body. You'd need to tell it which, somehow. So "all in one go" would become some convoluted thing like zcompileOfMyDreams --script=miscfunctions --function=n-list ... } and be able to see the functions in 'miscfunctions' regardless of } the filename This is for all practical purposes impossible to do automatically. In order to know what functions are in "miscfunctions", zcompile would have to first *run* (source) that file, which might have other side effects besides just defining the functions themselves. Neverthe less zcompile does have a way to do what you're asking, assuming you know there are no side-effects: ( # subshell so as not to muck up the parent unfunction -m \* # clean out all extra functions source miscfunctions # load the functions we care about zcompile -a -c miscfunctions.zwc # compile all the functions ) Note that here you are explicitly doing the "run that file" step. } and not try to digest existing .zwc's, } and not worry about directories. This is a philosophical issue along the same lines as CSH_NULL_GLOB. If I name a bunch of things and some of them are wrong, should the shell complain about them or not, and either way, should it skip them and continue working on the ones that are correct? Which is more likely to produce the final result that the user expected? Since the user is perfectly capable of filtering these out when the argument list is built, I think the decision to complain and stop is the correct one. } And the autoload of my dreams would be able to pass all of it back } every time. Maybe if you try replacing "autoload" with its synonym "functions -u" (create an undefined function) in your mental map, you'd get a better idea of what you're asking. What would it mean to create an undefined script? What event would cause it to become defined?