From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20769 invoked from network); 8 Oct 1997 08:25:40 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 8 Oct 1997 08:25:40 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id EAA18205; Wed, 8 Oct 1997 04:19:11 -0400 (EDT) Resent-Date: Wed, 8 Oct 1997 04:18:54 -0400 (EDT) Message-Id: <199710080819.KAA13588@hydra.ifh.de> To: zsh-users@math.gatech.edu (Zsh users list) Subject: Re: ideas, questions, and bugs (?) In-reply-to: "Quinn Dunkan"'s message of "Wed, 08 Oct 1997 00:11:51 MET." <199710080711.AAA01989@tammananny.tiger> Date: Wed, 08 Oct 1997 10:19:28 +0200 From: Peter Stephenson Resent-Message-ID: <"pLX5R3.0.rR4.j7qEq"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1058 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Quinn Dunkan wrote: > according to the zshmisc man page, a sublist is `one or more pipelines sepera > ted > by && or ||'. Then it says a list consists of one or more sublists optionall > y > 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. Yes, in fact the & in zsh really applies at the level of the pipeline, which is (necessarily) the same level that job control comes in. It certainly looks wrong, but it could be a pain to rewrite. > 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. I don't think there is one within the shell. You could make your own arrangement: add a line to .zshrc to . a particular file if it exists, then delete it, and write a trivial script which creates the file, then exec's zsh. There are no doubt equally unpleasant ways. > 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] ? This is now fixed, but I couldn't tell you since when now is. > 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 As far as I can tell, this is fixed, or maybe I have something set differently: there's certainly a default path here. What isn't yet fixed is that with shared libraries, zle doesn't get linked in until late in the initialisation, and zerr tries to call trashzle(), with the result that `zsh unknown-file' dumps core. I haven't found a cleaner fix than adding if (trashzleptr) to zerr(). -- Peter Stephenson Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, Platanenallee 6, 15738 Zeuthen, Germany.