From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12132 invoked by alias); 30 Apr 2012 05:05:07 -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: 17050 Received: (qmail 14006 invoked from network); 30 Apr 2012 05:05:04 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW, T_DKIM_INVALID autolearn=no version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.160.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=aoQXfY0lH+dFtI8dJnw6hesvnQnNruL7q8BniCA+ANg=; b=M5SgDq2WTky2kwh7kmEvbrsQujmb4k/tJrt5rlN9sXHOlSLaMIJK1YZG54dp9lHnf8 lheLPROzFDfbCopIa72xx2v4Sl7BDNrw986Xb9Buixnhd8QjZOzlKrlSNPP8cvSQuLLA AoHF7kkWvDYFk3pLApefXR16waNgafOKgeG1evGxMIZSXNSi8gbRZ0PYJ1Ehp9+1A0ht MvJslKON0o+E/DzzyZ0AZ7OcZMg7qq3XYVoEqqIBQoIfLOL24S+MfDc91KMF+h6x+GeU /EfoUAs6DfCOmPuxNyXntHIRmm3v1Fb13rYydslNeUKPaoaGfOlxvb29x8HX+86x56LE 2czw== References: <11E3E5A7F06F49C2B05AD5289019FC72@gmail.com> <120429172415.ZM8837@torch.brasslantern.com> From: TJ Luoma In-Reply-To: <120429172415.ZM8837@torch.brasslantern.com> Mime-Version: 1.0 (1.0) Date: Mon, 30 Apr 2012 01:04:54 -0400 Message-ID: <-840557096841281898@unknownmsgid> Subject: Re: compinit causes completion to fail? To: Bart Schaefer Cc: "zsh-users@zsh.org" Content-Type: text/plain; charset=UTF-8 On Apr 29, 2012, at 8:26 PM, Bart Schaefer wrote: On Apr 29, 2:57am, TJ Luoma wrote: } } IFS=' } ' } } is what was causing the problem. Could you say a bit more about exactly how this caused a problem? In normal circumstances the value of IFS shouldn't affect parsing of scripts etc., it should only affect "read" and parameter substitution. So I'm puzzled as to how you got the command-not-found symptom. Well, I don't know exactly either. Here's what I did: I had split my zshenv and zshrc files into several files. The ~/.zshenv was skeleton which sourced the other files as appropriate (aside: it does seem faster this way). But when I did that, completion broke with that "_normal not found" error. So I removed the ~/.zshenv file, and completion worked (with no customizations). {Note: by completion I mean just the basics: command completion and 'cd' completion.} Then I started sourcing files one at a time and testing completion (deleting ~/.zcompdump between each test by telling ~/.zlogout to delete the file and exiting the shell after each one). Completion broke ONLY when I added the explicit call to 'autoload' completion stuff, which seemed completely nonsensical. So I started all over again with a completely empty .zshenv EXCEPT for the calls the source the various files. I thought it might have to do with the *order* something was being loaded (bindkeys before setopts, etc) so I organized my .zshenv to source the files in a way that I thought made sense (i.e. environmental variables first, setting my prompt last, etc). I left everything commented out, and started un-commenting things one at a time, from the bottom-up (I don't know why I chose the bottom-up, it seemed like a good idea at the time). So it went like this: * uncomment last file-to-source from within .zshenv * start a new shell * test to see if command and 'cd' completion worked * exit shell (deleting ~/.zcompdump) * uncomment last-1 file-to-source from within .zshenv * start a new shell * test to see if command and 'cd' completion worked * exit shell (deleting ~/.zcompdump) and so on. When I got to the top of the .zshenv file, I realized completion STILL worked. So I looked at that .zshenv compared to the one I had used earlier (Thank you, Dropbox versioning!) The only difference was that the old .zshenv was that I had put in a few settings that I thought were important at the top of the .zshenv, including the IFS line. When I had a giant .zshenv/.zshrc file, the IFS line was after the completion stuff, but when I had broken it up into pieces, I thought that I should put the IFS near the top because it seemed like otherwise I might get inconsistent results. (Not sure if that would have been a problem, but that was my thinking.) I started adding those "odds and ends" back into the top of my .zshenv, and then did the same logout/login. Everything worked fine UNTIL I put the IFS line in at the top of the .zshenv. When I did that, completion broke. When I took it out, completion worked. Truthfully, I forgot why I had the IFS line in there, so I had to go back to Google (which wasn't easy) and realized that I had done that for when I was running a command and capturing the output into an array, and the output of the command might have newlines in it. I went *back* to Google and looked for an alternative, assuming that there was a better way. That's when I learned about defining IFS at the front of the array, like this: IFS=$'\n' array_of_lines=($(my_command)) or array_of_lines=("${(@f)$(my_command)}") (both of those examples gleaned from http://unix.stackexchange.com/questions/29724/how-to-properly-collect-an-array-of-lines-in-zsh FYI) Then I went to the bash-to-zsh book and learned more about it, or tried to. I think that's about all I can remember. No, I don't think it makes sense either. TjL