From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20352 invoked from network); 8 Oct 1997 07:28:45 -0000 Received: from ns2.primenet.com.au (7795@203.24.36.3) by ns1.primenet.com.au with SMTP; 8 Oct 1997 07:28:45 -0000 Received: (qmail 904 invoked from network); 8 Oct 1997 07:28:41 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns2.primenet.com.au with SMTP; 8 Oct 1997 07:28:41 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id DAA17196; Wed, 8 Oct 1997 03:12:33 -0400 (EDT) Resent-Date: Wed, 8 Oct 1997 03:11:51 -0400 (EDT) Recieved: from tammananny.tiger (quinn@tammananny.tiger [127.0.0.1]) by tammananny.tiger (8.8.7/petrouchka) with ESMTP id AAA01989 for ; Wed, 8 Oct 1997 00:11:53 -0700 Message-Id: <199710080711.AAA01989@tammananny.tiger> To: zsh-users@math.gatech.edu Subject: ideas, questions, and bugs (?) Date: Wed, 08 Oct 1997 00:11:51 -0700 From: Quinn Dunkan Resent-Message-ID: <"YY7j12.0.5C4.t8pEq"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1057 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Well, I'm new to this list, and here I go posting a big huge long suggestion list. I looked through the archives and didn't find other people mentioning any of these things, though. It could very well be many of these suggestions require applying existing features in ways I haven't thought of. So, I ask your patience in reading this, it's kinda long. according to the zshmisc man page, a sublist is `one or more pipelines seperated by && or ||'. Then it says a list consists of one or more sublists optionally terminated with ;, &, &|, &!, or \n. So it should be possible to do: command1 && command2 & and have the whole conditional execute in the background. Unfortunately, zsh runs command1 in the foreground, and if command1 returns 0, runs command2 in the background. Bash handles this command properly, btw. Even csh does this right, for goodness sake. Ok, so (cmd1 && cmd2) & works, but according to the man page I shouldn't have to do that. I had a few problems compiling zsh 3.1.2. Of course, it is an alpha release, so I didn't expect a pain-free installation, but my difficulties seemed unusually great. I wound up changing the configure script (dlopen is in -ldl on my linux system), and altering zshxmods.h and bltinmods.list to get a modular binary. I probably should have just altered the .conf files, but the comments seemed to indicate they were already right, and my changes didn't have any effect anyway. When chaselinks is off, there is a problem that the shell's idea of .. is different from another program's idea. So if you do 'cd symlink', zsh's pwd (and the %~ PS1 escape sequence) reports you as being in /old/path/symlink. However, you are _really_ in /path/symlink/points/to. So if you do 'ls ../foo', zsh looks for /path/symlink/points/foo. If you do 'cd ..; ls foo', zsh looks for /old/path/foo. What I would like is an option that makes it so that when chaselinks is off, zsh acts as if you really are in the fake zsh path, so it would 'expand' /old/path/symlink/../foo to /old/path/foo. Since programs being run have no idea if chaselinks is on or not, zsh would have to do this expansion itself. It seems it wouldn't be hard to just have every '..' in the path cancel out its parent. Here's a random idea: it would be interesting to generalize the $PATH facility so one could set up user defined path vars, and use a compctl-like command to assign them to commands and parts of commands. So, for example, you could do GFXPATH=".:$HOME/gfx/jpg:$HOME/gfx/ppm" assignpath GFXPATH /usr/local/bin/pbm/*(:t) djpeg cjpeg Then, if you type 'djpeg foo.jpg >foo.ppm', zsh will search through $GFXPATH for foo.jpg. Of course, we'd use a zsh-style $gfxpath array. I'm not sure how useful this would actually be. A nitpick: in the COMMAND EXECUTION section of zshmisc, it would be nice to mention the pathdirs option, I read that and assumed zsh couldn't do rc style path searching, then found pathdirs in zshoptions later. A $LASTPID or something parameter, which is the pid of the last command run. Yes, I know about $!, but that only works if the process is &ed and not at all if it forks like a daemon (or maybe daemons pitchfork() ?). Many daemons don't make nice .pid files, and it can be hard to figure out what you just started if there are many by the same name (the only thing I can figure out is to stat /proc/pids_of_a_certain_name for one with a timestamp that matches with one when I started the daemon (if you have a procfs), but that's not ideal). As much as I try, I can't figure out a good way to have zsh execute some command at startup and stay in interactive mode. What I mean is, I would like a command-line switch like -c but for interactive shells. E.g. one could set up special zsh sessions with % zsh -fr '. $HOME/.special.zshrc' where % zsh -c foo is equivalent to % zsh -r 'exec foo' I thought +t might do something like this, unfortunately even with -s it doesn't seem to consider a pipe `standard input', so % echo '. $HOME/.special.zshrc' | zsh -s +t is a no go. well, I had a description of zsh's autorepeat freezing like Paul Janzen mentioned a while ago, and then found some comments about $BAUD, setting it to 0 fixed the problem. if zsh gets a parsing error in an rc file, you get something like: zsh: unmatched ' [97] with no indication of what rc file bombed. Would it be possible to include the name of the file it came from (how it works for .), so you get ~me/.zshrc: unmatched ' [97] ? instead of just beeping when the user attempts to scroll the history past the current line, zsh should just predict the user's next command, so you could have a forward 'history' as well. Of course, you could also use this for command line completion: just hit to complete your next command and execute it, if you don't feel like typing the whole thing in. The prediction algorithm would be simple: just have the user scan in his brain and run an emulation in a sub process. Use dup() to copy all the user's input and pipe it to the simulation, it ought to think the same thing he's thinking of. This might not work for non-determinists, though. Another approch for those too cheap to buy a brain-scanner (or for ancient unices without /dev/brain support) would be to construct a markov chain. It would take a little while to get reasonably accurate, but after a month or so of learning it might work ok. oh, and to Jose Unpingco who mentioned dvorak, it's much easier to change the keymap at the terminal driver level, instead of individual apps. various unices have different methods of changing keymaps at the console, but xmodmap always works for X, of course. I use dvorak exclusively, especially in vi, I have no problems. In fact, I find vi keys (especially hjkl) awkward under qwerty (having right-left on one hand and up-down on the other keeps me un-confused). 'zshrc' is tons of fun to type in dvorak, but not as much fun as 'fvwmrc' To add some more confusion to the rc file thread, I don't quite understand the reasons for zprofile/zlogin. Ok, so you could use zlogin to override commands in zshrc for login shells... but is this really useful? I can't think of any situation that would require this (how many people have non-interactive login shells?), but it's obviously there for a reason, so maybe someone can help me out here. Also, is it better to stick vars in zlogin and export them so future shells inherit them, or put things like PATH, MANPATH, HOSTNAME, etc. in zshenv? I tend to go for the zshenv route, since I don't want different behaviour from scripts run from cron, for instance, but is this a bad idea? In fact, my zlogin is empty, everything that non-interactive zshs may want is in zshenv, everything else in zshrc. Is it better to let progs inherit their enviroments rather than rescan a large /etc/zshenv every time? The only thing I can think of to put in zlogin is things like `fortune'. I kept wondering where these run-help and which-command aliases were coming from... took a look in hashtable.c and found out that they're hard coded! I don't think they should be (since if you make a run-help function it will mysteriously not work right until you unalias run-help, despite the fact that you never set it in the first place), but in any case, it would be nice if the man pages were a little more explicit about that (they're defined even when zle is unloaded!), and any other surprises that may be lurking in the name space. My zsh 3.1.2 segfaults when it can't find PATH. This seems like a bug. % unset PATH;/bin/zsh-3.1.2 # always segfaults on my system. % unset PATH;/bin/zsh # works fine In zsh 3.0.0, PATH always reflecs path, and vice-versa. In zsh 3.1.2, PATH reflects path only if PATH is set. That means that given: % unset PATH % path=(/bin /usr/bin) zsh 3.0.0 % echo $PATH /bin:/usr/bin zsh 3.1.2 % echo $PATH (nothing) However, given: % unset PATH % PATH= % path=(/bin /usr/bin) % export PATH Both 3.0.0 and 3.1.2 work correctly. So for now I have PATH= in my zshenv as a workaround. Oh, and does anyone know a way to reprint the prompt? I want to make a widget: function vi-cmd-mode-boldps { PS1='%B%#%b '; zle redraw-line; zle vi-cmd-mode } and according ones for a, A, i, I, etc. that unbold the prompt, the idea being that I can have a nice reminder of what keymap I'm in. I tested this with zle clear-screen instead of the (nonexistent) redraw-line, and the prompt came back mangled (spaces and high chars), but if I hit enter it's like it should be. Also, there's a little pause whenever I invoke the widget, which would make it unusable (too annoying), even if clear-screen didn't already. So what am I doing wrong?