Re: ideas, questions, and bugs (?)

Re: ideas, questions, and bugs (?)

[Peter Stephenson]

Andrew Main wrote:
> What happened to trashzleptr being initialised to an empty function?

Sorry, wasn't quite clear (I've restricted this to zsh-workers).

If there are shared libraries, but zle is linked in directly, this
initialisation doesn't happen, it's just left to zero, and the real
trashzleptr is resolved later, but too late for the zerr resulting from
a script not found.  I need to link zle in to make its symbols
available to other shared libraries.  Maybe the fix is therefore to
initialise to a dummy function in any case.

-- 
Peter Stephenson <pws@ifh.de>       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.

Re: ideas, questions, and bugs (?)

[Stefan Monnier]

Tim Writer <Tim.Writer@ftlsol.com> writes:
>     rsh thathost xterm -display thishost:0.0
> The shell running inside xterm is interactive, but it's not a login shell, so
> it won't have EDITOR, HISTFILE, etc. which is probably not what you want.  Of

Common problem. Also happens with most XDM configurations.
I end up also putting everything in zshenv protected by a test:

        if [[ -z $MyEnv ]]; then
                export PATH=blablabla
                export CVS_RSH=ssh
                ...
        fi

my zlogin is always empty because I happen not to need to start anything when
logging in.


        Stefan

Re: ideas, questions, and bugs (?)

[Bart Schaefer]

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.[45], 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
http://www.well.com/user/barts              http://www.brasslantern.com