From: Ray Andrews <rayandrews@eastlink.ca>
To: Zsh Users <zsh-users@zsh.org>
Subject: two mysteries
Date: Wed, 04 Nov 2015 10:12:05 -0800 [thread overview]
Message-ID: <563A4A75.1020009@eastlink.ca> (raw)
Deep in my butcherings of Sebastian's code:
START_IDX=1+((idx-1)/page_hight)*page_hight
... it will work fine for days, then one Tuesday 'START_IDX' starts
throwing 'divide by zero' errors, and it turns out that it's been
transmuted from an integer to a string. There aughta be a law:
typeset -I number ... 'number' is an integer for ever and ever.
START_IDX=$(( 1+((idx-1)/page_hight)*page_hight ))
... fixes it, but I recall weeks back that that fix introduced other
bugs, tho I'd not stake anything on that, and it works on Wednesdays
anyway. But most days the variable remains an integer regardless of the
fix. God knows why a 'divide by zero' error would be thrown when zsh
considers the thing to be a string anyway. If it really must convert my
integers to strings, then tell me "You are trying to do arithmetic on a
string, dolt".
2nd mystery:
I have this little helper, you put it into code:
...
echo this
foo='that'
varis foo line123 5
code
code
...
Outputs:
line123 5: evaluated: "foo" is: that
... to /dev/pts/5. It pointedly takes the variable name without any '$'
so that the name of the variable can be reported along with it's
'evaled' value. Very helpful. The strange thing is that, now that I'm
playing with associative arrays, yesterday I had to single quote:
varis 'array[value]' line456 5
... but only with arrays--scalars were fine--or I got a message to the
effect that 'no values were matched'. AND ... now that I get around to
typing this the next day, the problem is gone, so I can't report the
message :-(
As the vaguest of probably unanswerable questions, what might possibly
have been different yesterday? Some option being changed in the
background perhaps? I've tried keeping an eye on that, but nothing. As
with mystery #1 above, this must be explicable but I don't know where to
begin looking.
In the same vein, if one of these 'zcurses' functions crashes, what the
docs say about the terminal being in a unstable state sure is true.
Things look fine, but, for example, history recall goes screwy. I've
learned to kill and restart the terminal--just restarting zsh isn't good
enough. It would be helpful if zcurses could report: "Please restart
this xterm" or something. Anyway, these strange, ghostly haunted house
things sure are bothersome. There's a skeleton buried somewhere, if I
could find it.
next reply other threads:[~2015-11-04 18:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-04 18:12 Ray Andrews [this message]
2015-11-04 20:35 ` Bart Schaefer
2015-11-05 0:38 ` Ray Andrews
2015-11-06 18:44 ` Bart Schaefer
2015-11-06 22:22 ` Ray Andrews
2015-11-07 9:55 ` Bart Schaefer
2015-11-07 15:19 ` Ray Andrews
2015-11-07 17:19 ` Bart Schaefer
2015-11-07 18:37 ` Ray Andrews
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563A4A75.1020009@eastlink.ca \
--to=rayandrews@eastlink.ca \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).