Zsh Mailing List Archive
Messages sorted by:
Re: ideas, questions, and bugs (?)
- X-seq: zsh-workers 3562
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx, Andrew Main <zefram@xxxxxxxxx>, Quinn Dunkan <quinn@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: ideas, questions, and bugs (?)
- Date: Wed, 8 Oct 1997 09:26:17 -0700
- In-reply-to: <199710080711.AAA01989@xxxxxxxxxxxxxxxx>
- In-reply-to: <199710080934.KAA07190@xxxxxxxxxxxxxxxx>
- References: <199710080711.AAA01989@xxxxxxxxxxxxxxxx> <199710080934.KAA07190@xxxxxxxxxxxxxxxx>
On Oct 8, 10:34am, Andrew Main wrote:
} Subject: Re: ideas, questions, and bugs (?)
} >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.
} Funnily enough, `interactive' implies interaction with the user. If you
} want interaction in a shell script, use vared.
The documentation should probably explain that -s and -i are mutually
exclusive and that -i always wins. Given just what's written down, one
would think that
echo 'echo foo ; exec < /dev/tty' | zsh -si
would "do the right thing".
} >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.
} I'd already considered doing this; history references like "!+1" ought
} to work. Of course, to get commands from future sessions you'll need
} a history file saved on a trfs (temporally reversed filesystem -- the
} media uses positrons instead of electrons).
Something I've been wishing for was a variant of infer-next-history that
would work like this:
If the current command line is either empty or matches "!-1", then search
backwards from "!-2" for another occurrence of the same line, and infer
the event that follows it.
However, at the moment in zsh-3.0., I can't get infer-next-history to
do anything other than beep at me no matter what the current line looks
like nor what's in the history. Is it just me?
} >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.
} This is a feature. Don't unset PATH if you want it to be available.
Um, what feature is this supposed to be providing? And it shouldn't seg
fault in any case.
On Oct 8, 12:11am, Quinn Dunkan wrote:
} My zsh 3.1.2 segfaults when it can't find PATH. This seems like a bug.
Bart Schaefer Brass Lantern Enterprises
Messages sorted by: