Shallow Thoughts : tags : mysteries

Akkana's Musings on Open Source Computing and Technology, Science, and Nature.

Thu, 31 Aug 2023

Signs on the Way to San Antonio Hot Springs

[Rock wall on the way to San Antonio Hot Springs] 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: , ,
[ 12:06 Aug 31, 2023    More hikes | permalink to this entry | ]

Thu, 28 Aug 2014

Debugging a mysterious terminal setting

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:

    stty -a | fgrep -- -ignbrk > /dev/null
    if [ $? -ne 0 ]; then
        echo "STTY SETTINGS HAVE CHANGED \!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!"
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: , , ,
[ 15:41 Aug 28, 2014    More linux | permalink to this entry | ]

Mon, 01 Aug 2011

Chlorine and reptiles

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: , ,
[ 11:31 Aug 01, 2011    More nature | permalink to this entry | ]

Wed, 06 Apr 2011

Slanted signs on dirt roads -- what do they mean?

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.

[slanted dirt-road sign] 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.

[slanted dirt-road sign] [slanted dirt-road sign] 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.

[slanted dirt-road sign] 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: , , ,
[ 11:19 Apr 06, 2011    More misc | permalink to this entry | ]

Fri, 02 May 2008

Two font mysteries solved

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: , , ,
[ 15:58 May 02, 2008    More linux | permalink to this entry | ]

Sun, 15 Jul 2007

Sniffin' the Oaks

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: , ,
[ 22:30 Jul 15, 2007    More nature | permalink to this entry | ]

Sat, 29 Jul 2006

What's that chlorine smell in the woods?

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: , ,
[ 11:36 Jul 29, 2006    More nature | permalink to this entry | ]