minised in now in Fedora – The GNU used-to-use SED implemention

I first heard mininsed when after using Linux for more than 5 years(although long long ago). As described from its official website, it’s a smaller, cheaper, faster SED implementation and Minix uses it so far. Then I found that GNU used to use it but now they’ve developed a brand-new sed with many extensions.

The first version was released in 199x years which I just got borned icon biggrin minised in now in Fedora   The GNU used to use SED implemention

I really don’t know what’s the difference between sed and minised. And I doubt only few people will use minised. “Why should I type 7 chars in order to run an command rather than 3 chars?”

But I still packaged it into Fedora as I treat it like an historic software which should be covered in current Linux distros.

Now I’m pacakging many projects founded by Eric S. Raymond, he has written so many applied small useful programs.

Just try:

If you can tell the difference between sed and minised, I wll be really very happy to include them into this post.

lnav is now in Fedora – A Logfile Navigator

The Logfile Navigator, lnav for short, is a curses-based tool for viewing and analyzing log files. The value added by lnav over text viewers / editors is that it takes advantage of any semantic information that can be gleaned from the log file, such as timestamps and log levels. Using this extra semantic information, lnav can do things like: interleaving messages from different files; generate histograms of messages over time; and providing hotkeys for navigating through the file. It is hoped that these features will allow the user to quickly and efficiently zero-in on problems.

The major features of lnav are:

  • Support for the following log file formats:

    Syslog, Apache access log, strace, tcsh history, and generic log files with timestamps. The file format is automatically detected when the file is read in.

  • Histogram view:

    Displays the number of log messages per bucket-of-time. Useful for getting an overview of what was happening over a long period of time.

  • Filters:

    Display only lines that match or do not match a set of regular expressions. Useful for removing extraneous log lines that you are not interested in.

  • “Live” operation:

    Searches are done as you type; new log lines are automatically loaded and searched as they are added; filters apply to lines as they are loaded; and, SQL queries are checked for correctness as you type.

  • Automatic tailing:

    The log file view automatically scrolls down to follow new lines that are added to files. Simply scroll up to lock the view in place and then scroll down to the bottom to resume tailing.

  • Time-of-day ordering of lines:

    The log lines from all the files are loaded and then sorted by time-of-day. Relieves you of having to manually line up log messages from different files.

  • Syntax highlighting:

    Errors and warnings are colored in red and yellow, respectively. Highlights are also applied to: SQL keywords, XML tags, file and line numbers in Java backtraces, and quoted strings.

  • Navigation:

    There are hotkeys for jumping to the next or previous error or warning and moving forward or backward by an amount of time.

  • Use SQL to query logs:

    Each log file line is treated as a row in a database that can be queried using SQL. The columns that are available depend on logs file types being viewed.

  • Command and search history:

    Your previously entered commands and searches are saved so you can access them between sessions.

  • Compressed files:

    Compressed log files are automatically detected and uncompressed on the fly.

IMO you can scroll up/down/right/left the log file without resizing the window. And it also contains a proportionally sized scrollbar.

On color displays, the lines will be highlighted as follows:

  • Errors will be colored in red;
  • warnings will be yellow;
  • boundaries between days will be underlined; and
  • various color highlights will be applied to: SQL keywords, XML
  • tags, file and line numbers in Java backtraces, and
  • quoted strings.

You can view its powerful feature via this screenshot:

lnav1 lnav is now in Fedora   A Logfile Navigator

This is really powerful.

On the top of itself, you can see the current time, and an important feature is that it can display the number of warnings(W) and errors(E) and the name of the log file; At the bottom you can also notice log lines in time sorted order and highlighted.

For more information, please refer to its instructions.

Install(if you cannot find this in Fedora 18+, please enable update-testing channel if you want):

lookat is now in Fedora – A user-friendly text file viewer

Well, lookat has been pushed into Rawhide and update-testing of f18/19. Just yum install lookat and taste.

lookat is a advanced alternatives of GNU coreutils such as less/more/view and others. Here are some screenshots which you can quickly find out what it is:

Screenshot from 2013 05 10 152822 lookat is now in Fedora   A user friendly text file viewer Screenshot from 2013 05 10 153041 lookat is now in Fedora   A user friendly text file viewer

The current version in Fedora is 1.4.2 released at Dec, 2012. 1.4.3 is now in RC rolling so I will update it when it’s ready for production.

You can:
– by just typing ‘lookat’, after the program is started you can select the
file you want to view.
– by typing ‘lookat <dir_name>’, change the current directory to <dir_name>.
– by typing ‘lookat <filename>’, the file with <filename> will automatically
be loaded.
– read form stdin
examples : lookat < test.txt
ls | lookat
– use ‘lookat’ as a manual page viewer : man -P lookat <name>

It supports syntax-highlight (basic, not for programming language) and I think you can navigate your working dirs just via lookat and choose which one you like to open it. It’s easy for life.

How to judge OS version in RPM

If we make an RPM for various users with various system, like someone in RHEL6 and someone in FC18, what should we do when installing systemd or sysv files?

Then we can define requires of systemd is whether needed or not like this:

rpmbuild 的 bug

昨天打包的时候,先去 SUSE 看了看有没有类似的 SRPM,还真幸运,找到了一个。修改了一下,不过问题出来了,这个 spec 在 Fedora 下无法编译。

虽然这个 bug 是由我人为造成的,但是这次的问题也很严重。因为达到 Core Dump 的水平,对于这种软件,的确是一个不小的问题。

后来问题已被上游修复

具体的问题就是,如果开头我有类似的路径定义:

%if 0%{?suse_version}
%define apxs /usr/sbin/apxs2
%else
%define apxs /usr/sbin/apxs
%endif

然后有这条定义:

%define apache_sysconfdir       %(%{apxs} -q SYSCONFDIR)

如果我注释掉 apxs 的路径判断语句,在 %files 分类下,如果有定义

%dir %{apache_sysconfdir}/../conf.d

这时候 %{apache_sysconfdir} 返回值就为空了。上面这段路径就会变成了:
/../conf.d

哦,看见没!RPM 认为这个路径是合法的,但是这时候已经脱离了 BUILDROOT 了,随后步骤就会失败因为路径根本不在 BUILDROOT 里面,变成了系统根目录。而这就是 RPM 的一个缺陷。我在想,如果我构造一个 RPM 包,最后离开了 BUILDROOT 而是进入了真实的文件系统,会不会可以构成 exploit ?本人水平有限,实在无法完成,只能等待日后了。

软件许可证

今天打包某图像处理程序时发现了很奇怪的许可证,貌似是 SUSE 自家搞的一个协议,叫做 SUSE-Permissive。随后查找半天也搞不懂这协议源头是哪里。于是想看看协议究竟有多少,顺便科普一下。

后来我在想,做软件开发,肯定会有写 LICENCE 的这一步,选一个正确恰当的 LICENCE 是每个人都要必须面对的问题,世界上有超过2000种不同的协议,虽然可以寻找律师,不过对某国人来讲版权什么的就是扯淡,律师不就是打官司的么?

不是所有人都会自动写一个 COPYING 和 LICENSE 文件到 tarball 中,即使包含了相应文件,谁又能保证万无一失呢?可是选协议总得有个汇总规范吧,找来找去多费事,最后找到了 spdx.org。什么是 SPDX 呢,按照官方的说法就是:

The Software Package Data Exchange® (SPDX®) specification is a standard format for communicating the components, licenses and copyrights associated with a software package.

字面意思,差不多就是一种有关许可协议的标准规范,Debian 有一个页面讲述了目前 Debian 的情况,OpenSUSE 据称也实施了该标准,有一份文档显示了 OpenSUSE 的情况。

SUSE Mapping for spdx.org  软件许可证

可以看出,规范性大大加强了。

不过,在看完标准规范的 PDF 后,我个人感觉 SPDX 缺点就是太臃肿, rdf 文件需要工具来写,尽管工具官方有,问题是需要写的选项很多,规范中规定了大量需要写的内容,虽然是自动化生成,不过总觉得太套路化了。如果为了一个软件,还要学习 spdx,额,好吧。

Fedora 这方面不是很清楚,我认为应该做了,但是通过浏览 Tom (Red Hat employee & SPDX member)给出的页面 发觉仍然不是很清楚。

无论如何,希望软件的许可证能够尽早规范化,让用户和其他开发者一目了然。

RPM 脚本判断系统

如果偷懒不想写两份 spec,那么可以这么弄:

举个例子,RHEL5 中 php 软件包的版本较低,EPEL 还有 php53 这个包,那么可以通过该语句在安装某些需要 php 的软件包时先进行判断:

Fedora Rawhide SpeedUp with “nodebuginfo” kernel

Recently I found that my os is too slow…Sounds like a bit weird but it’s the fact……My ThinkPad has a low than 2.0Ghz CPU and after long time using it becomes slower and slower.

So I found a way to speedup my rawhide by using no debuginfo kernel…As is depicted in the wiki, just following this:

This will automatically solve the dependencies and update current kernel to the no debuginfo version.

Seems a little bit faster….But I should buy a new computer indeed… icon smile Fedora Rawhide SpeedUp with nodebuginfo kernel

$’\r’: command not found

Today I copied my rpm script from Windows to Fedora, when rpmbuild it noted me $’\r’: command not found. I tried many ways including fix an error in the spec and it still noted me.

Then I looked into \r and find that this is a Windows-releated problem. So I use one tool to convert:

Then it came back normal!