無標題文檔

Shell 不是 BASH,BASH 是 Shell

标题听起来像是在绕口令,不过很多兄弟都会将 BASH、CSH 和 ZSH 以及 Shell 之间的关系搞混。本人似乎又在「误人子弟」了,下面是我和 ghosTM55 兄弟 的一些聊天记录,整理如下。

ghosTM55: 自动补全是 Shell 极为有用的一项拓展功能 ,这句话有没有错?
手气不错: 应该是 BASH,Shell 是一个接口,而不是程序
ghosTM55: 好的,明白了。那么为什么有 Shell 分类这种说法呢?
手气不错: Shell 的主要功能就是封装内核和系统调用,提供统一的接口供
          用户使用。比如你编辑 /etc/passwd 更改用户默认的 shell 为
          ls,那么就显示一下当前用户目录就退出了。这是因为 ls 发送
          了 Shell 退出同样的信号(通常为 EXIT_SUCCESS)。
ghosTM55: 对
手气不错: 同时 Shell 会在幕后做很多的事情。比如你在 Shell 中输入 ls
          回车。它要做的事情首先就是在 PATH 中寻找 ls 程序。
ghosTM55: 恩
手气不错: 然后 exec() 运行 ls,等待 ls 返回,然后 shell 获得 ls 的
          退出返回值(信号),程序结束。
          这你可以看 time ls 就知道,有一个用户进程和内核进程的概念。
          大致的流程就这样,不过通常 shell 要做的事情比上述要做的事
          情要复杂得多。
ghosTM55: 那么 Shell 的种类这种讲法是不存在的?
手气不错: 这就回到上面所提到的了,shell 我个人认为是一个接口,可以有
          不同的实现(有一个叫 POSIX 标准的东西),对比 bash、csh、
          zsh 等等这些 Shell,这就像虚拟终端(Virtual Terminals)有 
          xterm、rxvt 一样。所以,引证上面的话,说终端都有半透明功能,
          这是不正确的 - 有可能就 rxvt 有这样的功能。
ghosTM55: 哦

简而言之,可以用下面的图来理解 内核 - Shell - 应用程序 - 用户 之间的的关系(图片引自 这里 )。

https://friable.rocks/_/2008_01_09/536750136.jpg

想更深入了解 Shell 机制的,可以参看 这里这里

更正:感谢寂寞烈火等兄弟的 指正 ,「应该是 BASH,Shell 是一个接口,而不是程序」这句话是 错误 的。应该是:

理论上,只要你愿意,任何一个程序都可以作为你的 Shell。- 引自 r2007 兄弟

改变控制台的字体

近日,wu qiong 兄弟问我上次的 一篇文章 中,控制台的字体是怎么设置的。我在这里详细说一下,其实使用 setfont 脚本就可以非常简单的完成这一效果。

https://friable.rocks/_/2007_11_10/1194688414.gif

前提条件是控制台已经启用了 framebuffer (启动的时候屏幕的顶端有个小企鹅)。接下来,调用的命令非常简单:

setfont -v 字体名称

就可以了。而各字体的名称,你可以在 /usr/share/kbd/consolefonts/ 下找到它们(Slackware 11.0)。Slackware 下,其实 /etc/rc.d/rc.font 文件就是专门定制控制台字体的配置文件(如果没有,可以找找 rc.font.new 等名称,更名即可)。在脚本里设置相应的字体,并将此文件设置为可运行(chmod +x /etc/rc.d/rc.font ),即可每次启动的时候自动设置成相应的字体。

本人推荐使用 term 系列字体,比如 ter-g16f.psf.gz 字体的效果就非常的好。截图中的字体则是 sc.fnt.gz 字体。下面是使用 sc.fnt.gz 字体查看 setfont 的 man 的效果( 在这里 可以查看大图)。

https://friable.rocks/_/2008_01_05/281199310.jpg

更详细的文档信息可以参考 这里这里(Debian 系统)

最后,很多的兄弟不知道控制台下面如何截图, fbgrab 程序 就可以做到。但是编译 fbgrab 需要 splint 工具 (它是代码检查工具,通常也用不到)。 在这里 提供已经编译好的静态链接版本(Slackware 11.0 下编译,bzip2 压缩)。

支持中文 ID3 的 Mp3blaster

从 LinuxToy 上面看见关于 Mp3blaster 的介绍 ,但是有很多兄弟反应他不支持中文 ID3。由于这个问题我以前也碰到过,而且是已经解决了的,下面说说我的解决的办法。

包路径下有个 src/id3parse.cc 文件,里面有一个函数如下:

/* tampers with 's' to replace non-printable chars with dots. */
void
convert_to_sane_string(char *s)
{
    unsigned int
        cnt = strlen(s),
        i;

    for (i = 0; i < cnt; i++)
    {
        if (s[i] < (char)32)
            s[i] = '.';
    }
}

它的主要问题就是 strlen 不支持多字符集(比如中文),所以都将中文转换成了 '.'(点) 。而本身这个函数就起到一个过滤的功能,所以加上多字符集的判断(Multibyte String)我个人感觉没有必要,就直接注释掉了。

最后发现中文 ID3 就可以正常显示了(手气真的不错)。下面是一个效果图一张:

https://friable.rocks/_/2008_01_02/1768415811.jpg

最后,提供我修改后的代码 打包下载 ,感谢本部门的唐工同志提供 Linux 环境。

请使用 MySQL Date/Time 类型

上次对于 MySQL 方面已经有的 一些总结 ,但是昨晚 wiLdGoose 兄 说他也碰到同样的问题,但是无法解决。结果经过种种的假设和判断以后,到最后发现原来是 Zend Studio 的时区配置问题(我狂汗ing)。而在和他讨论期间也谈到了很多关于 MySQL 的细节问题,还是记录一下当作备忘比较好。这篇文章同时也做说服 wiLdGoose 兄用。

由于曾经和他是同一个团队的,所以对于其我很熟悉他那「洁癖」的做法,对于他的很多的观点我也非常的赞同;但是有一件非常不理解的地方就是设计数据库的时候总是会回避使用 Date/Time 类型。他的做法是将时间相关的字段设置为 INT(10) 类型,然后用 UNIX 时间戳来存储。而我本人对于这点做法非常的不赞同:

首先,是类型操作的不同,类似于 wiLdGoose 这样做法的「时间计算」实质上是整形之间的操作(而且这个整形非常大,长度为 10)。更有甚者,将时间戳设置为 VARCHAR(10) ,由此引发的效率问题不言而喻。

至于时间计算和整形计算乃至字符串的计算的效率问题, 这篇文章 非常能说明问题。

其次,是逻辑方面的操作问题。这是使用时间类型的优势,尤其是在需要高精度的项目上。比如需要「前一个星期的数据」和「获得从数据库建立以来每个星期一的数据」,这样的操作如用 wiLdGoose 兄的做法复杂度可想而知。

最后,就是直观不直观的问题,可以理解的是我们的大脑是不会直接将这一大串的时间戳转换成日期格式的。相比而言,直接使用时间类型明显就直观得多(它本身就是时间格式)。

而我目前的团队也还是在使用类似的方法。本人对于类似技术细节也 争执了良久 ,但由于岗位和决定权的问题,团队还是无法采纳本人的意见,甚为遗憾。

MySQL 定位为简单快速的 DBM 自然能迅速的驾驭,但是另一方面很容易造成不会深入下去的局面。对于此,我们更应该注意每一项的数据库设计细节,一项产品不断添加新的功能到最后都是面向应用的。

最后,附 MySQL 官方的 时间和日期函数的手册

数据库选择何种 API 摘记

这几天翻阅了尘封已久的 MySQL Reference Book 。虽然这是一本老书并且已经阅读过多次,但是反复的阅读还是能温故知新。里面有段关于如何选择数据库 API 的言论,我认为这不仅仅是在 MySQL 上面适用,其他的数据库也同样可以参照这个总结。

于是我就花了一点时间做了一下摘记。大家如果有更好的见解,欢迎指出。

平台和应用程序要求

通常,在开发使用的平台决定了对 API 或编程语言的选择。这种情况下,在选择 API 是能够使用的语言和开发环境将起到决定的作用。例如 C 编译程序可以在大多数体系结构中使用,但是 PHP 和 Perl 的解释程序可能就不行。

在决定选择变成语言和 API 时,应用程序的要求也会起到非常重要的作用。不同的语言会具有不同的特点,比如 Perl 对于文本处理具有优势,而 C 和 C++ 可以提供对内存管理的更精密的控制。重要的是要利用语言的长处,满足应用程序的实际要求。

性能

十分明显,应用程序的性能在选择 API 和语言中是一个十分重要的决定性因素。总体目标是让应用程序更快,更加方便用户。假设其他条件都相同,则基本的决定因素就是希望对于应用程序使用一种编译语言(如 C)、还是一种解释语言(如 PHP)。

两种方法都有其优缺点。编译代码的实行速度通常必要解释型的代码要快,应为执行编译程序是,就已经把源代码转换成了机器语言,因此与解释型的代码行必,其速度有了实质性的改善,处理速度会很快。但是,解释性语言是一种很好的代码开发和排错工具,因为这些代码在每个阶段的测试之前不需要进行编译。

编译代码在不同的平台之间一般不可移植,应用程序在即将运行的平台上需要重新进行编译,而解释型程序则可以在任何平台或结构上面运行,只要提供相应的解释器就可以。

简单性

KISS 原则(尽量简单扼要)适用于很多的软件工程,简单化和容易使用的原则在决定使用哪种 API 时成为重要的因素。大多数实际的项目开发时间都很紧张,费用压缩即使在具体语言可能在技术上最适合应用程序的情况下,如果开发的代码属于时间和资源紧密型的,也可能无法通过成本效益测试。

这种情况下,时间和费用的因素可能必要使用最优化的技术更为重要,退而求此次可能会使解决方案更简单。

可提供的库和工具

影响选择 API 的另一个重要因素是可以为这种语言提供的十分复杂的库模块。这种额外的库的提供,实际上可以减少开发新新功能花费的时间。而同时通过使用经过测试的、可以公开使用的代码模块改善了可靠性。

可移植性

可移植性也是坐在选择开发语言时需要考虑的一个重要因素。很明显,只能在单一处理器或者架构上使用的语言,要比可以跨多种处理器和平台平台的语言的价值要低。

如果应用程序将计划在不同的平台上使用,则在实现编写代码之前需要探讨一下可移植性方面的问题。如果处理不当,到了后面阶段问题将会相当的严重。

成熟性

在决定使用一个 API 时,应该考虑的因素还包括这种语言的成熟性。一种成熟的开发语言满足公开标标准,可以支持开发者社区,而且还能得到广泛的文档支持和在线社区的帮助。

虽然他们属于非技术的因素,但是这些因素在决定原则语言是将起决定性的作用。十分明显,文档越多、支持越广,也就越容易提高应用程序的开发速度,从而能确保按时提交产品。

费用

一个重要的因素而且经常在纯技术讨论中会被忽略的因素是:使用某种语言需要的开发工具费用。这种计算项目所需工具的真正费用是一件重要工作,并且有时会限制使用针对特别重要的某些语言或 API,例如类似 C 和 Java 语言可能需要投资一些高质量的商业编译程序。

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHub (2) 、 TwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 其实无所谓叫什么名字,作为码农知道取名是件很难的事情。最后想到的这个名字,其实都没啥特别的含义,系统默认的文件名而已。

作为八零后,自认为还仅存点傲娇式的幽默感,以及对平淡生活的追求和向往。 为了免得对号入座和不必要的麻烦,声明本站点所持观点仅代表个人意见,不代表自己所服务公司的立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

文章

项目