When I find a functional bug in an application, I think it’s useful to post the solution for others to find. Here are two recent problems I solved.
Thunderbird allows you to switch SMTP servers. However, sometimes it appeared like the setting change wasn’t taking effect. While I’d change the server, some mail would still use the old setting and some would use the new. Even plug-ins designed to help with this didn’t work reliably.
I tracked this down to the Identities feature. It allows you to set up different identities (email addresses) under a single account. This means that with two identities, there are actually three different places the SMTP server and other information is set. The global account settings panel (Tools -> Account Settings -> Outgoing Server (SMTP)) and all identities (… -> Manage Identities -> Edit each profile) need to be changed in order to switch servers. While I agree that some things make sense to make local to an identity (e.g., signature file), SMTP server should only be a per-account setting.
I like using cygwin on Windows for a somewhat reasonable Unix-like environment. There are two shells that can be used: bash and rxvt. The bash shell runs within a Windows command prompt instance, and inherits the same annoyances from there. Text selection works differently, there is no real terminal emulation, and scrollback is not reliable. I switched to rxvt to fix a lot of those problems, but had to keep bash around for one reason. When I tried to run Windows python from rxvt, it would just hang during startup. The cygwin python worked fine.
It turns out that the rxvt code allocates a pty. You can see this by typing “tty” in both bash and rxvt. The former reports “/dev/console” and the latter, something like “/dev/tty1”. I believe the reason is that Windows consoles (and thus bash) actually use a separate API for working with the user. Thus, Windows python calls to that API hang if the shell isn’t actually running in the console.
This is similar to an experience I had trying to do asynchronous IO with a Windows console. I had written a small serial port comms tool that would work interactively, printing output when the device generated it and accepting input from the user. It worked fine until the user started typing, then the input routine would block. Nothing worked with it, not WFMO, setting asynchronous mode on the stdin handle and polling, or even threads. A read from the console blocks all process execution, including all the process’s threads, until the input is completed.
I hope this helps you if you encounter similar problems.
If you run the windows python like this:
/cygdrive/c/Python24/python -i
things will work interactively. You’ll have to kill it with quit() or sys.exit() to get out instead of ^d or ^z.
Nice tip, Shawn.
sounds like it’s time to detour console apis to cygwin tty
Danny, I didn’t know you were still alive, let alone read my blog. :-)
Danny had another comment, sent via email:
i am, i do, and i found a more generic answer.. tfy!
http://sources.redhat.com/ml/cygwin/2006-03/msg00164.html
it doesnt quite detour the console apis, but close. it does a dll
injection, that when run, creates threads that hook the console
handles back up to the bootstrapper program via pipes. the
bootstrapper then translates console stuff to something more
xterm/vt100 friendly using ncurses.
I just installed Cygwin on Win XP SP-3 and was puzzled by the absence of gcc.
I would get back bash: gcc: command not found. It turns out that gcc isn’t linked to anything and there is, in fact, gcc-3.exe and gcc-4.exe in /usr/bin.
A simple symbolic link solved the problem. Hope this helps