Shallow Thoughts : tags : mysteries
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Thu, 31 Aug 2023
This week's group hike was to San Antonio Hot Springs, in the Jemez
above La Cueva. It was nice and cool up there, especially since the
trail is mostly shady, winding through ponderosa forest with views of
San Antonio Creek below and towering rock walls above.
Read more ...
Tags: hiking, sign, mysteries
[
12:06 Aug 31, 2023
More hikes |
permalink to this entry |
]
Thu, 28 Aug 2014
For the last several months, I repeatedly find myself in a mode where
my terminal isn't working quite right. In particular, Ctrl-C doesn't
work to interrupt a running program. It's always in a terminal where
I've been doing web work. The site I'm working on sadly has only ftp
access, so I've been using ncftp to upload files to the site, and git
and meld to do local version control on the copy of the site I keep on
my local machine. I was pretty sure the problem was coming from either
git, meld, or ncftp, but I couldn't reproduce it.
Running reset
fixed the problem. But since I didn't know
what program was causing the problem, I didn't know when I needed to
type reset
.
The first step was to find out which of the three programs was at fault.
Most of the time when this happened, I wouldn't notice until hours
later, the next time I needed to stop a program with Ctrl-C.
I speculated that there was probably some way to make zsh run a check
after every command ... if I could just figure out what to check.
Terminal modes and stty -a
It seemed like my terminal was getting put into raw mode.
In programming lingo, a terminal is in raw mode when characters
from it are processed one at a time, and special characters like
Ctrl-C, which would normally interrupt whatever program is running,
are just passed like any other character.
You can list your terminal modes with stty -a:
$ stty -a
speed 38400 baud; rows 32; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff
-iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
But that's a lot of information. Unfortunately there's no single flag
for raw mode; it's a collection of a lot of flags.
I checked the interrupt character:
yep, intr = ^C
, just like it should be. So what was
the problem?
I saved the output with stty -a >/tmp/stty.bad
, then
I started up a new xterm and made a copy of what it should
look like with stty -a >/tmp/stty.good
. Then I looked
for differences: meld /tmp/stty.good /tmp/stty.bad
.
I saw these flags differing in the bad one: ignbrk ignpar -iexten -ixon,
while the good one had -ignbrk -ignpar iexten ixon. So I should be
able to run:
$ stty -ignbrk -ignpar iexten ixon
and that would fix the problem. But it didn't. Ctrl-C still didn't work.
Setting a trap, with precmd
However, knowing some things that differed did give me something to
test for in the shell, so I could test after every command and find
out exactly when this happened. In zsh, you do that by defining a
precmd function, so here's what I did:
precmd()
{
stty -a | fgrep -- -ignbrk > /dev/null
if [ $? -ne 0 ]; then
echo
echo "STTY SETTINGS HAVE CHANGED \!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!"
echo
fi
}
Pardon all the exclams. I wanted to make sure I saw the notice when it happened.
And this fairly quickly found the problem: it happened when I suspended
ncftp with Ctrl-Z.
stty sane and isig
Okay, now I knew the culprit, and that if I switched to a different ftp
client the problem would probably go away. But I still wanted to know
why my stty command didn't work, and what the actual terminal
difference was.
Somewhere in my web searching I'd stumbled upon some pages suggesting
stty sane
as an alternative to reset
.
I tried it, and it worked.
According to man stty
, stty sane is equivalent to
$ stty cread -ignbrk brkint -inlcr -igncr icrnl -iutf8 -ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
Eek! But actually that's helpful. All I had to do was get a bad
terminal (easy now that I knew ncftp was the culprit), then try:
$ stty cread
$ stty -ignbrk
$ stty brkint
... and so on, trying Ctrl-C each time to see if things were back to normal.
Or I could speed up the process by grouping them:
$ stty cread -ignbrk brkint
$ stty -inlcr -igncr icrnl -iutf8 -ixoff
... and so forth. Which is what I did. And that quickly narrowed it
down to
isig. I ran reset, then ncftp again to get the terminal
in "bad" mode, and tried:
$ stty isig
and sure enough, that was the difference.
I'm still not sure why meld didn't show me the isig difference.
But if nothing else, I learned a bit about debugging stty settings,
and about stty sane
, which is a much nicer way of
resetting the terminal than reset
since it doesn't
clear the screen.
Tags: linux, cmdline, debugging, mysteries
[
15:41 Aug 28, 2014
More linux |
permalink to this entry |
]
Mon, 01 Aug 2011
We went exploring around the upper Skyline-to-the-Sea trail yesterday.
The mysterious chlorine smell was very evident, for the first time
this year. Usually I've first noticed it in early July or even June,
but although we had some very hot weather in early June this year,
it wasn't enough to bring out the smell. I've made no progress in
identifying it, but I continue to
suspect
tanoaks as the chlorine culprit.
It was a good day for reptiles, too. We surprised the biggest
ring-necked snake I've ever seen -- well over two feet long and
thicker than my thumb (which admittedly isn't saying much).
It hastened off the trail before I could get the camera out.
Then back at home, I found a small young alligator lizard splayed
out in the shade on the sidewalk of our back yard. We've occasionally
had alligator lizards here before, but never such a small one.
Again, no picture; instead we just watched as it made its way across
the yard to hide under the rosemary. I hope it stays around.
Tags: chlorine, nature, mysteries
[
11:31 Aug 01, 2011
More nature |
permalink to this entry |
]
Wed, 06 Apr 2011
I like to travel in out-of-the-way places.
On desert back roads, one often encounters mysteries of one
sort or another. And the mystery under consideration today is a prosaic
one: road signs.
Dirt roads, especially in the desert, seldom have much in the way of
signage. You're lucky if you get an occasional signpost with a BLM
route number (which invariably isn't marked on any of your maps anyway).
And yet, quite often out on deserted dirt roads, you'll see odd, slanted
signs painted yellow with black stripes. No numbers or letters, and not
every road has them. What do they mean?
They don't always seem to slant the same way. I've wondered if they
might point to underground cables or other hazards -- but there are
usually much clearer signs for such things. Sometimes they run along
a fence ... but not always.
I've seen them a lot in California, but I'm pretty sure I've seen them in
Nevada and maybe in Arizona. I don't think I've seen any in New Mexico.
Sometimes they come in pairs -- and sometimes the pairs are at
right angles to one another, or
at some other
angle entirely.
Sometimes they seem to be aimed primarily at traffic coming from
one direction; sometimes they're posted on opposite sides of the
same post and clearly meant to be viewed both ways.
Try as I might, I haven't been able to detect any regularly in where
the signs appear or which direction they slant.
And I can't figure out how to search the web. How do you search for
"slanted sign with strips on dirt roads"? I've tried, but I haven't
had much luck. I've found lots of compendia of standard signs for
paved roads and construction areas, but nothing that covers off-road
symbolism.
I've seen them in the Mojave, in deserts in other states like Arizona
and Utah, and even a few along I-5 through the California central valley.
They're clearly a widespread phenomenon, not a regional thing.
Of course, there are lots of mysterious dirt road signs besides
the slanted ones: I don't know what the little round ones mean either,
nor the little houses on thick posts.
Can anyone decode the signs and solve the mystery?
Tags: roadsigns, desert, travel, mysteries
[
11:19 Apr 06, 2011
More misc |
permalink to this entry |
]
Fri, 02 May 2008
This has been a good week for fonts: two longstanding mysteries solved.
The first concerns the bitstream vera sans mono I've been using
as a terminal font in apps like rxvt and xterm. I'd been specifying it in
~/.Xdefaults like this:
XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso10646-1
The mystery is that I'd noticed that in xterm, the font looked
slightly different -- slightly uglier -- than in rxvt (both apps
use the same X class name of XTerm). It was hard to put my finger on
what was different -- the shape of all the letters looked the same,
but it just seemed a little more ragged, and a little less compact,
in xterm. I figured it was just a minor difference in their drawing
code, or something.
Well, I was fiddling with fonts (trying to get the new-to-me
"Inconsolata" font working) and I noticed that iso10646 bit.
I didn't know what 10646 was, but shouldn't it be 8859-1 or 8859-15,
the codes for the Latin-1 alphabet? After finishing up my Inconsolata
experiments, when I set the font back to Vera I changed the line to
XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso8859-15
and moved on to other things.
Until the next morning, when I booted up to a surprise: my main
terminal window no longer fit on the screen. It seems it had reverted
to the other (uglier) version of Vera Sans Mono, which is also very
slightly taller, so instead of being a couple of lines shorter than
the screen height, it was a couple of lines too tall to fit.
I checked .Xdefaults -- yes, it was still Vera. What was going on?
I finally remembered the one thing I had changed:
the language setting on the font, from 10646-1 to 8858-15. I changed
it back: sure enough, now the font was pretty again and the terminal
was short enough to fit.
I fired up xfontsel and did some experimenting. It turned out the
difference between the two almost-identical Vera sans mono bold roman
fonts is a field xfontsel calls "spc". It can be either 'c' or 'm'.
The 'c' version is the pretty, compact font; the 'm' is the uglier,
taller one. For some reason, specifying 10646-1 makes "spc" default
to 'c', while 8859-15 makes it default to 'm'. But specifying 'c'
in the font specifier gets the good version regardless of which
language is specified.
So this would work:
XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-*-*
But then I read up on 10646-1 and it turns out to mean "the
whole unicode character set". That sounds like a good idea,
so I kept it in my font specifier after all:
XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-iso10646-1
(For the moment I still didn't know what spc, c or n meant;
read on if you're curious.)
The second insight concerned a longstanding mystery of Dave's.
He has been complaining for quite a while about the way
Ubuntu's modern pango-based apps all refuse to see bitmapped fonts.
(It bothered me too, but less so, because the terminal and editor
apps I use can see X fonts.)
Dave has an Ubuntu install on one machine that he's been upgrading
release after release, which does see his bitmapped fonts.
But any fresh Ubuntu installation fails to see the fonts.
What was the difference?
We knew about the trick of going into /etc/fonts/conf.d,
removing the symbolic link 70-yes-bitmaps.conf and replacing it
with a link to /etc/fonts/conf.avail/70-yes-bitmaps.conf ...
But doing that doesn't actually change anything, and bitmap
fonts still don't show up.
The secret turned out to be that you need to run
fc-cache -fv
after changing the font/conf.d links. This apparently never
happens on its own -- not on a reboot, not on installing or
uninstalling font packages. Somehow it had happened once on Dave's
good install, and that's why it worked there but nowhere else.
I'm not sure how anyone is supposed to find out about fc-cache --
there's no man fontconfig,
and the /etc/fonts/conf.avail/README offers no clue,
just misleadingly says "Fontconfig scans this directory".
man fc-cache
mentions /usr/share/doc/fontconfig/fontconfig-user.html,
which doesn't exist; it turns out on Ubuntu it's actually
/usr/share/doc/fontconfig-config/fontconfig-user.html.
But wait, that's just an html-ized manual page for fonts-conf,
so actually you could just run man fonts-conf
...
your guess is as good as mine why the fc-cache man page sends
you on a hunt for html files instead.
man fonts-conf
is good reading -- it even solves the
mystery of that spc parameter. It stands for spacing
and can be proportional, dual-width, monospace or charcell.
Aha! And there's lots more useful-looking information in that
manual page as well.
Tags: linux, fonts, i18n, mysteries
[
15:58 May 02, 2008
More linux |
permalink to this entry |
]
Sun, 15 Jul 2007
I continue to be puzzled by the mysterious
chlorine small that
sometimes wafts through the redwood forests during the warm
days of summer.
It's been fairly noticable for about a month now, though it's
patchy and doesn't occur everywhere.
Today's hike was on a trail called "The Lonely Trail", up above
Woodside. It was just as well that it was lonely: no one could see
Dave and me (mostly me) stopping to sniff bushes and trees and rotting
logs and dirt. But alas, no definite culprit emerged.
It did seem stronger when we were next to tanoak trees, though that
is virtually everywhere in these forests.
Tanoak is short for Tanbark-Oak, or Lithocarpus densiflorus.
It's not a true oak (genus Quercus) and is more closely related
to chestnuts. But it's like oaks in many ways -- the tough, shiny
leaves look a bit like larger versions of our local coast live oak
(though the distinctive veins make it easy to tell the two apart).
The acorns, too, are very similar to those of live oaks.
The smell definitely wasn't coming from the tanoak leaves, but it did
seem stronger near the trunks of some of the tanoaks. I'd always
assumed "tan" referred to color (since there are white oaks, black
oaks, blue oaks and red oaks, none of which are really those
colors). But what if it refers to a tree whose bark is particularly
high in tannic acid? What does tannic acid smell like, anyway?
This would still leave some mysteries. Tanoaks are all over bay area
parks, not just in redwood forests. What is it about the deep, shady
redwood forests which bring out this smell, where it's seldom obvious
in the tanoaks of the valleys or rolling hills? Some interaction
between tanoaks and redwoods, or ferns? Something that only happens
in the shade?
I never found a tree that gave me a clear answer -- I merely picked
up subtle hints of chlorine odor from the trunks of a few trees.
Returning home to the digital world, I learned that
the tanoak tree is indeed very high in tannins, and was extensively
harvested for tanning hides. The local native Americans also used
the acorns for flour, after leaching them to remove the bitter acid.
I found no references to odor from tanoak bark or wood,
but a few pages mentioned that the flowers, which hang in catkins,
have a foul odor. No one goes into specifics on this odor.
I didn't see many flower catkins on today's hike,
but they're listed as appearing in June through October.
Looks like I have a research project lined up for the next outing.
Tags: nature, chlorine, mysteries
[
22:30 Jul 15, 2007
More nature |
permalink to this entry |
]
Sat, 29 Jul 2006
A few weeks ago, hiking in the woods, I noticed it was happening
again: the smell of chlorine in a forest far away from pools or
other likely sources of chlorine smell. This happened about this time
last summer, too. It only lasts for a few weeks: apparently there's
something that blooms briefly in deep redwood forests which smells
like pool chlorine.
Whatever it is, it's pervasive and not very localized.
I never notice it getting stronger near any of the
trails where we hike -- it's more a general odor one notices while
driving along forest roads.
That makes it hard to narrow it down to a specific plant.
Googling wasn't entirely enlightening, but it did suggest that the
most likely culprit is a mushroom.
Various species of Mycena mushrooms apparently emit a
chlorine-like odor, especially when they're growing on wood.
Chlorine smells are also reported from
Marasmius oreades, the "fairy ring" or "scotch bonnet" mushroom,
and from Amanita chlorinosma and A. polypyramis.
But I didn't find anything about widespread seasonal blooms of
any of these mushrooms.
So the mystery remains, and I guess all that's left is to remember,
when hiking in the redwood forest at this time of year,
to stop and smell the mushrooms.
Tags: nature, chlorine, mysteries
[
11:36 Jul 29, 2006
More nature |
permalink to this entry |
]