http://permalink.gmane.org/gmane.comp.shells.zsh.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.shells.zsh.user/8644 } } while I generally love the vi mode (which more software should have), } there is a minor quirk: when I recall a previous command line (by } pressing the up arrow), the cursor is at the beginning rather than the } end of the command line. You're seeing the difference between the "up-line-or-history" widget and the "vi-up-line-or-history" widget (and similarly for "down-"). The vi- widgets move the cursor to the beginning of the line while moving up and down, and the others move it to the end. What's puzzling to me is that the *default* bindings for the history motions are the other ones, even in the vi keymaps. So in order for you to have the behavior you're describing, you (or someone who put bindings in your /etc/z* files) must have explicitly bound the arrow keys to the vi widgets. Bart Schaefer 2008-10-08T01:40:36 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8643 Matthias Rampke <matthias.rampke< at >googlemail.com>: [...] Yes, you can just bind the emacs widgets you want to the appropriate keys in viins and vicmd. Regards, Frank Frank Terbeck 2008-10-07T18:43:44 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8641 On Tue, 7 Oct 2008 08:59:52 +0800 "Aaron Davies" <aaron.davies< at >gmail.com> wrote: There is certainly no way of producing *exactly* the same results, since massively more completions are enabled on purpose, but the basic options for what happens when you hit tab etc. are the same as with the old system, so you shouldn't need to change anything. The options like AUTO_LIST, BASH_AUTO_LIST, MENU_COMPLETE, etc., as given in the zshoptions manual page have just the same effect. If you need a guide, there are two I know about: the one online at http://zsh.sourceforge.net/Guide/zshguide.html (look for chapter 6), and the book, see http://www.bash2zsh.com/ . However, you're never going to find a guide that tells you how to configure every possible command. For things like host names, you need to know about styles as described in the zshcompsys manual page. The style in question is "hosts" and there is an example for it in the overview section of "Completion System Configuration". Peter Stephenson 2008-10-07T08:53:39 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8640 i love the idea of a fully-customizable completion system, but every time i turn it on, i get horribly confused by the configuration system, get annoyed at the changes to my UI, and give up and go back to plain completion. two questions: is there a way to set up compinit completion so as to produce exactly the same results in all cases as "default" completion? i have a lot of muscle memory invested in things like "hit tab twice to start iterating through list of candidates", and it's when things like that change on me (and their customization is spread over four options each five levels down in different parts of the compinstall menu system) that i get bored and give up. i would love to be able to turn on the advanced completion, have nothing change, and be able to start experimenting from that point. pursuant to that, my second question: is there a guide to completion that's oriented towards working on one specific feature at a time (e.g., just add hostname completion for ssh)? Aaron Davies 2008-10-07T00:59:52 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8639 Eric P. Mangold yazmış: Here's a snippet from my zshrc which does it, not sure if it's perfect though. DIRSTACKSIZE=32 DIRSTACKFILE="${HOME}"/.zdirs autoload -U is-at-least # Keep dirstack across logouts if [[ -f ${DIRSTACKFILE} ]] && [[ ${#dirstack[*]} -eq 0 ]] ; then dirstack=( ${(f)"$(< $DIRSTACKFILE)"} ) dirstack=( ${(u)dirstack} ) fi # Make sure there are no duplicates typeset -U dirstack # Share dirstack between multiple zsh instances function chpwd() { if is-at-least 4.1; then # dirs -p needs 4.1 # Get the dirstack from the file and add it to the current dirstack dirstack+=( ${(f)"$(< $DIRSTACKFILE)"} ) dirstack=( ${(u)dirstack} ) dirs -pl |sort -u >! ${DIRSTACKFILE} fi } Ali Polatel 2008-10-05T01:30:38 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8638 Hi, I'm looking for a way to transparently share a single directory stack between multiple instances of zsh in the same fashion as shared history. I note the zsh-workers thread here which raises the same question: http://www.zsh.org/mla/workers/2007/msg00691.html Has anyone implemented this yet? -teratorn Eric P. Mangold 2008-10-05T00:27:12 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8637 } } > 1. There's something weird about completion of 'init.d' scripts with the } > '<filename' form. The simplest example I could find: } } There certainly is: [...] } in other words *any* completion from *anywhere* involving files in an init } and an rc directory tries to treat it as if it was a service to be started } or stopped. It seems hard to believe this is the right thing to do. I'm sure that's because you might run any of /etc/init.d/service sh /etc/init.d/service sh -x /etc/init.d/service or even pathologically I suppose /bin/sh < /etc/init.d/service (also any of same with one from /rc.d/*.d instead). Bart Schaefer 2008-10-01T14:53:23 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8636 On 05.09.2008, at 17:08, Bart Schaefer wrote: I prefer the {}always{} way, but both proposals helped me learn a lot, thanks. Sebastian Sebastian Stark 2008-10-01T12:48:35 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8635 On Tue, 30 Sep 2008 22:37:48 -0400 (EDT) "Benjamin R. Haskell" <zsh< at >benizi.com> wrote: There certainly is: completion for these files is in Completion/Unix/Command/_init_d which asks to be called as #compdef -p */(init|rc[0-9S]#).d/* in other words *any* completion from *anywhere* involving files in an init and an rc directory tries to treat it as if it was a service to be started or stopped. It seems hard to believe this is the right thing to do. That's because the file is coming from stdin, so it doesn't see the file name and can't tell it's a .html file. It's a necessary feature of the way READNULLCMD works that it does read from stdin, so that can't really be changed. However, there may be a workaround. Peter Stephenson 2008-10-01T11:40:53 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8634 } } It seems that _history will give "Star\ " as a completion instead of } "Star\ Trek", given that "Star\ Trek" is in $historywords. I see no } obvious way of fixing this. Anyone have any suggestions? Would you please give steps to reproduce this, including showing via which completion you invoked _history? I can get some strange stuff to happen with _history-complete-older but I haven't stumbled on anything that seems to match what you described. Here's an example of a strange one I did get: schaefer<503> print 'foo bar' foo bar schaefer<504> echo ' (press escape slash after that single quote) schaefer<504> echo ''foo bar'' zsh: do you wish to see all 1520 possibilities (1523 lines)? Bart Schaefer 2008-10-01T06:23:49 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8633 Two issues related to READNULLCMD (one of the features I looove about Zsh): 1. There's something weird about completion of 'init.d' scripts with the '<filename' form. The simplest example I could find: # </etc/init.d/<Tab> [no completion] # rsync -av /etc/init.d/ /etc/notinitd/ [... showing it's not something in the directory...] # </etc/notinitd/<Tab> zsh: do you wish to see all 101 possibilities (15 lines)? It looks like init.d is special-cased somehow. Running with '-x', I see the following (among other output) when <Tab>-ing: +_init_d:3> local magic cmds what script opts +_init_d:5> _compskip=all +_init_d:9> script=/etc/init.d/ +_init_d:10> [[ /etc/init.d/ == '*/*' ]] +_init_d:11> [[ ! -f /etc/init.d/ ]] +_init_d:12> _message 'init.d is not an init script' But it's odd that it's not special-cased for other forms: $ cat < /etc/init.d/<Tab> zsh: do you wish to see all 101 possibilities (15 lines)?n $ less < /etc/init.d/<Tab> zsh: do you wish to see all 101 possibilities (15 lines)?n 2. The Benjamin R. Haskell 2008-10-01T02:37:48 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8632 It seems that _history will give "Star\ " as a completion instead of "Star\ Trek", given that "Star\ Trek" is in $historywords. I see no obvious way of fixing this. Anyone have any suggestions? Nikolai Weibull 2008-09-30T20:12:40 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8631 Most of you probably won't notice, but Sourceforge notified us: On 2008-09-30 (Tuesday), project CVS service will be taken offline at 17:00 UTC for not more than 8 hours to permit the migration of service to the new Chicago datacenter.On 2008-09-30 (Tuesday), project CVS service will be taken offline at 17:00 UTC for not more than 8 hours to permit the migration of service to the new Chicago datacenter. Bart Schaefer 2008-09-29T18:08:20 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8630 On Sun, 28 Sep 2008 15:19:37 -0400 "Rocky Bernstein" <rocky.bernstein< at >gmail.com> wrote: exec.c:parse_string() resets the line number for every invocation. That's fine for eval, where we've fixed this up explicitly, but doesn't work in the call from exec.c:getoutput() which is the case here. Obviously that's not consistent with the fact that it doesn't have its own file; we don't do the special eval handling of reconstructing the file location in this case. The reason (...) is different is it's parsed straight away when the shell reads it in; it's not stored as a string argument to be looked at again later. It's possible we can simply get away with not resetting the line number in any case without its own entry on the function stack. That's about the simplest fix, but changes the meaning of line numbers in all string evaluations apart from eval, trap and functions, where we have the special handling. I'm coming round to the view that this is nonetheless the best way of salvaging consistency of the debugg Peter Stephenson 2008-09-28T21:16:51 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8629 There is what looks to me a bug in the recent funcfiletrace that I've been trying to isolate. I've spent the weekend on this and have made some progress but have to stop now. Perhaps there's someone out there who can help further pinpoint this bug. You'll need the most recent zsh in CVS. If you have zshdb installed (and chances are you don't) you can see the bug by running this program under the debugger #!/usr/local/bin/zsh # Test debugger handling of subshells ( x=$(print 5; print 6) ) Below I'll show output from a sample session using the debugger. I've put comments to the side (in #) to try to explain what's going on. $ zshdb -q /tmp/zshdb/testing.sh # run testing.sh (/tmp/zshdb/testing.sh:3): # file and line number ( x=$(print 5; print 6) ) # What's going to get run next zshdb<4> s # 's' issues a "step" command (/tmp/zshdb/testing.sh:4): x=$(print 5; print 6) # Note we are in a subshell zshdb<(5)> s # the () indicates Rocky Bernstein 2008-09-28T19:19:37 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8628 I'm in an directory with java sources, and I want to cvs update **/build.xml. cvs update **/build.xml<tab> I have it so that my completers are _expand then _complete, and first choice it offers is a list of all the files, which is what I want, so my choices are: 1. bin/a/b/c/build.xml bin/d/e/f/build.xml a/b/c/build.xml d/e/f/build.xml 2. bin/a/b/c/build.xml 3. bin/d/e/f/build.xml 4. a/b/c/build.xml 5. d/e/f/build.xml 6. foo/bar/build.xml Pressing Enter on choice 1. leads to a quick realization that bin/ directory is not under version control, so whole cvs command fails with unable to find CVS/Entries. After doing: zstyle ':completion:*expand*:*' ignored-patterns 'bin/*' The choices offered are: 1. a/b/c/build.xml 2. d/e/f/build.xml 3. foo/bar/build.xml As you can see the choice of all the completions together disappeared? It seems that the ignored-patterns is applied by _expand to the all-expansions completion thus disabling it. What I'm looking for is: 1. a/b/c/ Max Mikhanosha 2008-09-28T18:11:38 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8627 [SNIP] Stéphane and Mikael: thanks for your answers. It's clear now. Louis-David Mitterrand 2008-09-26T18:29:25 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8626 That's a problem with "transmission-remote". It expects a regular file and <(cat) is a pipe (transmission-remote and cat run concurrently). It's the same as: ssh remotehost "cat | transmission-remote -a /dev/stdin" < ~/torrent.file You could have done ssh remotehost "transmission-remote -a /dev/stdin" < ~/torrent.file In which case it would probably have been a pipe as well. $ ssh localhost lsof -ac lsof -d0 Password: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME lsof 13428 chazelas 0r FIFO 0,6 66743 pipe [...] Here, zsh creates a temp file. cat and transmission-remote are run sequencially (zsh waits for cat to finish fill up the temp file and then runs transmission-remote with that temp file name as argument), it's the same as ssh remotehost "cat > tempfile; transmission -a tempfile" < ~/torrent.file Stephane Chazelas 2008-09-26T18:08:16 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8625 2008/9/26 Louis-David Mitterrand <vindex+lists-zsh-users< at >apartia.org>: Presumably for the reasons stated by the program. <() gives you a symlink to an fd, while =() gives you a temporary file in /tmp which is seekable and all that. Mikael Magnusson 2008-09-26T18:07:01 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8624 Hi, when trying this: % ssh remotehost "transmission-remote -a <(cat)" < ~/torrent.file I get this error: Couldn't read "/proc/self/fd/11": Not a regular file Couldn't add file: /proc/self/fd/11 However when using: % ssh remotehost "transmission-remote -a =(cat)" < ~/torrent.file all is well. Why doesn't the first form work? Thanks, Louis-David Mitterrand 2008-09-26T17:30:52 http://permalink.gmane.org/gmane.comp.shells.zsh.user/8623 On Wed, 24 Sep 2008 14:00:17 +0200 "Mikael Magnusson" <mikachu< at >gmail.com> wrote: It looks like it is. The reason this shows up is that spell checking simply sets a flag in the history mechanism that the line currently being parsed isn't to be executed when it's finished. However, I think that if that flag is set there is no point in reporting any syntax errors since the code isn't going to be executed. Index: Src/parse.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/parse.c,v retrieving revision 1.74 diff -u -r1.74 parse.c --- Src/parse.c11 Sep 2008 12:49:20 -00001.74 +++ Src/parse.c24 Sep 2008 19:04:38 -0000 < at >< at > -2205,12 +2205,14 < at >< at > for (t0 = 0; t0 != 20; t0++) if (!t || !t[t0] || t[t0] == '\n') break; - if (t0 == 20) -zwarn("parse error near `%l...'", t, 20); - else if (t0) -zwarn("parse error near `%l'", t, t0); - else -zwarn("parse error"); + if (!(histdone & HISTFLAG_NOEXEC)) { +if (t0 == 20) + zwarn("parse error Peter Stephenson 2008-09-24T19:10:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.shells.zsh.user