zsh-workers
 help / Atom feed
* Bug Report
@ 1995-08-24 11:23 Carsten Friedrich
  0 siblings, 0 replies; 27+ messages in thread
From: Carsten Friedrich @ 1995-08-24 11:23 UTC (permalink / raw)
  To: zsh-workers


Hi,

I'm using zsh-2.6-beta9 on sparcs running solaris 2.4. I found the
following Bug:

> *<tab>

produces:

> *-
zsh: do you wish to see all 1897 possibilities? y

Program received signal SIGSEGV, Segmentation fault.

As the resulting stack (compiled with -g) only consists of garbage I will
not include it. This behavior is not alterer if using no optimization
flags.

output of reporter at the end of the mail. I got many 
awk: syntax error near line x
awk: illegal statement near line x
errors while runnning reporter

I'm not on the zsh mailing list.

greetings
carsten

p.s> I deleted some lines reoprter generated, which I don't want to become
public, like information about user names/ids, hostsnames etc. If you
absolutly need this informatin, please contact me.



# START zsh saveset
# uname:  SunOS bartok 5.4 Generic_101945-13 sun4m sparc

# Aliases.

alias run-help='man'
alias which-command='whence'

# Key bindings.

bindkey -r "^@"
bindkey -r "^A"
bindkey -r "^B"
bindkey -r "^C"
bindkey -r "^D"
bindkey -r "^E"
bindkey -r "^F"
bindkey -r "^G"
bindkey -r "^H"
bindkey -r "^I"
bindkey -r "^J"
bindkey -r "^K"
bindkey -r "^L"
bindkey -r "^M"
bindkey -r "^N"
bindkey -r "^O"
bindkey -r "^P"
bindkey -r "^Q"
bindkey -r "^R"
bindkey -r "^S"
bindkey -r "^T"
bindkey -r "^U"
bindkey -r "^V"
bindkey -r "^W"
bindkey -r "^X"
bindkey -r "^Y"
bindkey -r "^Z"
bindkey -r "\e"
bindkey -r "^_"
bindkey -r "^?"
bindkey -r "^X^B"
bindkey -r "^X^F"
bindkey -r "^X^J"
bindkey -r "^X^K"
bindkey -r "^X^N"
bindkey -r "^X^O"
bindkey -r "^X^U"
bindkey -r "^X^V"
bindkey -r "^X^X"
bindkey -r "^X*"
bindkey -r "^XG"
bindkey -r "^Xg"
bindkey -r "^Xr"
bindkey -r "^Xs"
bindkey -r "^Xu"
bindkey -r "\e^D"
bindkey -r "\e^G"
bindkey -r "\e^H"
bindkey -r "\e^I"
bindkey -r "\e^J"
bindkey -r "\e^L"
bindkey -r "\e^M"
bindkey -r "\e^_"
bindkey -r "\e "
bindkey -r "\e!"
bindkey -r "\e\""
bindkey -r "\e$"
bindkey -r "\e'"
bindkey -r "\e-"
bindkey -r "\e."
bindkey -r "\e0"
bindkey -r "\e1"
bindkey -r "\e2"
bindkey -r "\e3"
bindkey -r "\e4"
bindkey -r "\e5"
bindkey -r "\e6"
bindkey -r "\e7"
bindkey -r "\e8"
bindkey -r "\e9"
bindkey -r "\e<"
bindkey -r "\e>"
bindkey -r "\e?"
bindkey -r "\eA"
bindkey -r "\eB"
bindkey -r "\eC"
bindkey -r "\eD"
bindkey -r "\eF"
bindkey -r "\eG"
bindkey -r "\eH"
bindkey -r "\eL"
bindkey -r "\eN"
bindkey -r "\eP"
bindkey -r "\eQ"
bindkey -r "\eR"
bindkey -r "\eS"
bindkey -r "\eT"
bindkey -r "\eU"
bindkey -r "\eW"
bindkey -r "\e[A"
bindkey -r "\e[B"
bindkey -r "\e[C"
bindkey -r "\e[D"
bindkey -r "\e_"
bindkey -r "\ea"
bindkey -r "\eb"
bindkey -r "\ec"
bindkey -r "\ed"
bindkey -r "\ef"
bindkey -r "\eg"
bindkey -r "\eh"
bindkey -r "\el"
bindkey -r "\en"
bindkey -r "\ep"
bindkey -r "\eq"
bindkey -r "\er"
bindkey -r "\es"
bindkey -r "\et"
bindkey -r "\eu"
bindkey -r "\ew"
bindkey -r "\ex"
bindkey -r "\ey"
bindkey -r "\ez"
bindkey -r "\e|"
bindkey -r "\e^?"

bindkey "^@"	set-mark-command
bindkey "^A"	beginning-of-line
bindkey "^B"	backward-char
bindkey "^C"	undefined-key
bindkey "^D"	delete-char-or-list
bindkey "^E"	end-of-line
bindkey "^F"	forward-char
bindkey "^G"	send-break
bindkey "^H"	backward-delete-char
bindkey "^I"	expand-or-complete
bindkey "^J"	accept-line
bindkey "^K"	kill-line
bindkey "^L"	clear-screen
bindkey "^M"	accept-line
bindkey "^N"	down-line-or-history
bindkey "^O"	accept-line-and-down-history
bindkey "^P"	up-line-or-history
bindkey "^Q"	push-line
bindkey "^R"	history-incremental-search-backward
bindkey "^S"	history-incremental-search-forward
bindkey "^T"	transpose-chars
bindkey "^U"	kill-whole-line
bindkey "^V"	quoted-insert
bindkey "^W"	backward-kill-word
bindkey "^X"	prefix
bindkey "^Y"	yank
bindkey "^Z"	undefined-key
bindkey "\e"	prefix
bindkey "^_"	undo
bindkey "^?"	backward-delete-char
bindkey "^X^B"	vi-match-bracket
bindkey "^X^F"	vi-find-next-char
bindkey "^X^J"	vi-join
bindkey "^X^K"	kill-buffer
bindkey "^X^N"	infer-next-history
bindkey "^X^O"	overwrite-mode
bindkey "^X^U"	undo
bindkey "^X^V"	vi-cmd-mode
bindkey "^X^X"	exchange-point-and-mark
bindkey "^X*"	expand-word
bindkey "^XG"	list-expand
bindkey "^Xg"	list-expand
bindkey "^Xr"	history-incremental-search-backward
bindkey "^Xs"	history-incremental-search-forward
bindkey "^Xu"	undo
bindkey "\e^D"	list-choices
bindkey "\e^G"	send-break
bindkey "\e^H"	backward-kill-word
bindkey "\e^I"	self-insert-unmeta
bindkey "\e^J"	self-insert-unmeta
bindkey "\e^L"	clear-screen
bindkey "\e^M"	self-insert-unmeta
bindkey "\e^_"	copy-prev-word
bindkey "\e "	expand-history
bindkey "\e!"	expand-history
bindkey "\e\""	quote-region
bindkey "\e$"	spell-word
bindkey "\e'"	quote-line
bindkey "\e-"	neg-argument
bindkey "\e."	insert-last-word
bindkey "\e0"	digit-argument
bindkey "\e1"	digit-argument
bindkey "\e2"	digit-argument
bindkey "\e3"	digit-argument
bindkey "\e4"	digit-argument
bindkey "\e5"	digit-argument
bindkey "\e6"	digit-argument
bindkey "\e7"	digit-argument
bindkey "\e8"	digit-argument
bindkey "\e9"	digit-argument
bindkey "\e<"	beginning-of-buffer-or-history
bindkey "\e>"	end-of-buffer-or-history
bindkey "\e?"	which-command
bindkey "\eA"	accept-and-hold
bindkey "\eB"	backward-word
bindkey "\eC"	capitalize-word
bindkey "\eD"	kill-word
bindkey "\eF"	forward-word
bindkey "\eG"	get-line
bindkey "\eH"	run-help
bindkey "\eL"	down-case-word
bindkey "\eN"	history-search-forward
bindkey "\eP"	history-search-backward
bindkey "\eQ"	push-line
bindkey "\eR"	toggle-literal-history
bindkey "\eS"	spell-word
bindkey "\eT"	transpose-words
bindkey "\eU"	up-case-word
bindkey "\eW"	copy-region-as-kill
bindkey "\e[A"	up-line-or-history
bindkey "\e[B"	down-line-or-history
bindkey "\e[C"	forward-char
bindkey "\e[D"	backward-char
bindkey "\e_"	insert-last-word
bindkey "\ea"	accept-and-hold
bindkey "\eb"	backward-word
bindkey "\ec"	capitalize-word
bindkey "\ed"	kill-word
bindkey "\ef"	forward-word
bindkey "\eg"	get-line
bindkey "\eh"	run-help
bindkey "\el"	down-case-word
bindkey "\en"	history-search-forward
bindkey "\ep"	history-search-backward
bindkey "\eq"	push-line
bindkey "\er"	toggle-literal-history
bindkey "\es"	spell-word
bindkey "\et"	transpose-words
bindkey "\eu"	up-case-word
bindkey "\ew"	copy-region-as-kill
bindkey "\ex"	execute-named-cmd
bindkey "\ey"	yank-pop
bindkey "\ez"	execute-last-named-cmd
bindkey "\e|"	vi-goto-column
bindkey "\e^?"	backward-kill-word

# Completions.


# Undefined functions.


# Defined functions.


# Limits.

limit datasize        2047MB
limit stacksize       8MB
limit descriptors     64
# START zsh saveset
# uname:  SunOS bartok 5.4 Generic_101945-13 sun4m sparc

# Aliases.

alias run-help='man'
alias which-command='whence'

# Key bindings.

bindkey -r "^@"
bindkey -r "^A"
bindkey -r "^B"
bindkey -r "^C"
bindkey -r "^D"
bindkey -r "^E"
bindkey -r "^F"
bindkey -r "^G"
bindkey -r "^H"
bindkey -r "^I"
bindkey -r "^J"
bindkey -r "^K"
bindkey -r "^L"
bindkey -r "^M"
bindkey -r "^N"
bindkey -r "^O"
bindkey -r "^P"
bindkey -r "^Q"
bindkey -r "^R"
bindkey -r "^S"
bindkey -r "^T"
bindkey -r "^U"
bindkey -r "^V"
bindkey -r "^W"
bindkey -r "^X"
bindkey -r "^Y"
bindkey -r "^Z"
bindkey -r "\e"
bindkey -r "^_"
bindkey -r "^?"
bindkey -r "^X^B"
bindkey -r "^X^F"
bindkey -r "^X^J"
bindkey -r "^X^K"
bindkey -r "^X^N"
bindkey -r "^X^O"
bindkey -r "^X^U"
bindkey -r "^X^V"
bindkey -r "^X^X"
bindkey -r "^X*"
bindkey -r "^XG"
bindkey -r "^Xg"
bindkey -r "^Xr"
bindkey -r "^Xs"
bindkey -r "^Xu"
bindkey -r "\e^D"
bindkey -r "\e^G"
bindkey -r "\e^H"
bindkey -r "\e^I"
bindkey -r "\e^J"
bindkey -r "\e^L"
bindkey -r "\e^M"
bindkey -r "\e^_"
bindkey -r "\e "
bindkey -r "\e!"
bindkey -r "\e\""
bindkey -r "\e$"
bindkey -r "\e'"
bindkey -r "\e-"
bindkey -r "\e."
bindkey -r "\e0"
bindkey -r "\e1"
bindkey -r "\e2"
bindkey -r "\e3"
bindkey -r "\e4"
bindkey -r "\e5"
bindkey -r "\e6"
bindkey -r "\e7"
bindkey -r "\e8"
bindkey -r "\e9"
bindkey -r "\e<"
bindkey -r "\e>"
bindkey -r "\e?"
bindkey -r "\eA"
bindkey -r "\eB"
bindkey -r "\eC"
bindkey -r "\eD"
bindkey -r "\eF"
bindkey -r "\eG"
bindkey -r "\eH"
bindkey -r "\eL"
bindkey -r "\eN"
bindkey -r "\eP"
bindkey -r "\eQ"
bindkey -r "\eR"
bindkey -r "\eS"
bindkey -r "\eT"
bindkey -r "\eU"
bindkey -r "\eW"
bindkey -r "\e[A"
bindkey -r "\e[B"
bindkey -r "\e[C"
bindkey -r "\e[D"
bindkey -r "\e_"
bindkey -r "\ea"
bindkey -r "\eb"
bindkey -r "\ec"
bindkey -r "\ed"
bindkey -r "\ef"
bindkey -r "\eg"
bindkey -r "\eh"
bindkey -r "\el"
bindkey -r "\en"
bindkey -r "\ep"
bindkey -r "\eq"
bindkey -r "\er"
bindkey -r "\es"
bindkey -r "\et"
bindkey -r "\eu"
bindkey -r "\ew"
bindkey -r "\ex"
bindkey -r "\ey"
bindkey -r "\ez"
bindkey -r "\e|"
bindkey -r "\e^?"

bindkey "^@"	set-mark-command
bindkey "^A"	beginning-of-line
bindkey "^B"	backward-char
bindkey "^C"	undefined-key
bindkey "^D"	delete-char-or-list
bindkey "^E"	end-of-line
bindkey "^F"	forward-char
bindkey "^G"	send-break
bindkey "^H"	backward-delete-char
bindkey "^I"	expand-or-complete
bindkey "^J"	accept-line
bindkey "^K"	kill-line
bindkey "^L"	clear-screen
bindkey "^M"	accept-line
bindkey "^N"	down-line-or-history
bindkey "^O"	accept-line-and-down-history
bindkey "^P"	up-line-or-history
bindkey "^Q"	push-line
bindkey "^R"	history-incremental-search-backward
bindkey "^S"	history-incremental-search-forward
bindkey "^T"	transpose-chars
bindkey "^U"	kill-whole-line
bindkey "^V"	quoted-insert
bindkey "^W"	backward-kill-word
bindkey "^X"	prefix
bindkey "^Y"	yank
bindkey "^Z"	undefined-key
bindkey "\e"	prefix
bindkey "^_"	undo
bindkey "^?"	backward-delete-char
bindkey "^X^B"	vi-match-bracket
bindkey "^X^F"	vi-find-next-char
bindkey "^X^J"	vi-join
bindkey "^X^K"	kill-buffer
bindkey "^X^N"	infer-next-history
bindkey "^X^O"	overwrite-mode
bindkey "^X^U"	undo
bindkey "^X^V"	vi-cmd-mode
bindkey "^X^X"	exchange-point-and-mark
bindkey "^X*"	expand-word
bindkey "^XG"	list-expand
bindkey "^Xg"	list-expand
bindkey "^Xr"	history-incremental-search-backward
bindkey "^Xs"	history-incremental-search-forward
bindkey "^Xu"	undo
bindkey "\e^D"	list-choices
bindkey "\e^G"	send-break
bindkey "\e^H"	backward-kill-word
bindkey "\e^I"	self-insert-unmeta
bindkey "\e^J"	self-insert-unmeta
bindkey "\e^L"	clear-screen
bindkey "\e^M"	self-insert-unmeta
bindkey "\e^_"	copy-prev-word
bindkey "\e "	expand-history
bindkey "\e!"	expand-history
bindkey "\e\""	quote-region
bindkey "\e$"	spell-word
bindkey "\e'"	quote-line
bindkey "\e-"	neg-argument
bindkey "\e."	insert-last-word
bindkey "\e0"	digit-argument
bindkey "\e1"	digit-argument
bindkey "\e2"	digit-argument
bindkey "\e3"	digit-argument
bindkey "\e4"	digit-argument
bindkey "\e5"	digit-argument
bindkey "\e6"	digit-argument
bindkey "\e7"	digit-argument
bindkey "\e8"	digit-argument
bindkey "\e9"	digit-argument
bindkey "\e<"	beginning-of-buffer-or-history
bindkey "\e>"	end-of-buffer-or-history
bindkey "\e?"	which-command
bindkey "\eA"	accept-and-hold
bindkey "\eB"	backward-word
bindkey "\eC"	capitalize-word
bindkey "\eD"	kill-word
bindkey "\eF"	forward-word
bindkey "\eG"	get-line
bindkey "\eH"	run-help
bindkey "\eL"	down-case-word
bindkey "\eN"	history-search-forward
bindkey "\eP"	history-search-backward
bindkey "\eQ"	push-line
bindkey "\eR"	toggle-literal-history
bindkey "\eS"	spell-word
bindkey "\eT"	transpose-words
bindkey "\eU"	up-case-word
bindkey "\eW"	copy-region-as-kill
bindkey "\e[A"	up-line-or-history
bindkey "\e[B"	down-line-or-history
bindkey "\e[C"	forward-char
bindkey "\e[D"	backward-char
bindkey "\e_"	insert-last-word
bindkey "\ea"	accept-and-hold
bindkey "\eb"	backward-word
bindkey "\ec"	capitalize-word
bindkey "\ed"	kill-word
bindkey "\ef"	forward-word
bindkey "\eg"	get-line
bindkey "\eh"	run-help
bindkey "\el"	down-case-word
bindkey "\en"	history-search-forward
bindkey "\ep"	history-search-backward
bindkey "\eq"	push-line
bindkey "\er"	toggle-literal-history
bindkey "\es"	spell-word
bindkey "\et"	transpose-words
bindkey "\eu"	up-case-word
bindkey "\ew"	copy-region-as-kill
bindkey "\ex"	execute-named-cmd
bindkey "\ey"	yank-pop
bindkey "\ez"	execute-last-named-cmd
bindkey "\e|"	vi-goto-column
bindkey "\e^?"	backward-kill-word

# Completions.


# Undefined functions.


# Defined functions.


# Limits.

limit datasize        2047MB
limit stacksize       8MB
limit descriptors     64

# Non-array variables.

TERMCAP=''
TERM='xterm'
ARGC="0"
BAUD="9600"
CDPATH=""
COLUMNS="80"
CVSROOT="/home/steffen/pp/CVS"
DIRSTACKSIZE="-1"
DISPLAY=":0"
EDITOR="/public/bin/emacs"
EGID="23"
ERRNO="9"
EXINIT="set sh=/bin/csh sw=4 ai report=2 redraw"
FCEDIT="vi"
FIGNORE=""
FPATH="/home/steffen/friedric/working/zsh-2.6-beta9/Functions"
GID="23"
GUIDEHOME="/public/opt/SUNWguide"
HISTSIZE="100"
HOME="/home/steffen/friedric"
HOST="bartok"
HOSTTYPE="solaris2.4"
HZ="100"
KEYTIMEOUT="40"
LANG=""
LD_LIBRARY_PATH="/public/lib:/usr/lib:/public/opt/SUNWguide/lib:/usr/openwin/lib"
LIBWWW_PERL="/home/steffen/friedric/source/libwww-perl-0.40"
LINENO="495"
LINES="24"
LISTMAX="100"
LITHISTSIZE="5"
LOGCHECK="60"
LOGNAME="friedric"
MACHTYPE="sparc"
MAIL="/var/mail/friedric"
MAILCHECK="3600"
MAILPATH=""
MANPATH="/public/man:/usr/man:/public/opt/dt/man:/usr/openwin/man:/home/steffen/friedric/man"
MOTIFHOME="/public/opt/dt"
NETHACKOPTIONS="restonspace,time"
NNTPSERVER="nntpserver"
NULLCMD="cat"
OBERON=".:/public/languages/oberon/lib"
OLDPWD="/home/steffen/friedric/working/zsh-2.6-beta9/Util"
OPENWINHOME="/usr/openwin"
OPTARG=""
OPTIND="1"
OS="Solaris2"
OSTYPE="solaris2.4"
PATH="/public/programming/sniff+-2.0.1/bin:/home/steffen/friedric/bin:/public/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/sbin:/public/opt/SUNWguide/bin:/usr/openwin/bin:."
PERIOD="0"
PGP_SYSTEM_DIR="/public/network/pgp26/lib"
PLATFORM="sparc-sun-solaris2.3"
POOL="lssun"
POSTEDIT=""
PPID="12195"
PRINTER="lp"
PROMPT="\033[1m\h : \w\033[0m\n\!> "
PROMPT2="> "
PROMPT3="?# "
PROMPT4="+ "
PS1="\033[1m\h : \w\033[0m\n\!> "
PS2="> "
PS3="?# "
PS4="+ "
PSVAR=""
PWD="/home/steffen/friedric/working/zsh-2.6-beta9/Util"
RANDOM="12890"
READNULLCMD="more"
REPORTTIME="-1"
REPOSITORY="/home/steffen/pp/CVS"
RNINIT="-g4 -m -S -hMessage -hSender -hKeyword"
RPROMPT=""
RPS1=""
SAVEDDIR="/home/steffen/friedric/.secure"
SAVEHIST="0"
SECONDS="8"
SHELL="/bin/bash"
SHLVL="3"
SNIFF_DIR="/public/programming/sniff+-2.0.1"
SPROMPT="zsh: correct \`%R\' to \`%r\' [nyae]? "
TIMEFMT="%E real  %U user  %S system  %P %J"
TMOUT="0"
TMPPREFIX="/tmp/zsh"
TTY="/dev/pts/24"
TZ="MET"
UIDPATH="/public/opt/SUNWmfdm/lib/uid"
USERNAME="friedric"
VENDOR="sun"
VISUAL="/public/bin/emacs"
WATCH=""
WATCHFMT="%n has %a %l from %m."
WINDOWID="41943053"
WORDCHARS="*?_-.[]~=/&;!#$%^(){}<>"
WORKMANDB="/public/tools/workman/lib/workmandb"
WORKSPACE="/home/steffen/friedric/working"
WWW_HOME="file:///home/www/local.html"
XAPPLRESDIR="/public/opt/dt/lib/%T/%N%S:/public/app-defaults:/home/steffen/friedric/app-defaults"
XGLHOME="/public/opt/SUNWits/Graphics-sw/xgl"
XILHOME="/public/opt/SUNWits/Graphics-sw/xil"
XMBINDIR="/public/opt/dt/lib/bindings"
ZSH_VERSION="2.6-beta9"
bash_startup_prefer_public="TRUE"
bash_startup_prefer_x11="TRUE"
each="unix"
ftp_proxy="http://www.uni-passau.de:80/"
gopher_proxy="http://www.uni-passau.de:80/"
histchars="!^#"
http_proxy="http://www.uni-passau.de:80/"
no_proxy="uni-passau.de"
reporter_junkiequotes="no"
status="1"
str="SunOS bartok 5.4 Generic_101945-13 sun4m sparc"
wais_proxy="http://www.uni-passau.de:80/"
prompt='test%'

# Array variables.

argv=()
cdpath=()
fignore=()
fpath=(/home/steffen/friedric/working/zsh-2.6-beta9/Functions)
mailpath=()
manpath=(/public/man /usr/man /public/opt/dt/man /usr/openwin/man /home/steffen/friedric/man)
path=(/public/programming/sniff+-2.0.1/bin /home/steffen/friedric/bin /public/bin /usr/bin /usr/ccs/bin /usr/ucb /usr/sbin /public/opt/SUNWguide/bin /usr/openwin/bin .)
psvar=()
signals=(EXIT HUP INT QUIT ILL TRAP IOT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM USR1 USR2 CLD PWR WINCH URG POLL STOP TSTP CONT TTIN TTOU VTALRM PROF XCPU XFSZ WAITING LWP FREEZE THAW RTMIN 37 38 39 40 41 42 RTMAX ZERR DEBUG)
watch=()

# Exported variables.

export TERMCAP
export TERM
export BASH
export CF_HOSTS
export COLUMNS
export CVSROOT
export DISPLAY
export DOOMWADDIR
export EDITOR
export EXINIT
export FPATH
export GUIDEHOME
export HISTSIZE
export HOME
export HOSTTYPE
export HZ
export LD_LIBRARY_PATH
export LIBWWW_PERL
export LINES
export LOGNAME
export MAIL
export MAILCHECK
export MANPATH
export MOTIFHOME
export NETHACKOPTIONS
export NNTPSERVER
export OBERON
export OPENWINHOME
export OS
export OSTYPE
export PATH
export PGP_SYSTEM_DIR
export PLATFORM
export POOL
export PRINTER
export PROMPT
export PS1
export PWD
export REPOSITORY
export RNINIT
export SAVEDDIR
export SHELL
export SHLVL
export SNIFF_DIR
export TERM
export TZ
export UIDPATH
export VISUAL
export WINDOWID
export WORKMANDB
export WORKSPACE
export WWW_HOME
export XAPPLRESDIR
export XGLHOME
export XILHOME
export XMBINDIR
export bash_startup_prefer_public
export bash_startup_prefer_x11
export ftp_proxy
export gopher_proxy
export http_proxy
export no_proxy
export wais_proxy

# Setopt.

setopt bgnice
setopt hashcmds
setopt hashdirs
setopt hashlistall
setopt notify

# END zsh saveset

# END zsh saveset

-- 
###############################################################################
Carsten Friedrich			             friedric@fmi.uni-passau.de

"I have the impression that, to penguins, man is just another penguin -- 
different, less predictable, occasionally violent, but tolerable company
when he sits still and minds his own business." (B. Stonehouse)
###############################################################################


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Bug report
@ 1996-05-10  8:30 Martin Birgmeier
  0 siblings, 0 replies; 27+ messages in thread
From: Martin Birgmeier @ 1996-05-10  8:30 UTC (permalink / raw)
  To: zsh-list

Dear zsh-maintainer & hackers,

I think I've found a problem with 2.6-beta16:

If I have in my startup files

    periodic () {
	fc -AI && echo "(history saved.)" || echo "(could not save history.)"
    }
    PERIOD=1800

then this works fine, *except* that the command - just entered before
the new prompt which triggers periodic() - is *lost* from the history
(and not even reachable with the cursor keys, like `k' in vi-mode).

Is this a feature or a bug? In the latter case, I'd be happy if you could
fix it.

Yours,

Martin

---
Martin Birgmeier

Vienna University of Technology
Department of Communication and Radio Frequency Engineering

Martin.Birgmeier@nt.tuwien.ac.at



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Bug report
@ 1996-05-15  7:48 Martin Birgmeier
  0 siblings, 0 replies; 27+ messages in thread
From: Martin Birgmeier @ 1996-05-15  7:48 UTC (permalink / raw)
  To: zsh-list

Dear zsh-maintainer & hackers,

I think I've found a problem starting with 2.6-beta14:

zsh% - zsh-2.6-beta13
zsh-2.6-beta13% ls =(ls ..) =(ls .)
/tmp/zsha03289  /tmp/zshb03289
zsh-2.6-beta13% exit
zsh% - zsh-2.6.beta14
zsh-2.6-beta14% ls =(ls ..) =(ls .)
/tmp/zshb03330  /tmp/zshb03330
        ^
	| wrong file name

This does not happen if the second command (`ls .') is changed to have
no argument (`ls').

Thanks to all the hackers for all the improvements.

Yours,

Martin

---
Martin Birgmeier

Vienna University of Technology
Department of Communication and Radio Frequency Engineering

Martin.Birgmeier@nt.tuwien.ac.at



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Bug report
@ 1996-05-22  0:07 leitner
  0 siblings, 0 replies; 27+ messages in thread
From: leitner @ 1996-05-22  0:07 UTC (permalink / raw)
  To: zsh-workers


This is for beta18.

Compiling it with mawk instead of gawk produces a Src/signames.h with
escaped "#else" lines like this:

\#else

This leads to gcc complaining that "sigs" is not declared.  This happens
for me under Linux, SunOS and Solaris.

Under Solaris zsh fails to link with -lnsl, so getdomainname and yp_all
are not declared at link time.

Felix

-- 
(------------------------------------------------------------------)
Good programmers write good code; great programmers 'borrow' good code.
"Who is General Failure and why is he reading my hard disk ?"
PGP public key available (mail me with the subject "send key")
PGP public key fingerprint 05 B9 C9 43 3C 96 C5 1E  FD E4 EF 45 E1 A0 09 4D



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Bug Report
@ 2013-08-04 12:16 Yuusuke Yoshimoto
  2013-08-04 17:58 ` Peter Stephenson
  0 siblings, 1 reply; 27+ messages in thread
From: Yuusuke Yoshimoto @ 2013-08-04 12:16 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Hello, I'm Yusuke Yoshimoto, a Japanese university student majoring in
computer science. I found a minor bug in the standard completion function
_java_class and fixed it. The bug is that typed string gets broken if
$JAVA_TOOL_OPTIONS is set and -classpath is designated as jar files. For
example, given that $JAVA_TOOL_OPTIONS is '-Dfile.encoding=UTF-8', I type

java -classpath hamcrest-all-1.3.jar:junit-4.11.jar:

and hit tab, then the input goes to the following:

java -classpath hamcrest-all-1.3.jar:junit-4.11.jar: Picked up
JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

To fix this, change line 18 of zsh-5.0.2/Completion/Unix/Type/_java_class
    c+=( ${${${(M)$(_call_program jar_classes jar -tf
$i)##*.class}%%.class}:gs#/#.#} )
into
    c+=( ${${${(M)$(_call_program jar_classes jar -tf $i
2>/dev/null)##*.class}%%.class}:gs#/#.#} )
Thank you.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug Report
  2013-08-04 12:16 Bug Report Yuusuke Yoshimoto
@ 2013-08-04 17:58 ` Peter Stephenson
  0 siblings, 0 replies; 27+ messages in thread
From: Peter Stephenson @ 2013-08-04 17:58 UTC (permalink / raw)
  To: Yuusuke Yoshimoto; +Cc: zsh-workers

On Sun, 4 Aug 2013 21:16:33 +0900
Yuusuke Yoshimoto <immortal836@gmail.com> wrote:
> Hello, I'm Yusuke Yoshimoto, a Japanese university student majoring in
> computer science. I found a minor bug in the standard completion function
> _java_class and fixed it.

Thanks, I've applied this.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Bug report
@ 2013-12-14 18:44 Patrick Oscity
  2013-12-14 19:08 ` Bart Schaefer
  0 siblings, 1 reply; 27+ messages in thread
From: Patrick Oscity @ 2013-12-14 18:44 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1.1: Type: text/plain, Size: 920 bytes --]

Dear zsh team,

I think I might have found a bug in zsh. Here is my bug report:

Steps to reproduce

	* add a simple RPROMPT to ~/.zshrc, e.g. RPROMPT='X'
	* optionally set PROMPT='$ ' to avoid side-effects of escape
	  sequences like color codes etc.

Actual outcome

	* the right prompt is not right aligned, it is in fact shifted to the
	  left by one character
	* this means that there is one character of space wasted
	* it is also optically disturbing, e.g. when using tmux and the
	  right prompt does not align with tmux's status bar

Expected outcome

	* the right prompt should be right aligned, using the full
	  available width of the terminal

Attached is a diff for zle_refresh.c that fixes the issue for me, although I now have to compile zsh myself. It would however be great to see this corrected in an official release of zsh. Thanks for your consideration!

Best,
Patrick


[-- Attachment #1.2: zle_refresh.c.diff --]
[-- Type: application/octet-stream, Size: 852 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-14 18:44 Bug report Patrick Oscity
@ 2013-12-14 19:08 ` Bart Schaefer
  2013-12-14 20:43   ` Peter Stephenson
                     ` (2 more replies)
  0 siblings, 3 replies; 27+ messages in thread
From: Bart Schaefer @ 2013-12-14 19:08 UTC (permalink / raw)
  To: zsh-workers; +Cc: Patrick Oscity

On Dec 14,  7:44pm, Patrick Oscity wrote:
}
} 	* the right prompt is not right aligned, it is in fact shifted to the
} 	  left by one character

This is intentional, because a particular kind of terminal device that
was very widespread a few years ago had a misfeature wherein printing to
the lower right corner character position scrolls the screen up a line.

Terminal types that have this behavior are not readily identifiable from
terminfo descriptions, and the extra space along the right side was
deemed less annoying than an entire extra line across the bottom (and
corresponding loss of whatever was in the line that scrolled off the
top).

Worse, there was another common terminal where filling the bottom line
of the screen and then writing a trailing newline would NOT scroll the
display, resulting in e.g. blank lines disappearing from output.

Much easier than attempting to detect different combinations of this was
to always be sure that the only thing ever written in the lower right
corner *is* a newline, and only when scrolling is wanted.

Given the number of other prompt-specific setopts we have at this point,
we could potentially add another one to control this, but I think the
default behavior should remain as it is.


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-14 19:08 ` Bart Schaefer
@ 2013-12-14 20:43   ` Peter Stephenson
  2013-12-15  1:15     ` Bart Schaefer
  2013-12-15  1:08   ` Patrick Oscity
  2013-12-15 11:01   ` Patrick Oscity
  2 siblings, 1 reply; 27+ messages in thread
From: Peter Stephenson @ 2013-12-14 20:43 UTC (permalink / raw)
  To: zsh-workers

On Sat, 14 Dec 2013 11:08:30 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Given the number of other prompt-specific setopts we have at this point,
> we could potentially add another one to control this, but I think the
> default behavior should remain as it is.

Or avoid version clutter by adding an optional variable giving the
indent.  The clutter is less because if the variable isn't set it
doesn't appear anywhere except the documentation.

Seems to work: I've sanity checked for negative values and the worst I
can see happening with large numbers is the prompt doesn't appear.

diff --git a/Doc/Zsh/params.yo b/Doc/Zsh/params.yo
index 9d951bb..37c79b2 100644
--- a/Doc/Zsh/params.yo
+++ b/Doc/Zsh/params.yo
@@ -1547,4 +1547,17 @@ See the completion system documentation in
 ifzman(zmanref(zshcompsys))\
 ifnzman(noderef(Completion System)).
 )
+vindex(ZLE_RPROMPT_INDENT)
+item(tt(ZLE_RPROMPT_INDENT))(
+If set, used to give the indentation between the right hand side of
+the right prompt in the line editor as given by tt(RPS1) or tt(RPROMPT)
+and the right hand side of the screen.  If not set, the value 1 is used.
+
+Typically this will be used to set the value to 0 so that the prompt
+appears flush with the right hand side of the screen.  This is not the
+default as many terminals do not handle this correctly, in particular
+when the prompt appears at the extreme bottom right of the screen.
+Recent virtual terminals are more likely to handle this case correctly.
+Some experimentation is necessary.
+)
 enditem()
diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index 17b78ce..2863e39 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -976,7 +976,8 @@ zrefresh(void)
     int tmppos;			/* t - tmpline				     */
     int tmpalloced;		/* flag to free tmpline when finished	     */
     int remetafy;		/* flag that zle line is metafied	     */
-    int txtchange;		/* attributes set after prompts */
+    int txtchange;		/* attributes set after prompts              */
+    int rprompt_off = 1;	/* Offset of rprompt from right of screen    */
     struct rparams rpms;
 #ifdef MULTIBYTE_SUPPORT
     int width;			/* width of wide character		     */
@@ -1573,10 +1574,23 @@ zrefresh(void)
     if (!more_start) {
 	if (trashedzle && opts[TRANSIENTRPROMPT])
 	    put_rpmpt = 0;
-	else
+	else {
 	    put_rpmpt = rprompth == 1 && rpromptbuf[0] &&
-		!strchr(rpromptbuf, '\t') &&
-		(int)ZR_strlen(nbuf[0]) + rpromptw < winw - 1;
+		!strchr(rpromptbuf, '\t');
+	    if (put_rpmpt)
+	    {
+		struct value vbuf;
+		char *name = "ZLE_RPROMPT_INDENT";
+		if (getvalue(&vbuf, &name, 1)) {
+		    rprompt_off = getintvalue(&vbuf);
+		    /* sanity to avoid horrible things happening */
+		    if (rprompt_off < 0)
+			rprompt_off = 0;
+		}
+		put_rpmpt =
+		    (int)ZR_strlen(nbuf[0]) + rpromptw < winw - rprompt_off;
+	    }
+	}
     } else {
 /* insert >.... on first line if there is more text before start of screen */
 	ZR_memset(nbuf[0], zr_sp, lpromptw);
@@ -1631,7 +1645,7 @@ zrefresh(void)
 	if (put_rpmpt && !iln && !oput_rpmpt) {
 	    int attrchange;
 
-	    moveto(0, winw - 1 - rpromptw);
+	    moveto(0, winw - rprompt_off - rpromptw);
 	    zputs(rpromptbuf, shout);
 	    vcs = winw - 1;
 	/* reset character attributes to that set by the main prompt */


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-14 19:08 ` Bart Schaefer
  2013-12-14 20:43   ` Peter Stephenson
@ 2013-12-15  1:08   ` Patrick Oscity
  2013-12-15 11:01   ` Patrick Oscity
  2 siblings, 0 replies; 27+ messages in thread
From: Patrick Oscity @ 2013-12-15  1:08 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

I have seen the much improved patch by Peter Stephenson and find it to be the perfect solution. Thank you guys for the quick reaction and your detailed explanations. You rock!

> On 14.12.2013, at 20:08, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
> On Dec 14,  7:44pm, Patrick Oscity wrote:
> }
> }    * the right prompt is not right aligned, it is in fact shifted to the
> }      left by one character
> 
> This is intentional, because a particular kind of terminal device that
> was very widespread a few years ago had a misfeature wherein printing to
> the lower right corner character position scrolls the screen up a line.
> 
> Terminal types that have this behavior are not readily identifiable from
> terminfo descriptions, and the extra space along the right side was
> deemed less annoying than an entire extra line across the bottom (and
> corresponding loss of whatever was in the line that scrolled off the
> top).
> 
> Worse, there was another common terminal where filling the bottom line
> of the screen and then writing a trailing newline would NOT scroll the
> display, resulting in e.g. blank lines disappearing from output.
> 
> Much easier than attempting to detect different combinations of this was
> to always be sure that the only thing ever written in the lower right
> corner *is* a newline, and only when scrolling is wanted.
> 
> Given the number of other prompt-specific setopts we have at this point,
> we could potentially add another one to control this, but I think the
> default behavior should remain as it is.


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-14 20:43   ` Peter Stephenson
@ 2013-12-15  1:15     ` Bart Schaefer
  2013-12-15 13:30       ` Peter Stephenson
  0 siblings, 1 reply; 27+ messages in thread
From: Bart Schaefer @ 2013-12-15  1:15 UTC (permalink / raw)
  To: zsh-workers

On Dec 14,  8:43pm, Peter Stephenson wrote:
}
} Seems to work: I've sanity checked for negative values and the worst I
} can see happening with large numbers is the prompt doesn't appear.

Something isn't quit right here.  In the copy-paste below, pay attention
to what happens to the left prompt; the placement of the right prompt is
correct, though vagaries of email may have muddled the line width or
wrapping:

torch% setopt promptsubst
torch% PS1=987654321_ RPS1='$ZLE_RPROMPT_INDENT'
987654321_

Cursor is immediately to the left of the "_" as expected.

987654321_ZLE_RPROMPT_INDENT=1
987654321_ZLE_RPROMPT_INDENT=2                                                1
987654321ZLE_RPROMPT_INDENT=3                                                2
98765432ZLE_RPROMPT_INDENT=4                                                3
9876543ZLE_RPROMPT_INDENT=5                                                4
987654ZLE_RPROMPT_INDENT=6                                                5
98765ZLE_RPROMPT_INDENT=7                                                6
987654321_                                                              7

Cursor is presently on the "5" digit in PS1.

9876ZLE_RPROMPT_INDENT=0                                                7
987654321_ echo oops                                                           0
oops

Cursor is now one full space to the right of the "_".  So whatever moves
the cursor "back" to PS1 after drawing RPS1 still calculates as if the
right-indent is always 1.  If I set ZLE_RPROMPT_INDENT to a value larger
than the number of characters in $PS1 but smaller than $COLUMNS, the
cursor actually moves up to the line above, which I can't really show
with cut-and-paste.

It appears that if you want to make this offset different from 1, you
are going to have to change countprompt() to include the offset in the
width of the prompt rather than just fiddle with math in the output code.


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-14 19:08 ` Bart Schaefer
  2013-12-14 20:43   ` Peter Stephenson
  2013-12-15  1:08   ` Patrick Oscity
@ 2013-12-15 11:01   ` Patrick Oscity
  2 siblings, 0 replies; 27+ messages in thread
From: Patrick Oscity @ 2013-12-15 11:01 UTC (permalink / raw)
  To: zsh-workers; +Cc: Bart Schaefer

[-- Attachment #1: Type: text/plain, Size: 4651 bytes --]

On 14.12.2013, at 17:15 -0800, Bart Schaefer <schaefer@brasslantern.com> wrote:

> It appears that if you want to make this offset different from 1, you
> are going to have to change countprompt() to include the offset in the
> width of the prompt rather than just fiddle with math in the output code.

Maybe I was too enthusiastic ;-) I continued experimenting with my original patch and hard coded an offset of 5 instead of removing it, just to see what happens:

diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index 17b78ce..f136178 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -1576,7 +1576,7 @@ zrefresh(void)
 	else
 	    put_rpmpt = rprompth == 1 && rpromptbuf[0] &&
 		!strchr(rpromptbuf, '\t') &&
-		(int)ZR_strlen(nbuf[0]) + rpromptw < winw - 1;
+		(int)ZR_strlen(nbuf[0]) + rpromptw < winw - 5;
     } else {
 /* insert >.... on first line if there is more text before start of screen */
 	ZR_memset(nbuf[0], zr_sp, lpromptw);
@@ -1631,9 +1631,9 @@ zrefresh(void)
 	if (put_rpmpt && !iln && !oput_rpmpt) {
 	    int attrchange;
 
-	    moveto(0, winw - 1 - rpromptw);
+	    moveto(0, winw - 5 - rpromptw);
 	    zputs(rpromptbuf, shout);
-	    vcs = winw - 1;
+	    vcs = winw - 5;
 	/* reset character attributes to that set by the main prompt */
 	    txtchange = pmpt_attr;
 	    /*

This did not result in the problem you described. It worked just as expected, not misplacing the cursor at all, so I figured that the problem had to be introduced by Peter's patch. I came up with the following fix, which also sets the vcs variable according to rprompt_off, instead of subtracting the fixed value 1 (last change in the diff). This fixed the issue for me with arbitrary values for ZLE_RPROMPT_INDENT.

diff --git a/Doc/Zsh/params.yo b/Doc/Zsh/params.yo
index b7b7750..2039fa1 100644
--- a/Doc/Zsh/params.yo
+++ b/Doc/Zsh/params.yo
@@ -1531,4 +1531,17 @@ See the completion system documentation in
 ifzman(zmanref(zshcompsys))\
 ifnzman(noderef(Completion System)).
 )
+vindex(ZLE_RPROMPT_INDENT)
+item(tt(ZLE_RPROMPT_INDENT))(
+If set, used to give the indentation between the right hand side of
+the right prompt in the line editor as given by tt(RPS1) or tt(RPROMPT)
+and the right hand side of the screen.  If not set, the value 1 is used.
+
+Typically this will be used to set the value to 0 so that the prompt
+appears flush with the right hand side of the screen.  This is not the
+default as many terminals do not handle this correctly, in particular
+when the prompt appears at the extreme bottom right of the screen.
+Recent virtual terminals are more likely to handle this case correctly.
+Some experimentation is necessary.
+)
 enditem()
diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index 17b78ce..83cbd0b 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -976,7 +976,8 @@ zrefresh(void)
     int tmppos;			/* t - tmpline				     */
     int tmpalloced;		/* flag to free tmpline when finished	     */
     int remetafy;		/* flag that zle line is metafied	     */
-    int txtchange;		/* attributes set after prompts */
+    int txtchange;		/* attributes set after prompts              */
+    int rprompt_off = 1;	/* Offset of rprompt from right of screen    */
     struct rparams rpms;
 #ifdef MULTIBYTE_SUPPORT
     int width;			/* width of wide character		     */
@@ -1573,10 +1574,23 @@ zrefresh(void)
     if (!more_start) {
 	if (trashedzle && opts[TRANSIENTRPROMPT])
 	    put_rpmpt = 0;
-	else
+	else {
 	    put_rpmpt = rprompth == 1 && rpromptbuf[0] &&
-		!strchr(rpromptbuf, '\t') &&
-		(int)ZR_strlen(nbuf[0]) + rpromptw < winw - 1;
+		!strchr(rpromptbuf, '\t');
+	    if (put_rpmpt)
+	    {
+		struct value vbuf;
+		char *name = "ZLE_RPROMPT_INDENT";
+		if (getvalue(&vbuf, &name, 1)) {
+		    rprompt_off = getintvalue(&vbuf);
+		    /* sanity to avoid horrible things happening */
+		    if (rprompt_off < 0)
+			rprompt_off = 0;
+		}
+		put_rpmpt =
+		    (int)ZR_strlen(nbuf[0]) + rpromptw < winw - rprompt_off;
+	    }
+	}
     } else {
 /* insert >.... on first line if there is more text before start of screen */
 	ZR_memset(nbuf[0], zr_sp, lpromptw);
@@ -1631,9 +1645,9 @@ zrefresh(void)
 	if (put_rpmpt && !iln && !oput_rpmpt) {
 	    int attrchange;
 
-	    moveto(0, winw - 1 - rpromptw);
+	    moveto(0, winw - rprompt_off - rpromptw);
 	    zputs(rpromptbuf, shout);
-	    vcs = winw - 1;
+	    vcs = winw - rprompt_off;
 	/* reset character attributes to that set by the main prompt */
 	    txtchange = pmpt_attr;
 	    /*

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-15  1:15     ` Bart Schaefer
@ 2013-12-15 13:30       ` Peter Stephenson
  2013-12-15 17:10         ` Bart Schaefer
  0 siblings, 1 reply; 27+ messages in thread
From: Peter Stephenson @ 2013-12-15 13:30 UTC (permalink / raw)
  To: zsh-workers

On Sat, 14 Dec 2013 17:15:13 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Cursor is now one full space to the right of the "_".  So whatever moves
> the cursor "back" to PS1 after drawing RPS1 still calculates as if the
> right-indent is always 1.  If I set ZLE_RPROMPT_INDENT to a value larger
> than the number of characters in $PS1 but smaller than $COLUMNS, the
> cursor actually moves up to the line above, which I can't really show
> with cut-and-paste.
> 
> It appears that if you want to make this offset different from 1, you
> are going to have to change countprompt() to include the offset in the
> width of the prompt rather than just fiddle with math in the output code.

I guess this is Patrick's fix to vcs?

pws


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-15 13:30       ` Peter Stephenson
@ 2013-12-15 17:10         ` Bart Schaefer
  0 siblings, 0 replies; 27+ messages in thread
From: Bart Schaefer @ 2013-12-15 17:10 UTC (permalink / raw)
  To: zsh-workers

On Dec 15,  1:30pm, Peter Stephenson wrote:
}
} > It appears that if you want to make this offset different from 1, you
} > are going to have to change countprompt() to include the offset in the
} > width of the prompt rather than just fiddle with math in the output code.
} 
} I guess this is Patrick's fix to vcs?

Yeah, I should have compared your patch more closely to Patrick's original
before concluding the issue was in countprompt().

By the way, fiddling with this I discovered that I have one of the
terminals that scrolls up when anything is written to the bottom right
corner.  Vanilla "xterm" does this.


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
@ 2013-12-17 10:59 Patrick Oscity
  2013-12-17 11:27 ` Peter Stephenson
  2013-12-17 17:11 ` Bart Schaefer
  0 siblings, 2 replies; 27+ messages in thread
From: Patrick Oscity @ 2013-12-17 10:59 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

On Dec 15, 18:10,  Bart Schaefer wrote:
> By the way, fiddling with this I discovered that I have one of the
> terminals that scrolls up when anything is written to the bottom right
> corner.  Vanilla "xterm" does this.

In fact, I discovered the same behavior in my terminal (using iTerm2 on
OS X) which somehow defeats the purpose. Another odd behavior I noticed
is that when I set ZLE_RPROMPT_INDENT=0, the first character of any
completion disappears. For example:


$ PS1='$ '
$ RPS1='TEST'
$ ZLE_RPROMPT_INDENT=0                                                     TEST
$ ls                                                                        TEST
 SCOLORS   ls         lsappinfo  lsm        lsvfs
LS_COLORS  lsa        lsbom      lsof


On the last line I entered ls<TAB>. Notice how the first character in the
first line of the suggested completions disappears. As I said, I also
experience the scrolling up by one line.

Since other shells like e.g. FISH handle this correctly in the very same
terminal, maybe there's actually something else broken here? Consider this
session in FISH, where I also typed ls<TAB> on the last input line:


$ function fish_prompt
      echo '$ '
  end
$ function fish_right_prompt                                                TEST
      echo 'TEST'
  end
$ ls                                                                        TEST
ls
lsappinfo  (Control and query CoreApplicationServices about the app state on t…)
lsbom                                              (List contents of a bom file)
lsm                                               (Latent Semantic Mapping tool)
lsof                                                           (List open files)
lsvfs                                          (List known virtual file systems)


It works. If FISH can do it, I believe we can also do it in ZSH, or am I
wrong with this assumption?

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-17 10:59 Patrick Oscity
@ 2013-12-17 11:27 ` Peter Stephenson
  2013-12-17 17:11 ` Bart Schaefer
  1 sibling, 0 replies; 27+ messages in thread
From: Peter Stephenson @ 2013-12-17 11:27 UTC (permalink / raw)
  To: zsh-workers

On Tue, 17 Dec 2013 11:59:32 +0100
Patrick Oscity <patrick.oscity@gmail.com> wrote:
> On Dec 15, 18:10,  Bart Schaefer wrote:
> > By the way, fiddling with this I discovered that I have one of the
> > terminals that scrolls up when anything is written to the bottom right
> > corner.  Vanilla "xterm" does this.
> 
> In fact, I discovered the same behavior in my terminal (using iTerm2 on
> OS X) which somehow defeats the purpose. Another odd behavior I noticed
> is that when I set ZLE_RPROMPT_INDENT=0, the first character of any
> completion disappears.
> 
> Since other shells like e.g. FISH handle this correctly in the very same
> terminal, maybe there's actually something else broken here?

It's not so much a case of being broken as of working round the foibles
of various terminals.  It might well be possible to update the chunk of
code around line 1645 of zle_refresh.c marked "output the right-prompt
if appropriate" so that it's less likely to cause terminals to wrap, but
that will need some research.

pws


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-17 10:59 Patrick Oscity
  2013-12-17 11:27 ` Peter Stephenson
@ 2013-12-17 17:11 ` Bart Schaefer
  2013-12-17 17:56   ` Bart Schaefer
  1 sibling, 1 reply; 27+ messages in thread
From: Bart Schaefer @ 2013-12-17 17:11 UTC (permalink / raw)
  To: zsh-workers

On Dec 17, 11:59am, Patrick Oscity wrote:
}
} Since other shells like e.g. FISH handle this correctly in the very same
} terminal, maybe there's actually something else broken here?

I suspect that FISH is e.g. using the curses library to manage the entire
screen.  ZLE does not attempt to do this, and we long ago decided that we
have better things to do than to re-invent all the details of full-screen
terminal management when the real purpose of having the line editor is "get
work done more efficiently" not "look pretty".

If someone wants to take on the game of whack-a-terminal that this is very
likely to become, we'll welcome the help ...

} Another odd behavior I noticed
} is that when I set ZLE_RPROMPT_INDENT=0, the first character of any
} completion disappears.

It's quite possible (even very likely) that the completion code makes
assumptions about the prompt code.  If you capture the output with e.g.
"script", you can see that the character actually is printed (in fact,
the whole listing is printed) but then covered up when the completion
code attempts to return the cursor to the line the prompt is on.

This may in fact be another spot in the prompt code that needs to know
that there is no right-indent.  That might actually fix the issue with
scrolling up one line, too, on some terminals.


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2013-12-17 17:11 ` Bart Schaefer
@ 2013-12-17 17:56   ` Bart Schaefer
  0 siblings, 0 replies; 27+ messages in thread
From: Bart Schaefer @ 2013-12-17 17:56 UTC (permalink / raw)
  To: zsh-workers

On Dec 17,  9:11am, Bart Schaefer wrote:
}
} This may in fact be another spot in the prompt code that needs to know
} that there is no right-indent.  That might actually fix the issue with
} scrolling up one line, too, on some terminals.

OK, I have tracked this down (and rebuilt my memory) ...

Remember what I said about how some terminals scroll when you write to
the last character, and other don't, and it's not possible to tell
which is which?  This applies to the end of any line, not just to the
lower right corner.  The corner just happens to be the only case where
scrolling actually pushes something off the top.

Src/Zle/zle_refresh.c:moveto() knows that the last character that was
output for the right-prompt was in the rightmost column.  What it does
not know is whether that left the cursor AT the rightmost column, or
whether it wrapped around to the next line.

In order to know what to do next, it has to know where the cursor is.
So it outputs space-backspace, which is guaranteed to make ANY terminal
behave like one of the terminals where the cursor has already wrapped
around to the next line.  Unfortunately this steps on the first character
of whatever was below the prompt.

Now it knows where the cursor is, so it can move up one line to place
the cursor properly within the line containing the prompt.

So to "fix" this (other than by going back to a minimum right-indent of
one), we have to re-implement moveto() in some way that allows it to
"know" where the cursor is after writing to the rightmost column.  There
may not be a way to do this without causing a lot of flickery cursor
motion.


^ permalink raw reply	[flat|nested] 27+ messages in thread

* bug report
@ 2014-06-05 17:05 robin terrep-drangiug
  2014-06-05 20:48 ` Bart Schaefer
  0 siblings, 1 reply; 27+ messages in thread
From: robin terrep-drangiug @ 2014-06-05 17:05 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 63 bytes --]

Hello,

This command make the termcaps down

export COLUMNS=10

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: bug report
  2014-06-05 17:05 bug report robin terrep-drangiug
@ 2014-06-05 20:48 ` Bart Schaefer
  0 siblings, 0 replies; 27+ messages in thread
From: Bart Schaefer @ 2014-06-05 20:48 UTC (permalink / raw)
  To: zsh-workers; +Cc: robin.guignardperret

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Jun 5, 2014 10:13 AM, "robin terrep-drangiug" <
robin.guignardperret@gmail.com> wrote:
>
> Hello,
>
> This command make the termcaps down
>
> export COLUMNS=10

I' m not sure this is what you are referring to, but:  On terminals where
terminfo advertises auto-margin capability, the line editor (ZLE) assumes
that printing a character in the rightmost column causes an implicit line
feed.  If you set COLUMNS to less than the actual terminal width, the line
won't wrap where ZLE thinks it did and the display may be strange as a
result.

For what reason do you need to set a narrower value of COLUMNS?

^ permalink raw reply	[flat|nested] 27+ messages in thread

* bug report
@ 2014-09-17  0:26 Mica Chimera
  2014-09-17  1:08 ` Frank Terbeck
  0 siblings, 1 reply; 27+ messages in thread
From: Mica Chimera @ 2014-09-17  0:26 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

Strange behavior when using vi editor mode.
It goes something like this, with "|" being cursor:

%: bindkey -v
%: mv /some/file /some/other/file
commands: <ESC>Bi
%: mv /some/file |/some/other/file

At this point I can type in new stuff just fine, and <BS> up to the point
where I reentered insert mode, but anything earlier than that beeps and
doesn't delete. Stranger still is when I <DEL>

%: mv /some/file /SOME/OTH|er/file

Changes it to caps.

I'm using version 5.0.6 and have reproduced the error on multiple x86_64
machines with default configuration.

Since no one else seems to be reporting this bug and it's so severe I
figure it's likely there's something I just don't get. If that's the case
I'm sorry for all the trouble, but can you let me know what's happening?

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: bug report
  2014-09-17  0:26 Mica Chimera
@ 2014-09-17  1:08 ` Frank Terbeck
  0 siblings, 0 replies; 27+ messages in thread
From: Frank Terbeck @ 2014-09-17  1:08 UTC (permalink / raw)
  To: Mica Chimera; +Cc: zsh-workers

Hello Mica,

Mica Chimera wrote:
> Strange behavior when using vi editor mode.
> It goes something like this, with "|" being cursor:
>
> %: bindkey -v
> %: mv /some/file /some/other/file
> commands: <ESC>Bi
> %: mv /some/file |/some/other/file
>
> At this point I can type in new stuff just fine, and <BS> up to the point
> where I reentered insert mode, but anything earlier than that beeps and
> doesn't delete.

This is the behaviour of the original vi, which vi-mode is loosely based
on. You can always rebind to ‘backward-delete-char’ if you prefer.

> Stranger still is when I <DEL>
>
> %: mv /some/file /SOME/OTH|er/file
>
> Changes it to caps.

This on the other hand is just a lack of understanding of how terminals
work. I'll try to give a brief explanation of what's going on: Special
keys, like DELETE or INSERT or the PageUp key, are encoded by terminals
as so called escape sequences. (All of this stems from the fact that
"terminals" are actually programs that emulate ancient hardware that
exchanged characters with a host via serial links. Colours, for example,
are encoded by escape sequences as well.) In my terminal, pressing the
DELETE key sends four bytes, namely:

  ESC [ 3 ~

If that sequence is not bound to a widget (which it is not by default),
ZLE (zsh's line editor) executes the actions associated with the
individual characters. ESC would change back to normal mode; [ would do
nothing by default; and "3 ~" would toggle the capitalisation of the
next three characters.

That would be the case with you, as well. Only that there appears to be
a larger integer in front of the tilde.

Like I said "If that sequence is not bound to a widget". You can bind it
to a widget, like this:

  bindkey '^[[3~' delete-char

But the problem with that is, that different terminals use different
sequences for this kind of stuff.


Debian's new zsh packages include a few lines of configuration code that
bind a few common special keys to widgets automatically by looking at
the terminal's terminfo database entry¹. If you're interested, the code
resides in:

  http://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/zshrc

And the lines you would be looking for are the ones from line 18 up to
and including line 91.

You could fix your issue with the BackSpace key in one go by changing
line 54 of that file from

  bind2maps       viins       -- BackSpace   vi-backward-delete-char

to:

  bind2maps       viins       -- BackSpace   backward-delete-char

(‘bind2maps’ is a simple function defined in that file, that wraps
around ‘bindkey’.)

> I'm using version 5.0.6 and have reproduced the error on multiple x86_64
> machines with default configuration.
>
> Since no one else seems to be reporting this bug and it's so severe I
> figure it's likely there's something I just don't get. If that's the case
> I'm sorry for all the trouble, but can you let me know what's happening?

No worries. This is quite the common source of confusion.


Regards, Frank

¹ There are other attempts of handling special keys, like zkbd, but I'm
  pretty convinced, that the approach used in that setup is quite robust
  for most terminals and the most common of keys. Anything beyond is
  usually very much more terminal-specific.

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Bug report
@ 2014-12-26 16:53 mvxxc
  2014-12-27  2:35 ` Bart Schaefer
  0 siblings, 1 reply; 27+ messages in thread
From: mvxxc @ 2014-12-26 16:53 UTC (permalink / raw)
  To: zsh-workers

If the following script is run in an empty directory, zsh executes the defined
function only once.

  #!/usr/bin/zsh
  
  set -e
  setopt NULL_GLOB
  
  func () {for i in _*; do echo $i; done; echo _;} 
  
  func
  if false; then
    :
  else
    func
  fi  

After adding one line, the function is executed twice.

  [...]
  else
    :
    func
  fi

"set -e" and "NULL_GLOB" seem to affect both function calls in a different way.
This could be a bug, as the answer to my question on Stack Overflow suggests.

  https://stackoverflow.com/questions/27648773.

MVXXC


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2014-12-26 16:53 Bug report mvxxc
@ 2014-12-27  2:35 ` Bart Schaefer
  0 siblings, 0 replies; 27+ messages in thread
From: Bart Schaefer @ 2014-12-27  2:35 UTC (permalink / raw)
  To: mvxxc, zsh-workers

On Dec 26,  5:53pm, mvxxc@gmx.de wrote:
} Subject: Bug report
}
} If the following script is run in an empty directory, zsh executes the
} defined function only once.

Changing this line:

}   set -e

To "set -exv" shows that func is in fact called twice but exits without
doing anything on the second call.

I therefore suspect one of workers/32568 or workers/32569.

This is very tricky because we have to propagate the value of $? from
before the "for" keyword (including before the start of the function)
into the "do" body, but must *not* *use* the value of $? for deciding
whether to exit-on-error, because the nonzero value came from an "if"
test.  There is a "noerrexit" flag that is supposed to cover this case,
but it's not set when the very first "sublist" in a function body is
a for-loop (there are likely to be other similar cases).


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Bug report
@ 2019-09-19 11:16 Vladimir Deyter
  2019-09-19 14:53 ` Mikael Magnusson
  0 siblings, 1 reply; 27+ messages in thread
From: Vladimir Deyter @ 2019-09-19 11:16 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 86 bytes --]

ZShell doesn't show commands list for snap.
Could you fix it, please?
Regards Deyter.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2019-09-19 11:16 Vladimir Deyter
@ 2019-09-19 14:53 ` Mikael Magnusson
  2019-09-19 15:57   ` Daniel Shahaf
  0 siblings, 1 reply; 27+ messages in thread
From: Mikael Magnusson @ 2019-09-19 14:53 UTC (permalink / raw)
  To: Vladimir Deyter; +Cc: zsh-workers

On 9/19/19, Vladimir Deyter <deyter.vladimir@gmail.com> wrote:
> ZShell doesn't show commands list for snap.
> Could you fix it, please?

You can't possibly expect anyone to do anything with the level of
detail (none) you have provided.

-- 
Mikael Magnusson

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Bug report
  2019-09-19 14:53 ` Mikael Magnusson
@ 2019-09-19 15:57   ` Daniel Shahaf
  0 siblings, 0 replies; 27+ messages in thread
From: Daniel Shahaf @ 2019-09-19 15:57 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: zsh-workers, Vladimir Deyter

Mikael Magnusson wrote on Thu, 19 Sep 2019 14:53 +00:00:
> On 9/19/19, Vladimir Deyter <deyter.vladimir@gmail.com> wrote:
> > ZShell doesn't show commands list for snap.
> > Could you fix it, please?
> 
> You can't possibly expect anyone to do anything with the level of
> detail (none) you have provided.

I think he's asking for someone to write a completion function for him.

(Has anyone got a link that explains the phrase "Patches welcome" less tersely?)

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, back to index

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1995-08-24 11:23 Bug Report Carsten Friedrich
1996-05-10  8:30 Bug report Martin Birgmeier
1996-05-15  7:48 Martin Birgmeier
1996-05-22  0:07 leitner
2013-08-04 12:16 Bug Report Yuusuke Yoshimoto
2013-08-04 17:58 ` Peter Stephenson
2013-12-14 18:44 Bug report Patrick Oscity
2013-12-14 19:08 ` Bart Schaefer
2013-12-14 20:43   ` Peter Stephenson
2013-12-15  1:15     ` Bart Schaefer
2013-12-15 13:30       ` Peter Stephenson
2013-12-15 17:10         ` Bart Schaefer
2013-12-15  1:08   ` Patrick Oscity
2013-12-15 11:01   ` Patrick Oscity
2013-12-17 10:59 Patrick Oscity
2013-12-17 11:27 ` Peter Stephenson
2013-12-17 17:11 ` Bart Schaefer
2013-12-17 17:56   ` Bart Schaefer
2014-06-05 17:05 bug report robin terrep-drangiug
2014-06-05 20:48 ` Bart Schaefer
2014-09-17  0:26 Mica Chimera
2014-09-17  1:08 ` Frank Terbeck
2014-12-26 16:53 Bug report mvxxc
2014-12-27  2:35 ` Bart Schaefer
2019-09-19 11:16 Vladimir Deyter
2019-09-19 14:53 ` Mikael Magnusson
2019-09-19 15:57   ` Daniel Shahaf

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/ public-inbox