作者文章: Fenng

MT 4 最烦人的BUG: 反复提示升级

我前面的文章一直夸 MT 4 的一些优点，今天实在忍不住了，说说 MT 4 这个恼人的 Bug。

从 MT 3.3x 升级到 MT 4 之后，经常在登录的时候会提示：

Time to Upgrade!

而且，这个提示还是没办法跳过去的，只得选择 Upgrade，Upgrade 之后，很多配置和模版的内容又变成默认的，还要重新设定。可没几天，又会提示升级。烦死。

在 MT 邮件列表里发了这个消息（可怜我的蹩脚英语啊)，发现很多人都遇到了类似的情况。但是 Byrne Reese 似乎一时也找不到好的办法，许诺谁能协助解决将有奖励： ” A $50 Amazon Gift Certificate/Bounty has been declared for anyone who can help us track down the root cause of this”。此外，MT 4.01 Beta 版的问题列表也说这个问题还没有解决。

经过观察，发现每次都是提示数据库 Schema 版本从 MT 3.2 升级到 4.0026。邮件列表里有个人的提示很有帮助：

The upgrade check is in MT/App/CMS.pm, sub init_request.  It occurs when the schema version stored in the database ($app->config('SchemaVersion')) < the schema version stored in the application code ($app->schema_version).

数据库里面 Schema Version 存储在 MT_CONFIG 表里，检查这个表的记录(共有20多条)，发现第一条(config_id) 的config_data字段的值为：

SchemaVersion 4.0026
SQLSetNames 0

而其他行的值是：

SQLSetNames 0

也就是说其他行是不包含 SchemaVersion 的值。猜测升级程序在这里取值取错了(这个表的设计也够糟糕的了)，立刻找一个全新的 MT 4 安装，发现这个表是只有一行记录的。决定删掉多余的记录。目前没有发现错误。

是否彻底避免了这个问题，还有待观察。如果你等不及的话，可以看看 MT_CONFIG 表的数据是否也是类似我这样的。

–EOF–

倡议提高 RSS 输出内容的可读性

我大约订阅了 800 条 RSS。如何有效率的浏览就是个问题。现在遇到的一个比较烦的是，很多 RSS 里面的内容格式很糟糕，没有经过格式化，一大堆连在一起。很影响阅读。

看个例子：

以前关于 RSS 是否输出全文 曾经有过一个大讨论。之后的趋势是越来越多的 RSS 输出全文了。这是个好事情。当然，没有输出全文的，咱也订阅(没必要那么愤青嘛)，但是，但是，你输出的那一丁点内容能否格式化一下呢? 对于文章概述看起来都费劲，这个用户体验也太差了吧?

这里要点名批评一下 WordPress，输出的 RSS 可读性是很差的(可能是大多数人都在用那个糟糕的默认编辑器有关)，这一点上在 Movable Type 就容易控制。其实提高可读性也没那么复杂的，最简单到添加一个分段标记即可。

现在，用我最大的声音倡议一下：诸位 Blogger ，请把您的 RSS 输出弄得更容易读一点吧!

赞同的请举手！

BTW: 我的 MT 用的 RSS 模版, 另外，WP 的用户不妨参考一下: AnySQL 的建议

–EOF–

申请了雅虎邮箱的全新域名@yahoo.cn ID

中国雅虎这一招也挺绝的。后缀为 yahoo.cn 的邮箱提前对原后缀为 yahoo.com.cn 的 VIP 用户提前开放。网易原来急吼吼的喊着要赶在中国雅虎之前推出无限量邮箱的，看来是没机会了。你有张良计，我有上房梯。笑死。

Yahoo.cn.Email.png

现在注册要得到邀请信才可以，得不到邀请的可以不用着急，过不了几天就都开放了。

本来想用 “Fenng” 这个 ID 注册，可惜不允许，那就注册一个 “dbanotes” 。无限量容量，谁能用多少呢? 这下子大家心理上都满足了。

–EOF–

如何确保 Shell 脚本只有一个实例运行

在做维护的时候，经常要写一些脚本定期检查一些状态信息，而比较糟的时候可能该脚本在执行周期内没完成，接着第二个脚本又开始跑了。如何确保 Shell 脚本只有一个实例运行就成了一个比较有意思的话题。

必需要承认，要做到 100% 的完美可能需要长篇大论才可以做到。如果对于粒度要求不高，这里总结两个粗糙的方法。

一个是在脚本执行的时候判断某个文件的存在，如果不存在，则 touch 创建该文件(该文件看作一个”占座”文件)，脚本执行完毕的时候删掉。第二个进程如果启动，判断有该文件存在，则退出或者是 sleep 几秒钟重新判断。这个方法的关键是在删掉”占座”文件的处理方式上。必需要考虑到程序异常、被 Kill 等多个情况。根据需要 trap 搞一下。

trap 和 kill 命令的 -l 参数能够列出你想要的内容

第二个方法是过滤脚本的名字(当然最好把脚本起个独特一点容易过滤的名字)，计数，如果存在一个或者多个 instance , 则退出或者 sleep 等待。否则执行脚本。这个方法最简单，但是移植性似乎要差一点，需要考虑不同平台或 Shell 上的表现。

这两个方法都太粗糙了，经不起考究，但是对于 99% 的系统可能都足够用了。反过来说，如果一个系统对于脚本运行的粒度要求非常高，需要考虑到操作的原子性，那么 Shell 或许并不适合完成这个任务。

解决问题就好，过分炫技不可取。

–EOF–