<![CDATA[牧龙在野!]]> http://www.zhanghongbiao.com/index.php zh-cn http://www.zhanghongbiao.com/post/810/ <![CDATA[html代码大全]]> mlzy <mlzy@live.com> Sun, 07 Sep 2008 12:46:03 +0000 http://www.zhanghongbiao.com/post/810/ 1.结构性定义
文件类型 （放在档案的开头与结尾）
文件主题 （必须放在「文头」区块内）
文头 （描述性资料，像是「主题」）
文体 （文件本体）
（由浏览器控制的显示风格）
标题 （从1到6，有六层选择）
标题的对齐
区分

区分的对齐

引文区块
（通常会内缩）
强调 （通常会以斜体显示）
特别强调 （通常会以加粗显示）
引文 （通常会以斜体显示）
码 （显示原始码之用）
样本
键盘输入
变数
定义 （有些浏览器不提供）
地址

大字
小字
与外观相关的标签（作者自订的表现方式）
加粗
斜体
底线 （尚有些浏览器不提供）
删除线 （尚有些浏览器不提供）
下标
上标
打字机体 （用单空格字型显示）
预定格式 
 （保留文件中空格的大小）
预定格式的宽度 
（以字元计算）
向中看齐 
 （文字与图片都可以）
闪耀  （有史以来最被嘲弄的标签）
字体大小 （从1到7）
改变字体大小 
基本字体大小  （从1到7; 内定为3）
字体颜色 
2.连结与图形
连结 
连结到锚点 （如果锚点在另一个档案）
 （如果锚点目前的档案）
连结到目的视框 
设定锚点 
图形 
图形看齐方式 
图形看齐方式 ALIGN=LEFT|RIGHT|TEXTTOP|ABSMIDDLE|BASELINE|ABSBOTTOM>
取代文字 *** （如果没有办法显示图形则显示此文字）
点选图  （需要CGI程式）
N2.0 点选图 
N2.0 地图 （描述地图）
N2.0 段落 
3.0 大小 （以pixels为单位） N1.0 图形边缘  （以pixels为单位）
N1.0 图形边缘空间  （以pixels为单位）
N1.0 低解析度图形 
N1.1 用户端拉 （使用端自动更新 ）
N2.0 内嵌物件  （将物件插入页面）
N2.0 内嵌物件大小 
3.分隔
段落 
 （通常是两个return）
3.0 段落 
 （新定义成容器型标签）
3.0 文字看齐方式 

换行 
 （一个return）
N1.0 文字部份看齐方式
（与图形合用时）
横线 

N1.0 横线对齐 

N1.0 横线厚度 
 （以pixels为单位）
N1.0 横线宽度 
 （以pixels为单位）
N1.0 横线比率宽度 
 （以页宽为100%）
N1.0 实线 
 （没有立体效果）
N1.0 不可换行  （不换行）
N1.0 可换行处  （如果需要，可在此断行）
列举 （可以巢状列举）
无次序式列举 
 （
  •  放在每一项前）
    N1.0 公布式列举 
      （定义全部的列举项）
    • （定义这个及其後的列举项）
      有次序式列举 
       （
    •  放在每一项前）
      N1.0 数标型态 
         （定义全部的列举项）
      1.  （定义这个及其後的列举项）
        N1.0 起始数字 
           （定义全部的列举项）
        1.  （定义这个及其後的列举项）
          定义式列举 
          （
          项目, 
          定义）
          表单式列举 
        2. （
        3.  放在每一项前）
          目录式列举 
        4.  （
        5.  放在每一项前）
          背景与颜色
          3.0 重复排列的背景 
          N1.1+ 背景颜色  （依序为红、绿、蓝）
          N1.1+ 文字颜色 
          N1.1+ 连结颜色 
          N1.1+ 看过的连结 
          N1.1 使用中的连结 
          4.特殊字元（以下标签需用小写）
          特别符号 &#?; （其中 ? 代表 ISO 8859-1 的编码）
          < < > > & & " "
          注册商标TM ®
          N1.0+ 注册商标TM ®
          著作权符号 ©
          N1.0+ 著作权符号 ©
          5.表单 （通常需要与CGI程式配合）
          定义表单 

          N2.0 上传档案 

          栏位名称 
          栏位内定值 
          已选定  （适用於checkboxes与 radio boxes）
          栏位宽度  （以字元数为单位）
          最长字数  （以字元数为单位）
          下拉式选单 
          下拉式选单名称 
          选单项目数量 
          多选式选单 
          输入区名称 
          N2.0 输入区换行方式 
          6.表格
          3.0 定义表格 

          3.0 表格框线 
           （有或没有）
          N1.1 表格框线 
          （可以设定数值）
          N1.1 储存格左右留白 
          N1.1 储存格上下留白 

          N1.1 表格宽度 
           （以pixels为单位）
          N1.1 宽度比率 
           （页宽为100%）
          3.0 表格列 
          3.0 表格列内容看齐 
          3.0 储存格  （须与列并用）
          3.0 储存格内容看齐  （跟
          3.0 表格抬头看齐 
                
              

          前加上：


                   
                      
                    


          （2）修改文件：dede/templets/article_edit.htm

          在：


                
                  

          前加上：


                   
                      
                    


          6、修改文章添加和修改的处理页面，对 form 里提交的 pagename 进行处理

          （1）修改文件： dede/action/article_add_action.php

          A、在　$title =  cn_substr($title,80);　下面增加一行　$pagename = trim($pagename);

          B、在下面增加以下红色部分（看准颜色）。

          //加入数据库的SQL语句
          //----------------------------------
          $inQuery = "INSERT INTO `{$cts['maintable']}`(
          ID,typeid,typeid2,sortrank,iscommend,ismake,channel,
          arcrank,click,money,title,shorttitle,color,writer,source,reader,litpic,
          pubdate,senddate,arcatt,adminID,memberID,description,keywords,templet,redirecturl,likeid,pagename)
          VALUES ('$arcID','$typeid','$typeid2','$sortrank','$iscommend','$ismake','$channelid',
          '$arcrank','0','$money','$title','$shorttitle','$color','$writer','$source','$reader','$litpic',
          '$pubdate','$senddate','$arcatt','$adminID','0','$description','$keywords','$templet','$redirecturl','$likeid','$pagename');";


          （2）修改文件： dede/action/article_eidt_action.php

          A、在　$title =  cn_substr($title,80);　下面增加一行　$pagename = trim($pagename);

          B、在下面增加以下红色部分（看准颜色）。

          //更新数据库的SQL语句
          //----------------------------------
          $inQuery = "
          update `{$aTables['maintable']}` set
          typeid='$typeid',
          typeid2='$typeid2',
          sortrank='$sortrank',
          redirecturl='$redirecturl',
          iscommend='$iscommend',
          ismake='$ismake',
          arcrank='$arcrank',
          money='$money',
          title='$title',
          color='$color',
          writer='$writer',
          source='$source',
          reader='$reader',
          litpic='$litpic',
          pubdate='$pubdate',
          description='$description',
          keywords=

          3.0 不换行 
          N3.0 储存格背景颜色 
          3.0 储存格横向连接 
          3.0 储存格纵向连接 
          N1.1 储存格宽度           		 （以pixels为单位）
          N1.1 储存格宽度比率           		 （页宽为100%）
          3.0 表格标题           		一样，不过会对中并加粗）
          3.0 表格标题对齐 
          3.0 表格标题不换行 
          3.0 表格标题占几栏 
          3.0 表格标题占几列 
          N1.1 表格标题宽度           		 （以pixels为单位）
          N1.1 表格标题比率宽度          		 （页宽为100%）
          3.0 表格抬头 
          （在表格之上/之下）
          视框 （定义与控制萤幕上的特定区域）
          N2.0 视框格式总定义  （取代）
          N2.0 视框行长度分配 （pixels 或 %）
          N2.0 视框行长度分配  （* = 相对大小）
          N2.0 视框栏宽度分配 （pixels 或 %）
          N2.0 视框栏宽度分配  （* =相对大小）
          N2.0 定义个别视框  （定义个别视框）
          N2.0 个别视框内容 
          N2.0 个别视框名称 
          N2.0 边缘宽度  （「左」与「右」边界）
          N2.0 边缘高度  （「天顶」与「地底」边界）
          N2.0 卷动条 
          N2.0 不可改变大小 
          N2.0 无视框时的内容 （如果浏览器不提供视框功能的话）
          7.杂项
          说明  （浏览器不会显示） 


          转载出处不详
          Tags -  ,  ,  ,  , 
]]>


http://www.zhanghongbiao.com/post/809/
<![CDATA[dedecms系统伪静态]]> 
mlzy <mlzy@live.com>

Fri, 05 Sep 2008 01:55:38 +0000 
http://www.zhanghongbiao.com/post/809/ 

2、修改数据库将所有文档设置为“仅动态”，可以进入数据库管理中，执行下面命令： update dede_archives set ismake=2 并将ismake的默认值设置为 2即伪静态。将所有栏目设置为“使用动态页”，可以进入数据库管理中，执行下面命令： update dede_arctype set isdefault=-1 并将isdefault的默认值设置为 -1即动态。
          3、加入服务器重写规则，在根目录新建一个.htaccess

              php_value session.use_trans_sid 0

          RewriteEngine On
          RewriteCond %{REQUEST_FILENAME} -f
          RewriteRule ^(.*) $1 [L]
          RewriteCond %{REQUEST_FILENAME} !-d
          RewriteRule ^(.+)/([0-9]+).html$ plus/view.php?aid=$2 [L]
          RewriteCond %{REQUEST_FILENAME} !-d
          RewriteRule ^(.+)/([0-9]+)_([0-9]+).html$ plus/view.php?aid=$2&pageno=$3 [L]
          RewriteCond %{REQUEST_FILENAME} !-d
          RewriteRule ^(.+)/list_([0-9]+)_([0-9]+).html$ plus/list.php?typeid=$2&PageNo=$3 [L]
          RewriteCond %{REQUEST_FILENAME} !-d
          RewriteRule ^(.+)/list_([0-9]+).html$ plus/list.php?typeid=$2 [L]
          4、调整完毕后到DEDE后台管理程序中，更新一下首页，完成。
          Tags -  ,  ,  , 
]]>
          
          
http://www.zhanghongbiao.com/post/808/
<![CDATA[中搜完了]]> 
mlzy <mlzy@live.com>

Thu, 04 Sep 2008 14:15:07 +0000 
http://www.zhanghongbiao.com/post/808/ 


          仔细的看了它的社区人气——几乎没人了。。

          这种情况下，两年内再没新项目，新想法，就要完蛋了。
          Tags -  , 
]]>
          
          
http://www.zhanghongbiao.com/post/807/
<![CDATA[DedeCms的SEO技巧之URL篇]]> 
mlzy <mlzy@live.com>

Thu, 04 Sep 2008 14:00:03 +0000 
http://www.zhanghongbiao.com/post/807/ 


          所谓SEO技巧，这里要说的不是<MATE>标签之类的，是URL，不知道大家是否留意过这个。 DEDECMS，提供了几种生成URL的方法，把它叫做“文章命名规则”，有这几种：{Y}、{M}、{D},{timestamp},{aid},{pinyin}, {py},{typedir},{cc}这几种，大家常用哪些呢？在DEDECMS的论坛上，看见有人寻问用{pinyin}的方法，如何去掉文章的 ID，一直没有人回复，也不知道那位兄弟解决了没，但是这里有更好的方法命名后的地址如：http: //www.xxx.com/xxx/dkofkvom.html，类似这种随机数的样子，并且去掉了\"-""_"之类的字符，想知道吗，打开DW，与我一起动手改吧！<br/><br/>首先打开，include\inc_channel_unit_functions.php，在56行左右，$articleRule = str_replace("{py}",GetPinyin($title,1)."_".$aid,$articleRule);改成$ articleRule = str_replace("{py}",GetPinyin($title,1),$articleRule);也就是去掉."_".$aid.<br/><br/>然后在include\inc\inc_fun_funAdmin.php中，把第一个函数function SpGetPinyin($str,$ishead=0,$isclose=1)下面的FOR循环修改为如下：<br/><br/><div class="code"><br/>  for($i=0;$i<24;$i++){<br/>    if(ord($str[$i])>0x80)<br/>    {<br/>        $c = $str[$i].$str[$i+1];<br/>        $i++;<br/>        if(isset($pinyins[$c])){<br/>          if($ishead==0) $restr .= $pinyins[$c];<br/>          else $restr .= $pinyins[$c][0];<br/>        }else $restr .= "";<br/>    }else if( eregi("[a-z]",$str[$i]) ){   $restr .= $str[$i]; }<br/>    else{ $restr .= ""; }<br/>  }<br/><br/></div><br/><br/>这两部都做完之后，把“文章命名规则”写为{typedir}/{py}.html，测试一下你的文章URL吧！是不是很SEO。<br/>Tags - <a href="http://www.zhanghongbiao.com/tags/%25E8%25BD%25AC%25E8%25BD%25BD/" rel="tag">转载</a> , <a href="http://www.zhanghongbiao.com/tags/%25E7%25BD%2591%25E7%25BB%259C/" rel="tag">网络</a> , <a href="http://www.zhanghongbiao.com/tags/%25E6%258A%2580%25E6%259C%25AF/" rel="tag">技术</a> , <a href="http://www.zhanghongbiao.com/tags/dedecms/" rel="tag">dedecms</a>
]]>
</description>
</item><item>
<link>http://www.zhanghongbiao.com/post/806/</link>
<title><![CDATA[RegexBuddy——一款帮你写正则表达式的软件]]> 
mlzy <mlzy@live.com>

Thu, 04 Sep 2008 11:15:06 +0000 
http://www.zhanghongbiao.com/post/806/ 


          下载地址：http://www.onlinedown.net/soft/56808.htm#
          Tags -  ,  ,  , 
]]>
          
          
http://www.zhanghongbiao.com/post/805/
<![CDATA[dede生成静态页和动态页转换]]> 
mlzy <mlzy@live.com>

Thu, 04 Sep 2008 08:16:43 +0000 
http://www.zhanghongbiao.com/post/805/ 


          1.如何修改默认发布为动态页；[有人成功了，我似乎无效]
          这个其实很简单，会改html就可以了！把dede/templates文件夹打开，用编辑器打开article_add.html，找到

          <td width=”90″>发布选项：</td>
                     <td> <input name=”ishtml” type=”radio” class=”np” value=”1″ checked="checked">
                       生成HTML  
                       <input name=”ishtml” type=”radio” class=”np” value=”0″>
                       仅动态浏览</td>

          修改为：          

          <td width=”90″>发布选项：</td>
                     <td> <input name=”ishtml” type=”radio” class=”np” value=”1″>
                       生成HTML  
                       <input name=”ishtml” type=”radio” class=”np” value=”0″ checked="checked">
                       仅动态浏览</td>

          刷新一下发布文章页面看看可以了不！用DW可以很直观的修改。

          2.如何批量修改动态发布为静态生成，或者反过来修改。
          用phpmyadmin打开dede_dede_archives 这个表
          ismake这个字段就是我们要修改的对象。
          运行sql语句：

          UPDATE  dede_archives SET  ismake = ‘-1′  修改所有文档为动态浏览

          UPDATE  dede_archives SET  ismake = ‘1′   修改所有文档为静态发布
          这样就可以了
          Tags -  ,  , 
]]>
          
          
http://www.zhanghongbiao.com/post/804/
<![CDATA[女教师课上教学生别网聊 课后见网友被强暴]]> 
mlzy <mlzy@live.com>

Thu, 04 Sep 2008 07:57:55 +0000 
http://www.zhanghongbiao.com/post/804/ 


          　　女教师夏某上网时认识了自称大学生的朱某，聊天中，朱某得知夏老师爱好文学，便投其所好，经常写诗送给对方。一段时间下来，夏老师对朱某颇有好感，两人成了网上的爱侣，每天在QQ上与朱某聊天，也成了她生活的必需和唯一的精神寄托。

          　　终于有一天，朱某到无锡入住一家酒店，提出要与夏老师见面。夏老师考虑了一番后前往赴约，没想到彬彬有礼的“大学生”朱某露出了本来面目，利用夏老师要面子，怕隐私被人知道的心理进行威胁，强迫与其发生了性关系。直到5天后，夏老师才下决心报案。法院审理后，以强奸罪判处朱某有期徒刑四年六个月。

          　　让承办法官感到不可理解的是，一个有着多年思想政治教育经验，经常在讲台上告诫学生们提防网络不良影响的老师，竟然没能教会自己。

          　　据介绍，从2005年至今，无锡市北塘区法院受理的因网聊引发的性犯罪案件数量呈不断上升趋势，受害女性中近一半都面临着生活或工作压力大，缺少和朋友、家人沟通的问题。

          　　北塘区法院刑庭的法官提出了对策：女性对于网友要提高警惕，洁身自好，与网友见面尽量选择公共场合，不给犯罪分子提供任何机会。

          Tags -  ,  , 
]]>
          
          
http://www.zhanghongbiao.com/post/803/
<![CDATA[开源网络爬虫程序(spider)一览 ]]> 
mlzy <mlzy@live.com>

Thu, 04 Sep 2008 04:20:23 +0000 
http://www.zhanghongbiao.com/post/803/ 


          spider是搜索引擎的必须模块.spider数据的结果直接影响到搜索引擎的评价指标.

          第一个spider程序由MIT的Matthew K Gray操刀该程序的目的是为了统计互联网中主机的数目

          Spier定义(关于Spider的定义,有广义和狭义两种).

          狭义:利用标准的http协议根据超链和web文档检索的方法遍历万维网信息空间的软件程序.
          广义:所有能利用http协议检索web文档的软件都称之为spider.
          其中Protocol Gives Sites Way To Keep Out The ′Bots Jeremy Carl, Web Week, Volume 1, Issue 7, November 1995 是和spider息息相关的协议,大家有兴趣参考robotstxt.org.

          Heritrix

          Heritrix is the Internet Archive′s open-source, extensible, web-scale, archival-quality web crawler project.

          Heritrix (sometimes spelled heretrix, or misspelled or missaid as heratrix/heritix/ heretix/heratix) is an archaic word for heiress (woman who inherits). Since our crawler seeks to collect and preserve the digital artifacts of our culture for the benefit of future researchers and generations, this name seemed apt.

          语言:JAVA

          WebLech URL Spider

          WebLech is a fully featured web site download/mirror tool in Java, which supports many features required to download websites and emulate standard web-browser behaviour as much as possible. WebLech is multithreaded and comes with a GUI console.

          语言:JAVA

          JSpider

          A Java implementation of a flexible and extensible web spider engine. Optional modules allow functionality to be added (searching dead links, testing the performance and scalability of a site, creating a sitemap, etc ..

          语言:JAVA

          WebSPHINX

          WebSPHINX is a web crawler (robot, spider) Java class library, originally developed by Robert Miller of Carnegie Mellon University. Multithreaded, tollerant HTML parsing, URL filtering and page classification, pattern matching, mirroring, and more

          语言:JAVA

          PySolitaire

          PySolitaire is a fork of PySol Solitaire that runs correctly on Windows and has a nice clean installer. PySolitaire (Python Solitaire) is a collection of more than 300 solitaire and Mahjongg games like Klondike and Spider.

          语言:Python

          The Spider Web Network Xoops Mod Team

          The Spider Web Network Xoops Module Team provides modules for the Xoops community written in the PHP coding language. We develop mods and or take existing php script and port it into the Xoops format. High quality mods is our goal.

          语言:php

          Fetchgals

          A multi-threaded web spider that finds free porn thumbnail galleries by visiting a list of known TGPs (Thumbnail Gallery Posts). It optionally downloads the located pictures and movies. TGP list is included. Public domain perl script running on Linux.

          语言:perl

          Where Spider

          The purpose of the Where Spider software is to provide a database system for storing URL addresses. The software is used for both ripping links and browsing them offline. The software uses a pure XML database which is easy to export and import.

          语言:XML

          Sperowider

          Sperowider Website Archiving Suite is a set of Java applications, the primary purpose of which is to spider dynamic websites, and to create static distributable archives with a full text search index usable by an associated Java applet.

          语言:Java

          SpiderPy

          SpiderPy is a web crawling spider program written in Python that allows users to collect files and search web sites through a configurable interface.

          语言:Python

          Spidered Data Retrieval

          Spider is a complete standalone Java application designed to easily integrate varied datasources. * XML driven framework * Scheduled pulling * Highly extensible * Provides hooks for custom post-processing and configuration

          语言:Java

          webloupe

          WebLoupe is a java-based tool for analysis, interactive visualization (sitemap), and exploration of the information architecture and specific properties of local or publicly accessible websites. Based on web spider (or web crawler) technology.

          语言:java

          ASpider

          Robust featureful multi-threaded CLI web spider using apache commons httpclient v3.0 written in java. ASpider downloads any files matching your given mime-types from a website. Tries to reg.exp. match emails by default, logging all results using log4j.

          语言:java

          larbin

          Larbin is an HTTP Web crawler with an easy interface that runs under Linux. It can fetch more than 5 million pages a day on a standard PC (with a good network).

          语言:C++
          Tags -  ,  ,  ,  ,  , 
]]>
          
          
http://www.zhanghongbiao.com/post/802/
<![CDATA[How To Ask Questions the Smart Way]]> 
mlzy <mlzy@live.com>

Thu, 04 Sep 2008 03:38:45 +0000 
http://www.zhanghongbiao.com/post/802/ 

This is the original source of the blog"提问的智慧" --- while which I though is. 

          ---------------Article Start--------------------

          Disclaimer

          Many project Web sites link to this document in their sections on how to get help. That's fine, it's the use we intended — but, if you're a webmaster creating such a link for your project page, please display prominently near the link a notice that we are not your project's help desk!

          We've learned the hard way that, without such a notice, we will repeatedly be pestered by idiots who think having published this document makes it our job to solve all the world's technical problems.

          If you're reading this document because you need help, and you walk away with the impression you can get it directly from the authors, you are one of those idiots. Don't ask us questions: We'll just ignore you. We're here to show you how to get help from people who actually know about the software or hardware you're dealing with — but, 99% of the time, that will not be us. Unless you're certain one of the authors is expert in what you're dealing with, leave us alone and everybody will be happier.
          Introduction

          In the world of hackers, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer. This guide will teach you how to ask questions in a way more likely to get you a satisfactory answer.

          Now that use of open source has become widespread, you can often get as good answers from other, more experienced users as from hackers. This is a Good Thing; users tend to be just a little bit more tolerant of the kind of failures new users often have. Still, treating experienced users like hackers, in the ways we recommend here, will generally be the most effective way to get useful answers out of them, too.

          The first thing to understand is that hackers actually like hard problems, and good, thought-provoking questions about them. If we didn't, we wouldn't be here. If you give us an interesting question to chew on, we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have noticed or thought about otherwise. Among hackers, "Good question!" is a strong and sincere compliment.

          Despite this, hackers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to new users and the ignorant. However, this isn't really true.

          What we are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions. People like that are time sinks: They take without giving back, and they waste time we could have spent on another question more interesting and another person more worthy of an answer. We call people like this "losers" (and, for historical reasons, sometimes spell it "lusers").

          We realise there are many people who just want to use the software we write, who have no interest in learning technical details. For most people, a computer is merely a tool, a means to an end; they have more important things to do and lives to live. We acknowledge that, and don't expect everyone to take an interest in the technical matters that fascinate us. Nevertheless, our style of answering questions is tuned for people who do take such an interest and are willing to be active participants in problem-solving. That's not going to change. Nor should it; if it did, we would become less effective at the things we do best.

          We're (largely) volunteers. We take time out of busy lives to answer questions, and at times we're overwhelmed with them. So we filter, ruthlessly. In particular, we throw away questions from people who appear to be losers, in order to spend our question-answering time more efficiently, on winners.

          If you find this attitude obnoxious, condescending, or arrogant, check your assumptions. We're not asking you to genuflect to us — in fact, most of us would love nothing more than to deal with you as an equal, and welcome you into our culture, if you put in the effort required to make that possible. It's simply not efficient for us to try to help people who're not willing to help themselves. It's OK to be ignorant; it's not OK to play stupid.

          So, while it isn't necessary to already be technically competent, to get attention from us, it is necessary to demonstrate the kind of attitude that leads to competence — alert, thoughtful, observant, willing to be an active partner in developing a solution. If you can't live with this sort of discrimination, we suggest you pay somebody for a commercial support contract, instead of asking hackers to personally donate help to you.

          If you decide to come to us for help, you don't want to be one of the losers. You don't want to seem like one, either. The best way to get a rapid and responsive answer is to ask it like a person with smarts, confidence, and clues who just happens to need help on one particular problem.

          (Improvements to this guide are welcome. You can e-mail suggestions to esr@thyrsus.com or rick@linuxmafia.com. Note, however, that this document is not intended to be a general guide to netiquette, and we will generally reject suggestions not specifically related to eliciting useful answers in a technical forum.)
          Before You Ask

          Before asking a technical question by e-mail, or in a newsgroup, or on a Web site chat board, do the following:

             1.

                Try to find an answer by searching the Web.
             2.

                Try to find an answer by reading the manual.
             3.

                Try to find an answer by reading a FAQ.
             4.

                Try to find an answer by inspection or experimentation.
             5.

                Try to find an answer by asking a skilled friend.
             6.

                If you're a programmer, try to find an answer by reading the source code.

          When you ask your question, mention having done these things first; this will help establish that you're not being a lazy sponge and wasting people's time. Better yet, display what you've learned from doing these things. We like answering questions for people who've demonstrated they can learn from the answers.

          Use tactics like doing a Google search on the text of your error message (searching Google Groups, as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn't, saying "I googled on the following phrase but didn't get anything promising" is a good thing to include in e-mail or news posting requesting help.

          Take your time. Do not expect to be able to solve a complicated problem with a few seconds of Googling. Read and understand the FAQs, sit back, relax, and give the problem some thought before approaching experts. Trust us, they will be able to tell from your questions how much reading and thinking you did, and will be more willing to help if you come prepared. Don't instantly fire your whole arsenal of questions, just because your first search turned up no answers (or too many).

          Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.

          Beware of asking the wrong question. If you ask one that is based on faulty assumptions, J. Random Hacker is quite likely to reply with a uselessly literal answer, while thinking "Stupid question...", and hoping the experience of getting what you asked for, rather than what you needed, will teach you a lesson.

          Never assume you're entitled to an answer. You're not; you aren't, after all, paying for the service. You will earn an answer, if you earn it, by asking a substantial, interesting, and thought-provoking question — implicitly contributing to the experience of the community, rather than merely passively demanding knowledge from others.

          On the other hand, making clear your ability and willingness to help the solution-development process is a very good start. "Would someone provide a pointer?", "What is my example missing?", and "What site should I have checked?" are more likely to get answered than "Please post the exact procedure I should use", because you're stressing genuine willingness to complete the process, if someone can just point you in the right direction.
          When You Ask
          Choose your forum carefully

          Be sensitive in choosing where you ask your question. You're likely to be ignored, or written off as a loser, if you:

              *

                post your question to a forum where it's off topic
              *

                post a very elementary question to a forum where advanced technical questions are expected, or vice-versa
              *

                cross-post to too many different newsgroups
              *

                post a personal e-mail to somebody who is neither a personal acquaintance nor personally responsible for solving your problem

          Hackers blow off inappropriately targeted questions, in order to try to protect their communications channels from being drowned in irrelevance. You don't want this to happen to you.

          The first step, therefore, is to find the right forum. Again, Google and other Web-searching methods are your friend. Use them to find the project Web page most closely associated with the hardware or software giving you difficulties. Usually, it will have links to a FAQ (Frequently Asked Questions) list, and to project mailing lists and their archives. These mailing lists are the final places to go for help, if your own efforts (including reading those FAQs you found) don't find you a solution. The project page may also describe a bug-reporting procedure, or have a link to one; if so, follow it.

          Shooting off an e-mail to a person or forum you're unfamiliar with is risky at best. For example, don't assume the author of an informative Web page wants to be your free consultant. Don't make optimistic guesses about whether your question will be welcome: If you're unsure, send it elsewhere, or refrain from sending it at all.

          When selecting a Web forum, newsgroup, or mailing list, don't trust the name by itself too far; look for a FAQ or charter to verify your question being on-topic. Read some of the back traffic, before posting, so you'll get a feel for how things are done, there. In fact, do a keyword search for words relating to your problem, on the newsgroup or mailing list archives, before you post. It may find you an answer, and, if not, it will help you formulate a better question.

          Don't shotgun-blast all available help channels at once; that's like yelling, and irritates people. Step through them.

          Know what your topic is! One of the classic mistakes is asking questions about the Unix or Windows programming interface in a forum devoted to a language or library or tool portable across both. If you don't understand why this is a blunder, you'd be best off not asking any questions at all, until you get it.

          In general, questions to a well-selected public forum are more likely to get useful answers than are equivalent questions to a private one. There are multiple reasons: One is simply the size of the pool of potential respondents. Another is the size of the audience; hackers would rather answer questions that educate many people than questions serving only a few.

          Understandably, skilled hackers and authors of popular software are already receiving more than their fair share of mis-targeted messages. By adding to the flood, you could in extreme cases even be the straw that breaks the camel's back — quite a few times, contributors to popular projects have withdrawn their support because collateral damage in the form of useless e-mail traffic to their personal accounts became unbearable.
          Web and IRC forums directed towards new users often give the quickest response

          Your local user group, or your Linux distribution, may advertise a Web forum or IRC channel where new users can get help. (In non-English-speaking countries, new-user forums are still more likely to be mailing lists.) These are good first places, to ask, especially if you think you may have tripped over a relatively simple or common problem. An advertised IRC channel is an open invitation to ask questions there, and often get answers in real time.

          In fact, if you got the program that is giving you problems from a Linux distribution (as common today), it may be better to ask in the distro's forum/list before trying the program's project forum/list. The project's hackers may just say, use our build.

          Before posting to any Web forum, check if it has a Search feature. If it does, try a couple of keyword searches for something like your problem; it just might help. If you did a general Web search before (as you should have), search the forum anyway; your Web-wide search engine might not have all of this forum indexed recently.

          There is an increasing tendency for projects to do user support over a Web forum or IRC channel, with e-mail reserved more for development traffic. So, look for those channels first, when seeking project-specific help.
          As a second step, use project mailing lists

          When a project has a development mailing list, write to the mailing list, not to individual developers, even if you believe you know who can best answer your question. Check the documentation of the project and its homepage for the address of a project mailing list, and use it. There are several good reasons for this policy:

              *

                Any question good enough to be asked of one developer will also be of value to the whole group. Contrariwise, if you suspect your question is too dumb for a mailing list, it's not an excuse to harass individual developers.
              *

                Asking questions on the list distributes load between developers. Individual developers (especially the project leader) may be too busy to answer your questions.
              *

                Most mailing lists are archived, and the archives are indexed by search engines. Somebody could find your question and the answer on the Web, instead of asking it again in the list.
              *

                If certain questions are seen being asked often, developers can use that information to improve the documentation or the software itself, to be less confusing. If those questions are asked in private, nobody has a complete picture of what questions are asked most often.

          If a project has both a "user" and a "developer" (or "hacker") mailing list or Web forum, and you're not hacking on the code, ask in the "user" list/forum. Don't assume you will be welcome on the developer list, where they're likely to experience your question as noise disrupting their developer traffic.

          However, if you're sure your question is non-trivial, and you get no answer in the "user" list/forum for several days, try the "developer" one. You would be well advised to lurk there for a few days, before posting, to learn the local folkways. (Actually, this is good advice on any private or semi-private list.)

          If you can't find a project's mailing list address, but see only the project maintainer's address, go ahead and e-mail the maintainer. However, even in that case, don't assume the mailing list doesn't exist. Mention in your e-mail your unfruitful attempt to find an appropriate mailing list. Also mention that you don't object to having your message forwarded to other people. (Many people think private e-mail should remain private, even if nothing in it is secret. By allowing forwarding, you give correspondents a choice in handling your mail.)
          Use meaningful, specific subject headers

          On mailing lists, newsgroups, or Web forums, the subject header is your golden opportunity to attract qualified experts' attention, in around 50 characters or fewer. Don't waste it on babble like "Please help me" (let alone "PLEASE HELP ME!!!!"; messages with such subjects get discarded, by reflex). Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description, instead.

          One good convention for subject headers, used by many tech support organizations, is "object - deviation". The "object" part specifies what thing, or group of things, is having a problem. The "deviation" part describes observed deviation from expected behaviour.

          Stupid:

              HELP! Video doesn't work properly on my laptop!
          Smart:

              X.org 6.8.1 misshapen mouse cursor, Fooware MV1005 vid. chipset
          Smarter:

              X.org 6.8.1 mouse cursor on Fooware MV1005 vid. chipset - is misshapen

          The process of writing an "object-deviation" description will help you organise your thinking about the problem in more detail. What is affected? Just the mouse cursor, or other graphics, too? Is this specific to the X.org version of X? To version 6.8.1? Is this specific to Fooware video chipsets? To model MV1005? A hacker who sees the result can immediately understand what you're having a problem with and the problem you're having, at a glance.

          If you ask a question in a reply, be sure to change the subject line to indicate you're asking a question. A Subject line resembling "Re: test" or "Re: new bug" is less likely to attract useful amounts of attention. Also, pare quotations of previous messages, to the minimum consistent with cluing in new readers.

          Don't simply hit Reply on an existing list message, to start an entirely new thread: This will limit your audience. Some e-mail readers, like mutt, allow the user to sort by thread, and then hide messages in a thread by folding the thread. Such users will never see your message.

          Changing the subject isn't sufficient. Mutt, and probably other e-mail readers, looks at other information in the e-mail's headers to assign it to a thread, not the subject line. Instead, start an entirely new e-mail.

          On Web forums, the rules of good practice are slightly different, because messages are usually much more tightly bound to specific discussion threads, and often invisible outside those threads. Changing the subject when asking a question in reply is not essential. Not all forums even allow separate subject lines on replies, and nearly nobody reads them when they do. However, asking a question in a reply is a dubious practice in itself, because it will be seen only by those who're watching this thread. So, unless you're sure you want to ask the people currently active in the thread, start a new one.
          Make it easy to reply

          Finishing your query with "Please send your reply to..." makes it quite unlikely you'll get an answer. If you can't be bothered taking even the few seconds required to set up a correct Reply-To header in your e-mail agent, we can't be bothered to take even a few seconds to think about your problem. If your e-mail program doesn't permit this, get a better e-mail program. If your operating system doesn't support any e-mail programs permitting this, get a better operating system.

          In Web forums, asking for a reply by e-mail is outright rude, unless you believe the information may be sensitive (and somebody will, for some unknown reason, let you but not the whole forum know it). If you want an e-mail copy when somebody replies in the thread, request that the Web forum send it; this feature is supported almost everywhere, under options like watch this thread, send e-mail on answers, etc.
          Write in clear, grammatical, correctly-spelled language

          We've found by experience that careless, sloppy writers are usually also careless, sloppy thinkers and coders (often enough to bet on, anyway). Answering questions for careless, sloppy thinkers is not rewarding; we'd rather spend our time elsewhere.

          So, expressing your question clearly and well is important. If you can't be bothered to do that, we can't be bothered to pay attention. Spend the extra effort to polish your language. It doesn't have to be stiff or formal — in fact, hacker culture values informal, slangy, and humorous language used with precision. However, it has to be precise; there has to be some indication that you're thinking and paying attention.

          Spell, punctuate, and capitalise correctly. Don't confuse "its" with "it's", "loose" with "lose", or "discrete" with "discreet". Don't TYPE IN ALL CAPS; this is read as shouting, and considered rude. (All-smalls is only slightly less annoying, as it's difficult to read. Alan Cox can get away with it; you can't.)

          More generally, if you write like a semi-literate boob, you'll very likely be ignored. Writing like a l33t script kiddie hax0r is the absolute kiss of death, and guarantees you'll receive nothing but stony silence (or, at best, a heaping helping of scorn and sarcasm), in return.

          If you're asking questions in a forum not in your native language, you'll get a limited amount of slack for spelling and grammar errors — but no extra slack at all for laziness (and yes, we can usually spot the difference). Also, unless you know what your respondent's languages are, write in English. Busy hackers tend to simply flush questions in languages they don't understand, and English is the Internet's working language. By writing in English, you minimise the chance of your question being discarded unread.
          Send questions in accessible, standard formats

          If you make your question artificially hard to read, it's more likely to be passed over in favor of one that isn't. So:

              *

                Send plain text e-mail, not HTML. (It's not hard to turn off HTML.)
              *

                MIME attachments are usually OK, but only if they're real content (such as an attached source file or patch), and not merely boilerplate generated by your e-mail client (such as another copy of your message).
              *

                Don't send e-mail in which entire paragraphs are single multiply-wrapped lines. (This makes it too difficult to reply to just part of the message.) Assume your respondents will be reading e-mail on 80-character-wide text displays, and set your line wrap accordingly, to something less than 80.
              *

                However, do not wrap data (such as log file dumps or session transcripts) at any fixed column width. Data should be included as-is, so respondents can have confidence they're seeing what you saw.
              *

                Don't send MIME Quoted-Printable encoding to an English-language forum. This encoding can be necessary when posting in a language ASCII doesn't cover, but many e-mail agents don't support it. When they break, all those =20 glyphs scattered through the text are ugly and distracting — or may actively sabotage the semantics of your text.
              *

                Never, ever expect hackers to be able to read closed proprietary document formats like Microsoft Word or Excel. Most hackers react to these about as well as you would to having a pile of steaming pig manure dumped on your doorstep. Even when they can cope, they resent having to do so.
              *

                If you're sending e-mail from a Windows machine, turn off Microsoft's stupid "Smart Quotes" feature. This is so you'll avoid sprinkling garbage characters through your e-mail.
              *

                In Web forums, do not abuse smiley and HTML features (when they're present). A smiley or two is usually OK, but coloured fancy text tends to make people think you're lame. Seriously overusing smileys and colour and fonts will make you come off like a giggly teenage girl, which is not generally a good idea unless you're more interested in sex than in answers.

          If you're using a graphical-user-interface e-mail client, (such as Netscape Messenger, MS Outlook, or their ilk), beware that it may violate these rules when used with its default settings. Most such clients have a menu-based "View Source" command. Use this on something in your sent-mail folder, verifying sending of plain text without unnecessary attached crud.
          Be precise and informative about your problem

              *

                Describe the symptoms of your problem or bug carefully and clearly.
              *

                Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor's distribution and release level (e.g.: "Fedora Core 2", "Slackware 9.1" etc.).
              *

                Describe the research you did to try and understand the problem before you asked the question.
              *

                Describe the diagnostic steps you took to try and pin down the problem yourself, before you asked the question.
              *

                Describe any possibly relevant recent changes to your computer or software configuration.

          Do the best you can to anticipate the questions a hacker will ask, and answer them in advance in your request for help.

          Simon Tatham has written an excellent essay entitled How to Report Bugs Effectively. I strongly recommend you read it.
          Volume is not precision

          You need to be precise and informative. This end is not served by simply dumping huge volumes of code or data into a help request. If you have a large, complicated test case that breaks a program, try to trim it and make it as small as possible.

          This is useful for at least three reasons. One: Being seen to invest effort in simplifying the question makes it more likely you'll get an answer, Two: Simplifying the question makes it more likely you'll get a useful answer. Three: In the process of refining your bug report, you may develop a fix or workaround, yourself.
          Don't claim you've found a bug

          When you're having problems with a piece of software, don't claim you've found a bug, unless you're very, very sure of your ground. Hint: Unless you can provide a source-code patch fixing the problem, or a regression test against a previous version that demonstrates incorrect behaviour, you're probably not sure enough. This applies to Web pages and documentation, too; if you've found a documentation bug, you should supply replacement text and a note as to which pages it should go on.

          Remember, many other users aren't experiencing your problem. Otherwise, you would have learned about it while reading the documentation and searching the Web. (You did do that before complaining, didn't you?) This means that very probably it's you who're doing something wrong, not the software.

          The people who wrote the software work very hard to make it work as well as possible. If you claim you've found a bug, you'll be implying they did something wrong, and will almost always offend them — even if you're correct. It's especially undiplomatic to yell "bug" in the Subject line.

          When asking your question, write as though you assume you're doing something wrong, even if you're privately pretty sure you've found an actual bug. If there really is a bug, you'll hear about it in the answer. Play it so the maintainers will want to apologise to you if the bug is real, rather than so you'll owe them an apology if you've messed up.
          Grovelling is no substitute for doing your homework

          Some people who get that they shouldn't behave rudely or arrogantly, demanding an answer, retreat to the opposite extreme, of grovelling. ("I know I'm just a pathetic new user, but...".) This is distracting, and unhelpful. It's especially annoying when it's coupled with vagueness about the actual problem.

          Don't waste your time, or ours, on crude primate politics. Instead, present the background facts and your question as clearly as you can. That is a better way to position yourself than by grovelling.

          Sometimes, Web forums have separate places for new-user questions. If you feel you do have a new-user question, just go there. However, don't grovel there, either.
          Describe the problem's symptoms, not your guesses

          It's not useful to tell hackers what you think is causing your problem. (If your diagnostic theories were such hot stuff, would you be consulting others for help?) So, make sure you're telling them the raw symptoms of what goes wrong, rather than your interpretations and theories. Let them do the interpretation and diagnosis.

          Stupid:

              I'm getting back-to-back SIG11 errors on kernel compiles, and suspect a hairline crack on one of the motherboard traces. What's the best way to check for those?
          Smart:

              My home-built K6/233 on an FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB Corsair PC133 SDRAM starts getting frequent SIG11 errors about 20 minutes after power-on during kernel compiles, but never in the first 20 minutes. Rebooting doesn't restart the clock; powering down overnight does. Swapping out all RAM didn't help. The relevant part of a typical compile session log follows.

          Since the preceding point seems to be a tough one for many people to grasp, here's a phrase to remind you: "All diagnosticians are from Missouri." That US state's official motto is "Show me" (earned in 1899, when Congressman Willard D. Vandiver said "I come from a country that raises corn and cotton and cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I'm from Missouri. You've got to show me.") In diagnosticians' case, it's not a matter of skepticism, but rather a literal, functional need to see whatever is as close as possible to the same raw evidence that you see, rather than your surmises and summaries. Show us.
          Describe your problem's symptoms in chronological order

          The clues most useful in figuring out something that went wrong often lie in the events immediately prior. So, your account should describe precisely what you did, and what the machine did, leading up to the blowup. In the case of command-line processes, having a session log (e.g., using the script utility) and quoting the relevant twenty or so lines is very useful.

          If the program that blew up on you has diagnostic options (such as -v for verbose), check for options useful in adding debugging information to the transcript.

          If your account ends up being long (more than about four paragraphs), it might be useful to succinctly state the problem up top, and then follow with the chronological tale. That way, hackers will know what to watch for, in reading your account.
          Describe the goal, not the step

          If you're trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then, describe the particular step towards it, on which you're blocked.

          Often, people seeking technical help have a high-level goal in mind, and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realise the path is wrong. It can take substantial effort to get past this.

          Stupid:

              How do I get the color-picker on the FooDraw program to take a hexadecimal RGB value?
          Smart:

              I'm trying to replace the color table on an image with values of my choosing. Right now, the only way I can see to do this is by editing each table slot, but I can't get FooDraw's color picker to take a hexadecimal RGB value.

          The second version if the question is smart. It allows answers suggesting tools better suited to the task.
          Don't ask people to reply by private e-mail

          Hackers believe solving problems should be a public, transparent process, during which the first try at an answer can and should be corrected, if someone more knowledgeable notices incomplete or incorrect data. Also, helpers get some of their reward for being respondents from being seen to be competent and knowledgeable by their peers.

          When you ask for a private reply, you're disrupting both the process and the reward. Don't do this. It's the respondent's choice whether to reply privately — and, if he or she does, it's usually because he/she thinks the question is too ill-formed or obvious to be interesting to others.

          There is one limited exception to this rule. If you think the question may attract a number of similar answers, then the magic words are "e-mail me and I'll summarise answers for the group". It is courteous to try and save the mailing list or newsgroup a flood of substantially identical postings — but you must keep the promise to summarise.
          Be explicit about your question

          Open-ended questions tend to be perceived as open-ended time sinks. Those people most likely to be able to give useful answers are also the busiest (if only because they take on the most work themselves). People like that are allergic to open-ended time sinks; thus, they tend to be allergic to open-ended questions.

          You're more likely to get a useful response if you're explicit about what you want respondents to do (provide pointers, send code, check your patch, whatever). This will focus their effort, and implicitly put an upper bound on the time and energy a respondent must allocate for helping you. This is good.

          To understand the world experts live in, think of expertise as an abundant resource, and time to respond as a scarce one. The less time commitment you implicitly request, the more likely you are to get an answer from someone really good and really busy.

          So, it's useful to frame your question to minimise the time commitment required for an expert to field it — but this is often not the same thing as simplifying the question. Thus, for example, "Would you give me a pointer to a good explanation of X?" is usually a smarter question than "Would you explain X, please?". If you have some malfunctioning code, it's usually smarter to ask what's wrong with it than to request someone to fix it.
          Don't post homework questions

          Hackers are good at spotting homework questions; most of us have done them ourselves. Those questions are for you to work out, so you'll learn from the experience. It is OK to ask for hints, but not for entire solutions.

          If you suspect you've been passed a homework question, but can't solve it anyway, try asking in a user group forum or (as a last resort) in a "user" list/forum of a project. While the hackers will spot it, some of the advanced users may at least give you a hint.
          Prune pointless queries

          Resist the temptation to close your request for help with semantically-null questions like "Can anyone help me?" or "Is there an answer?" First: If you've written your problem description halfway competently, such tacked-on questions are at best superfluous. Second: Because they are superfluous, hackers find them annoying — and are likely to return logically impeccable but dismissive answers like "Yes, you can be helped" and "No, there is no help for you."

          In general, asking yes-or-no questions is a good thing to avoid unless you want a yes-or-no answer.
          Don't flag your question as "Urgent", even if it is for you

          That's your problem, not ours. Claiming urgency is very likely to be counter-productive: Most hackers will simply delete such messages as rude and selfish attempts to elicit immediate and special attention.

          There is one semi-exception: It can be worth mentioning if you're using the program in some high-profile place, one hackers will get excited about; in such a case, if you're under time pressure, and you say so politely, people may get interested enough to answer faster.

          This is a very risky thing to do, however, because the hackers' metric for what is exciting probably differ from yours. Posting from the International Space Station would qualify, for example, but posting on behalf of a feel-good charitable or political cause would almost certainly not. In fact, posting "Urgent: Help me save the fuzzy baby seals!" will reliably get you shunned or flamed, even by hackers who think fuzzy baby seals are important.

          If you find this mysterious, re-read the rest of this HOWTO repeatedly, until you understand it, before posting anything at all.
          Courtesy never hurts, and sometimes helps

          Be courteous: Use "Please" and "Thanks for your attention" or "Thanks for your consideration". Make it clear you appreciate time spent helping you for free.

          To be honest, this isn't as important as (and cannot substitute for) being grammatical, clear, precise, and descriptive, avoiding proprietary formats, etc.; hackers in general would rather get somewhat brusque but technically sharp bug reports than polite vagueness. (If this puzzles you, remember that we value a question by what it teaches us.)

          However, if you have your technical ducks in a row, politeness does increase your chances of getting a useful answer.

          (We must note that the only serious objection we've received from veteran hackers to this HOWTO concerns our previous recommendation to use "Thanks in advance". Some hackers feel this connotes an intention not to thank anybody afterwards. Our recommendation is to either say "Thanks in advance" first and thank respondents afterwards, or express courtesy in a different way, such as by saying "Thanks for your attention" or "Thanks for your consideration".)
          Follow up with a brief note on the solution

          Send a note after the problem has been solved, to all who helped you: Let them know how it came out, and thank them again for their help. If the problem attracted general interest in a mailing list or newsgroup, it's appropriate to post the followup there.

          Optimally, the reply should be within the thread started by the original question post, and should have 'FIXED', 'RESOLVED', or an equally obvious tag in the subject line. On mailing lists with fast turnaround, a potential respondent who sees a thread about "Problem X" ending with "Problem X - FIXED" knows not to waste time even reading the thread (unless he/she personally finds Problem X interesting), and therefore can use that time solving a different problem.

          Your followup needn't be long and involved; a simple "Howdy — it was a failed network cable! Thanks, everyone. - Bill" would be better than nothing. In fact, a short and sweet summary is better than a long dissertation, unless the solution has real technical depth. Say what action solved the problem, but you need not replay the whole troubleshooting sequence.

          For problems with some depth, it's appropriate to post a summary of the troubleshooting history. Describe your final problem statement. Describe what worked as a solution, and indicate avoidable blind alleys. Name the names of people who helped you; you'll make friends that way.

          Besides being courteous and informative, this sort of followup will help others searching the mailing-list / newsgroup / forum archives to know exactly which solution helped you, and thus may also help them.

          Last, and not least, this sort of followup helps everybody who assisted feel a satisfying sense of closure, about the problem. If you aren't a techie or hacker, yourself, trust us: This feeling is very important to the gurus and experts you tapped for help. Problem narratives trailing off into unresolved nothingness are frustrating things; hackers itch to see them resolved. The goodwill scratching that itch earns you will be very, very helpful to you, next time you need to pose a question.

          Consider how you might be able to prevent others from having the same problem in the future. Ask yourself if a documentation or FAQ patch would help. If the answer is yes, send your patch to the maintainer.

          Among hackers, this sort of behaviour is actually more important than conventional politeness. It's how you get a reputation for playing well with others, which can be a very valuable asset.
          How To Interpret Answers
          RTFM and STFW: How To Tell You've Seriously Screwed Up

          There is an ancient and hallowed tradition: If you get a reply reading "RTFM", the person who sent it thinks you should have Read the Fucking Manual. He/she is almost certainly right. Go read it.

          RTFM has a younger relative. If you get a reply that reads "STFW", the person who sent it thinks you should have Searched the Fucking Web. He/she is almost certainly right. Go search it. (The milder version of this is when you're told Google is your friend!)

          In Web forums, you may also be advised to search the forum archives. In fact, someone may even be so kind as to provide a pointer to the previous thread, where this problem was solved. However, don't rely on this consideration; do your archive-searching before asking.

          Often, the person sending either of these replies has the manual or the Web page with the information you need open, and is looking at it, as he or she types. These replies mean your respondent thinks (a) the information you need is easy to find, and (b) you will learn more if you seek out the information than if it's spoon-fed to you.

          You shouldn't be offended by this; by hacker standards, he or she's showing you a rough kind of respect simply by not ignoring you. You should instead thank that person for grandmotherly kindness.
          If you don't understand...

          If you don't understand the answer, don't immediately bounce back a demand for clarification. Use the same tools you focussed on your original question (manuals, FAQs, the Web, skilled friends), to understand the answer. Then, if you still need to ask for clarification, exhibit what you've learned.

          For example, suppose I tell you: "It sounds like you've a stuck zentry; you'll need to clear it." Then: Here's a bad followup question: "What's a zentry?" Here's a good followup question: "OK, I read the man page; zentries are only mentioned under the -z and -p switches. Neither of them says anything about clearing zentries. Is it one of these, or am I missing something here?"
          Dealing with rudeness

          Much of what looks like rudeness in hacker circles is not intended to give offence. Rather, it's the product of the direct, cut-through-the-bullshit communications style natural to people who're more concerned about solving problems than about making others feel warm and fuzzy.

          When you perceive rudeness, try to react calmly. If someone really is acting out, very likely, a senior person on the list or newsgroup or forum will call him or her on it. If that doesn't happen, and you lose your temper, very likely the person you lose it against was behaving within hacker community norms, and you'll be considered at fault. This will hurt your chances of getting the information or help you want.

          On the other hand, you'll occasionally run across quite gratuitous rudeness and posturing. The flip-side of the above is that it's acceptable form to slam real offenders quite hard, dissecting their misbehaviour with a sharp verbal scalpel. Be very, very sure of your ground, before you try this, however. The line between correcting an incivility and starting a pointless flamewar is thin enough that hackers themselves not infrequently blunder across it; if you're a new user or outsider, your chances of avoiding such a blunder are low. If you're after information rather than entertainment, it's better to keep your fingers off the keyboard than risk this.

          (Some people assert that many hackers have a mild form of autism or Asperger's Syndrome, and are actually missing some of the brain circuitry lubricating 'normal' human social interaction. This may or may not be true. If you're not a hacker, yourself, it may help you cope with our eccentricities if you think of us as brain-damaged. Go right ahead. We won't care; we like being whatever we are, and generally have a healthy skepticism about clinical labels.)

          In the next section, we'll talk about a different issue; the kind of "rudeness" you'll see when you misbehave.
          On Not Reacting Like a Loser

          Odds are you'll screw up a few times, on hacker community forums — in ways detailed in this article, or similar. And you'll be told exactly how you screwed up, possibly with colourful asides. In public.

          When this happens, the worst thing you can do is whine about the experience, claim to have been verbally assaulted, demand apologies, scream, hold your breath, threaten lawsuits, complain to people's employers, leave the toilet seat up, etc. Instead, here's what you do:

          Get over it. It's normal. In fact, it's healthy and appropriate.

          Community standards do not maintain themselves: They're maintained by people actively applying them, visibly, in public. Don't whine that all criticism should have been conveyed via private e-mail: That's not how it works. Nor is it useful to insist you've been personally insulted when someone comments that one of your claims was wrong, or that his/her views differ. Those are loser attitudes.

          There have been hacker forums where, out of some misguided sense of hyper-courtesy, participants are banned from posting any fault-finding with another's posts, and told "Don't say anything if you're unwilling to help the user." The resulting departure of clueful participants to elsewhere causes them to descend into meaningless babble, and become useless as technical forums.

          Exaggeratedly "friendly" (in that fashion) or useful: Pick one.

          Remember: When that hacker tells you you've screwed up, and (no matter how gruffly) tells you not to do it again, he/she's acting out of concern for (1) you and (2) his/her community. It would be much easier for him/her to ignore you and filter you out of his/her life. If you can't manage to be grateful, at least have a little dignity; don't whine, and don't expect to be treated like a fragile doll just because you're a newcomer with a theatrically hypersensitive soul and delusions of entitlement.
          Questions Not to Ask

          Here are some classic stupid questions, and what hackers are thinking when they don't answer them.

          Q: Where can I find program or resource X?
          Q: How can I use X to do Y?
          Q: How can I configure my shell prompt?
          Q: Can I convert an AcmeCorp document into a TeX file using the Bass-o-matic file converter?
          Q: My {program, configuration, SQL statement} doesn't work
          Q: I'm having problems with my Windows machine. Can you help?
          Q: My program doesn't work. I think system facility X is broken.
          Q: I'm having problems installing Linux or X. Can you help?
          Q: How can I crack root/steal channel-ops privileges/read someone's e-mail?

          Q:   

          Where can I find program or resource X?
          A:   

          The same place I'd find it, fool — at the other end of a Web search. Ghod, doesn't everybody know how to use Google, yet?
          Q:   

          How can I use X to do Y?
          A:   

          If what you want is to do Y, you should ask that question without pre-supposing use of a method that may not be appropriate. Questions of this form often indicate a person not merely ignorant about X, but also confused about what problem Y they're solving and too fixated on the details of their particular situation. It is generally best to ignore such people, until they define their problems better.
          Q:   

          How can I configure my shell prompt?
          A:   

          If you're smart enough to ask this question, you're smart enough to RTFM and find out yourself.
          Q:   

          Can I convert an AcmeCorp document into a TeX file using the Bass-o-matic file converter?
          A:   

          Try it and see. If you did that, you'd (a) learn the answer, and (b) stop wasting my time.
          Q:   

          My {program, configuration, SQL statement} doesn't work
          A:   

          This isn't a question, and I'm not interested in playing Twenty Questions to pry your actual question out of you — I have better things to do. On seeing something like this, my reaction is normally of one of the following:

              *

                do you have anything else to add to that?
              *

                oh, too bad; I hope you get it fixed.
              *

                and this has exactly what to do with me?

          Q:   

          I'm having problems with my Windows machine. Can you help?
          A:   

          Yes. Throw out that Microsoft trash and install an open-source operating system like Linux or BSD.

          Note: you can ask questions related to Windows machines if they are about a program that does have an official Windows build, or interacts with Windows machines (i.e., Samba). Just don't be surprised by the reply that the problem is with Windows and not the program, because Windows is so broken in general that this is very often the case.
          Q:   

          My program doesn't work. I think system facility X is broken.
          A:   

          While it's possible you're the first person to notice an obvious deficiency in system calls and libraries heavily used by hundreds or thousands of people, it's rather more likely you're utterly clueless. Extraordinary claims require extraordinary evidence; when you make a claim like this one, you must back it up with clear and exhaustive documentation of the failure case.
          Q:   

          I'm having problems installing Linux or X. Can you help?
          A:   

          No. I'd need hands-on access to your machine to troubleshoot this. Go ask your local Linux user group for hands-on help. (You can find lists of user groups inside the Linux User Group HOWTO.)

          Note: questions about installing Linux may be appropriate if you're on a forum or mailing list about a particular Linux distribution, and the problem is with that distribution; or on local user groups' forums. In this case, be sure to describe the exact details of the failure. However, do careful searching first, with "linux" and all suspicious pieces of hardware.
          Q:   

          How can I crack root / steal channel-ops privileges / read someone's e-mail?
          A:   

          You're a low-life for wanting to do such things, and a moron for asking a hacker to help you.
          Good and Bad Questions

          Finally, I'm going to illustrate how to ask questions in a smart way by example; pairs of questions about the same problem, one asked in a stupid way and one in a smart way.

          Stupid: Where can I find out stuff about the Foonly Flurbamatic?

              This question just begs for "STFW" as a reply.
          Smart: I used Google to try to find "Foonly Flurbamatic 2600" on the Web, but I got no useful hits. Does anyone know where I can find programming information on this device?

              This one has already STFWed, and sounds like he might have a real problem.

          Stupid: I can't get the code from project foo to compile. Why is it broken?

              The querent assumes somebody else screwed up. Arrogant git....
          Smart: The code from project foo doesn't compile under Nulix version 6.2. I've read the FAQ, but it doesn't have anything in it about Nulix-related problems. Here's a transcript of my compilation attempt; is it something I did?

              He or she's specified the environment, has read the FAQ, has shown the error, and isn't assuming his/her problems are someone else's fault. This one might be worth some attention.

          Stupid: I'm having problems with my motherboard. Can anybody help?

              J. Random Hacker's response to this is likely to be "Right. Do you need burping and diapering, too?" followed by a punch of the delete key.
          Smart: I tried X, Y, and Z on the S2464 motherboard. When that didn't work, I tried A, B, and C. Note the curious symptom when I tried C. Obviously the florbish is grommicking, but the results aren't what one might expect. What are the usual causes of grommicking on Athlon MP motherboards? Anybody got ideas for more tests I can run, to pin down the problem?

              This person, on the other hand, seems worthy of an answer. He/she has exhibited problem-solving intelligence, rather than passively waiting for an answer to drop from on high.

          In the last question, notice the subtle but important difference between demanding "Give me an answer" and "Please help me figure out what additional diagnostics I can run, to achieve enlightenment."

          In fact, the form of that last question is closely based on a real incident in August 2001 on the Linux-kernel mailing list (lkml). I (Eric) was the one asking the question that time. I was seeing mysterious lockups on a Tyan S2462 motherboard. The list members supplied the critical information I needed to solve them.

          By asking the question in the way I did, I gave people something to chew on; I made it easy and attractive for them to get involved. I demonstrated respect for my peers' ability, and invited them to consult with me as a peer. I also demonstrated respect for the value of their time, by telling them the blind alleys I'd already run down.

          Afterwards, when I thanked everyone, and remarked how well the process had worked, an lkml member observed that he thought it had worked not because I'm a "name" on that list, but because I asked the question in the proper form.

          Hackers are in some ways a very ruthless meritocracy; I'm certain he was right, and that if I had behaved like a sponge I would have been flamed or ignored, no matter who I was. His suggestion of writing up the whole incident as instruction to others led directly to composition of this guide.
          If You Can't Get an Answer

          If you can't get an answer, please don't take personally that we don't feel we can help you. Sometimes, the members of the asked group may simply not know the answer. No response is not the same as being ignored, though admittedly it's hard to spot the difference from outside.

          In general, simply re-posting your question is a bad idea. This will be seen as pointlessly annoying. Have patience: The person with your answer may currently be asleep, in a different time-zone.

          There are other sources of help you can go to, often sources better adapted to a novice's needs.

          There are many on-line and local user groups who are enthusiasts about the software, even though they may never have written any software themselves. These groups often form so people can help each other, and help new users.

          There are also plenty of commercial companies you can contract with for help, both large and small. (Red Hat and SpikeSource are two of the best known; there are many others.) Don't be dismayed at having to pay for a bit of help! After all, if your car engine blows a head gasket, chances are you would take it to a repair shop, and pay to get it fixed. Even if the software didn't cost you anything, you can't expect support to always come for free.

          For popular software like Linux, there are at least 10,000 users per developer. It's just not possible for one person to handle the support calls from over 10,000 users. Remember, even if you must pay for support, you're still paying much less than if you'd needed to buy the software as well (and support for closed-source software is usually more expensive and less competent than support for open-source software).
          How To Answer Questions in a Helpful Way

          Be gentle. Problem-related stress can make people seem rude or stupid, even when they're not.

          Reply to a first offender off-line. There is no need of public humiliation for someone who may have made an honest mistake. A real new user may not know how to search archives, or where the FAQ is stored or posted.

          If you don't know for sure, say so! A wrong but authoritative-sounding answer is worse than none at all. Don't point anyone down a wrong path simply because it's fun to sound like an expert. Be humble and honest; set a good example for both the querent and your peers.

          If you can't help, don't hinder. Don't make jokes about procedures that could trash the user's setup — the poor sap might interpret these as instructions.

          Ask probing questions to elicit more details. If you're good at this, the querent will learn something — and so might you. Try to turn the bad question into a good one; remember, we were all new users once.

          While just muttering RTFM is sometimes justified, when replying to someone who is just a lazy slob, a pointer to documentation (even just a suggestion to google for a key phrase) is better.

          If you're going to answer the question at all, give good value. Don't suggest kludgey workarounds, when somebody is using the wrong tool or approach. Suggest good tools. Re-frame the question.

          Help your community learn from the question. When you field a good question, ask yourself "How would the relevant documentation or FAQ have to change, so nobody has to answer this again?" Then, send a patch to the document maintainer.

          If you did research to answer the question, demonstrate your skills rather than writing as though you pulled the answer out of your butt. Answering one good question is like feeding a hungry person one meal, but teaching that person research skills by example is teaching him/her to grow food for a lifetime.
          Related Resources

          If you need instruction in the basics of how personal computers, Unix, and the Internet work, see The Unix and Internet Fundamentals HOWTO.

          When you release software or write patches for software, try to follow the guidelines in the Software Release Practice HOWTO.
          Special Note for FAQ List Maintainers and Webmasters

          Many Web sites, newsgroups, and other on-line forums link to this HOWTO, as a guide for new users. The authors are glad for you to do so. However, please add next to the link in bold type a note about our not being your project's help desk: We get far too many queries from users who assume otherwise.
          Acknowledgements

          Evelyn Mitchell contributed some stupid questions, and inspired the "How To Give A Good Answer" section.

          ---------------End-------------------
          Tags -  , 
]]>
          
          
http://www.zhanghongbiao.com/post/801/
<![CDATA[提问的艺术]]> 
mlzy <mlzy@live.com>

Wed, 03 Sep 2008 14:28:23 +0000 
http://www.zhanghongbiao.com/post/801/ 

据说这是一篇英文文章，热心的网友将其翻译的。但是我找不到英文原版了，于是将此文转载在自己博客上。

          现实生活中，很多人不懂提问，很多人不懂礼貌，当不懂礼貌的人同时又不懂如何提问时，问题就出现了。

          我管理的论坛中，经常会遇到这种人。www.aobo.com.au 比 bbs.izjx.com  懂得提问的人多（留过学的人都被迫学会读长篇大论了吧？）。。你可以上 bbs.izjx.com 去看看，什么样子的白痴都有——我说“白痴”，这只是针对一种行为，而不是针对某些人。这种行为是——当你在角角落落、以及他/她/它（？）注册成为用户的第一时间都告诉他什么问题应该到什么地方去看现成的教程、答案，那么这头生物仍然还是不会去的。于是这些ID的第一个帖子出现了：“帮帮我”。。。作为管理员，如果你没有较好的耐心，也许有一天会情绪失控


          由于原版中文的无法复制到我的blog上（奇怪？。。事实就是这样，一直出错。。）请大家点击此处浏览：http://www.beiww.com/doc/oss/smart-questions.html   （你的浏览器会被警告说此网站不安全，我亦不可得而知为何。）


          在虚拟世界里，当提出一个技术问题时，你能得到怎样的回答？这取决于挖出答案的难度， 同样取决于你提问的方法。本指南旨在帮助你提高发问技巧，以获取你最想要的答案……

          不想掩饰对这样一些人的蔑视--他们不愿思考，或者在发问前不去完成他们应该做的事。这种人只会谋杀时间--他们只愿索取，从不付出，无端消耗我们的时间，而我们本可以把时间用在更有趣的问题或者更值得回答的人身上。我们称这样的人为“失败者”（由于历史原因，我们有时把它拼作“lusers”）。

          提问之前(Before You Ask)

          在通过电邮、新闻组或者聊天室提出技术问题前，检查你有没有做到：
          1. 通读手册，试着自己找答案。
          2. 在FAQ里找答案（一份维护得好的FAQ可以包罗万象:）。
          3. 在网上搜索（个人推荐google~~~）。
          4. 向你身边精于此道的朋友打听。

          当你提出问题的时候，首先要说明在此之前你干了些什么；这将有助于树立你的形象：你不是一个妄图不劳而获的乞讨者，不愿浪费别人的时间。如果提问者能从答案中学到东西，我们更乐于回答他的问题。

          周全的思考，准备好你的问题，草率的发问只能得到草率的回答，或者根本得不到任何答案。越表现出在寻求帮助前为解决问题付出的努力，你越能得到实质性的帮助。

          小心别问错了问题。

          另一方面，表明你愿意在找答案的过程中做点什么，是一个非常好的开端。“谁能给点提示？”、“我这个例子里缺了什么？”以及“我应该检查什么地方？”比“请把确切的过程贴出来”更容易得到答复。因为你显得只要有人指点正确的方向，你就有完成它的能力和决心。

          怎样提问 (When You Ask)

          谨慎选择论坛

          小心选择提问的场合。如果象下面描述的那样，你很可能被忽略掉或者被看作失败者：
          1. 在风马牛不相及的论坛贴出你的问题
          2. 在探讨高级技巧的论坛张贴非常初级的问题；反之亦然
          3. 在太多的不同新闻组交叉张贴

          用辞贴切，语法正确，拼写无误

          我们从经验中发现，粗心的写作者通常也是马虎的思考者（我敢打包票）。

          回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。

          正确的拼写，标点符号和大小写很重要。

          更一般的说，如果你的提问写得象个半文盲，你很有可能被忽视。

          如果你在使用非母语的论坛提问，你可以犯点拼写和语法上的小错--但决不能在思考上马虎 （没错，我们能弄清两者的分别）

          使用含义丰富，描述准确的标题

          在邮件列表或者新闻组中，大约50字以内的主题标题是抓住资深专家注意力的黄金时机。别用喋喋不休的“帮帮忙”（更别说“救命啊！！！！！”这样让人反感的话）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，别用空格代替问题的描述，哪怕是极其简短的描述。

          蠢问题：

          救命啊！我的膝上机不能正常显示了！

          聪明问题：

          XFree86 4.1下鼠标光标变形，Fooware MV1005的显示芯片。

          如果你在回复中提出问题，记得要修改内容标题，表明里面有一个问题。一个看起来象“Re ：测试”或者“Re：新bug”的问题很难引起足够重视。另外，引用并删减前文的内容，给新来的读者留下线索。

          精确描述，信息量大

          1. 谨慎明确的描述症状。
          2. 提供问题发生的环境（机器配置、操作系统、应用程序以及别的什么）。
          3. 说明你在提问前是怎样去研究和理解这个问题的。
          4. 说明你在提问前采取了什么步骤去解决它。
          5. 罗列最近做过什么可能有影响的硬件、软件变更。

          Simon Tatham写过一篇名为《如何有效的报告Bug》的出色短文。强力推荐你也读一读。

          话不在多

          你需要提供精确有效的信息。这并不是要求你简单的把成吨的出错代码或者数据完全转储摘录到你的提问中。如果你有庞大而复杂的测试条件，尽量把它剪裁得越小越好。

          这样做的用处至少有三点。第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；第二，简化问题使你得到有用答案的机会增加；第三，在提炼你的bug报告的过程中，也许你自己就能找出问题所在或作出更正。

          蠢问题：

          我在内核编译中一次又一次遇到SIG11错误，我怀疑某条飞线搭在主板的走线上了，

          这种情况应该怎样检查最好？

          聪明问题：

          我自制的一套K6/233系统，主板是FIC-PA2007 （VIA Apollo VP2芯片组），256MB
          Corsair PC133 SDRAM，在内核编译中频频产生SIG11错误，从开机20分钟以后就有这种情况，开机前20分钟内从没发生过。重启也没有用，但是关机一晚上就又能工作20分钟。所有内存都换过了，没有效果。相关部分的典型编译记录如下...。

          按时间顺序列出症状

          对找出问题最有帮助的线索，往往就是问题发生前的一系列操作，因此，你的说明应该包含操作步骤，以及电脑的反应，直到问题产生。

          如果你的说明很长（超过四个段落），在开头简述问题会有所帮助，接下来按时间顺序详述。这样就会让人知道该在你的说明中找什么。

          明白你想问什么

          漫无边际的提问近乎无休无止的时间黑洞。最能给你有用答案的人也正是最忙的人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞不太感冒，因此也可以说他们对漫无边际的提问不大感冒。如果你明确表述需要回答者做什么（提供建议，发送一段代码，检查你的补丁或是别的），就最有可能得到有用的答案。这会定出一个时间和精力的上限，便于回答者集中精力来帮你，这很凑效。

          解决你的问题需要的时间越少，越能从忙碌的专家口中掏出答案。因此，优化问题的结构，尽量减少专家们解决它所需要的时间，会有很大的帮助--这通常和简化问题有所区别。因此，问“我想更好的理解X，能给点提示吗？” 通常比问“你能解释一下X吗？”更好。如果你的代码不能工作，问问它有什么地方不对，比要求别人替你修改要明智得多。

          别问应该自己解决的问题

          这些问题得由你来搞定，你会从中学到东西。你可以要求给点提示，但别要求得到完整的解决方案。

          去除无意义的疑问

          别用无意义的话结束提问，例如“有人能帮我吗？”或者“有答案吗？”。

          首先：如果你对问题的描述不很合适，这样问更是画蛇添足。其次：由于这样问是画蛇添足，别人会很厌烦你--而且通常会用逻辑上正确的回答来表示他们的蔑视，例如：“没错，有人能帮你”或者“不，没答案”。

          谦逊绝没有害处，而且常帮大忙

          彬彬有礼，多用“请”和“先道个谢了”。让大家都知道你对他们花费时间义务提供帮助心存感激。

          然而，如果你有很多问题无法解决，礼貌将会增加你得到有用答案的机会。

          问题解决后，加个简短说明

          问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个补充说明。补充说明不必很长或是很深入；简单的一句“你好，原来是网线出了问题！谢谢大家--Bill”比什么也不说要强。事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇学术论文更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。

          除了表示礼貌和反馈信息以外，这种补充有助于他人在邮件列表/新闻组/论坛中搜索对你有过帮助的完整解决方案，这可能对他们也很有用。

          最后（至少？），这种补充有助于所有提供过帮助的人从中得到满足感。这种感觉对于那些你向他们求助的导师或者专家而言，是非常重要的。问题久拖未决会让人灰心；好人有好报，满足他们的渴望，你会在下次贴出新问题时尝到甜头。


          转载地址：不详。。。实在找不到原文出处了
          Tags -  ,  ,  ,  , 
]]>
          
          
http://www.zhanghongbiao.com/post/800/
<![CDATA[王震将军简传]]> 
mlzy <mlzy@live.com>

Wed, 03 Sep 2008 02:29:25 +0000 
http://www.zhanghongbiao.com/post/800/ 


          　　新中国成立后某日，王震将军回乡，闻其弟王馀美家鸭子常吃队里谷子，无人敢管。

          　　王震将军(1908—1993)，瘦长挺拔，直鼻梁，厚嘴唇，大嘴巴。将军耿介为人，纯真为怀，怒则嘴咧齿突如金刚，乐亦嘴咧齿突似孩童。尤喜着深灰色中山装，任国家副主席时仍如是。

          　　王震将军凡受领任务，必蓄须，不达之不净面。毛泽东、朱德、彭德怀、贺龙等戏呼其为“王胡子”。

          　　1956年，王震将军被任命为农垦部部长。8月，将军至新疆农垦部队视察。某师为迎接将军，建牌楼，扎鲜花。将军见之，问:“这牌楼能打敌人吗？能长庄稼吗？能产粮食吗？”后，将军小解，又见一由新圆木围成的临时厕所，门旁挂一小牌子:“首长厕所”。将军怒曰:“搞这个名堂干啥？首长的尿也是臊的嘛！” 师长、政委惶惶，急拆除之。


          点击在新窗口中浏览此图片
          图为抗日战争时期，王震同志在延安


          　　据云，新中国成立后中央有规定，凡见毛泽东均不准带枪，惟独王震将军例外。某日，毛泽东召见将军，警卫见其戎装佩枪，挡之门外警卫室。毛泽东闻之，曰:“王胡子不会害我，除原子弹外，他带什么都不准阻拦。 ”1964年6月16日，毛泽东至十三陵观看军事表演，见王震将军问道:“胡子，你怎么瘦了？”将军对曰:“我肠子不好。”毛泽东笑道:“你肠子不好，心好！”“文革”中，造反派批判王震“有野心”，王震对曰:“毛主席说我王胡子心好！”

          　　王震将军虽为武夫，却喜好文化人，推崇文化人。新中国成立初期，与将军常来往的文化人有华罗庚、杜鹏程、丁玲、胡绳、艾青、周立波、李四光、陈白尘、吴祖光、张权，等等。

          　　1953年，王震将军与华罗庚初识，情投意合，契如金兰；来来往往，遂成密友。毛泽东闻之，喜曰:“知识分子不怕王胡子，好啊！”“文革”中，造反派批斗华罗庚，毛泽东表态曰:“王胡子的朋友华罗庚要保一下。”

          　　1944年冬，王震将军率南下支队过汾河、黄河。延安自然科学院副院长陈康白随行，途中骡马行至冰上，不慎打滑落水，书和仪器均丢失。陈康白痛惜落泪，王震将军好语相慰。后将军作诗一首送陈康白，诗曰:

          　　吕梁山上剃胡子，
          　　汾河岸边丢骡子。
          　　死也不丢竹杆子，
          　　誓与马列共生死。

          　　艾青，著名诗人，1957年被错划为右派，下放建设兵团某师。某日，王震将军见艾青，曰:“艾青同志，你好！”艾青讷讷，曰:“我是右派，您不能称我同志。”将军对曰:“你是世界闻名的大诗人，是我们国家的光荣。”是时，将军立于卡车之上，对全师官兵曰:“有个大诗人，艾青，你们知道不知道？他是我的朋友，来歌颂你们，欢迎不欢迎啊？”全场掌声雷动，艾青热泪盈眶。

          　　某日，诸将军做客于王震家中。忽闻警卫报告，著名剧作家陈白尘到访，王震将军急“轰”走诸将军，亲至大门，执陈白尘手进客厅，相谈甚洽，并背诵陈白尘剧作《大风歌》中的台词:“大风起兮云飞扬，威加海内兮归故乡。安得猛士兮守四方？”

          　　“文革”中，造反派斗王震将军，书“贺龙黑干将”牌子挂脖上，将军怒甚，破口大骂，取牌摔于地，以脚踩之，曰:“老子不挂这个，老子只挂军功章。”有人将此事告诉了毛泽东，毛泽东大笑，曰:“王胡子赤膊上阵了，谁让你们惹他？他急了，要跟你们拼命的嘛！”

          　　1975年，邓小平被停职。王震将军召叶飞、李强、王诤等将军，怒目奋臂曰:“我要上山打游击，你们敢不敢跟我去？”又曰:“你们能带多少队伍？能带多少枝枪？”又曰:“我要到天安门广场先发表讲话，然后自杀！”

          　　“文革”中某日晚，江青、张春桥、王洪文、姚文元等于中南海怀仁堂看内部电影。将映，忽见王震将军手持拐杖，愤愤而至，于前排来回走动。警卫局长急上前，悄声问:“王老，你找谁？”将军毫无顾忌，以拐杖敲地，大声喊:“××那王八蛋呢？”江、张、王、姚皆哑然。

          　　1952年10月，王震将军之弟王馀美致函将军，索资为其母建一栋“王家大院”。将军阅后回函曰:“弟弟:妈妈回家去住，我负责砌两间房子，也不能靠我占便宜，更不能靠我耍威风。我是新疆人民的勤务员，要拿钱回家砌王家大院，新疆人民要斗争我，家乡父老要骂我。你定要我拿钱，我写信给农会，发动大家斗争你！把分的田地种好，按照政府的规定缴纳农业税。此复并谅。”

          　　新中国成立后某日，王震将军回乡，闻其弟王馀美家鸭子常吃队里谷子，无人敢管。将军即召生产队领导，专门开会解决王馀美家的鸭子问题。会上，王震将军对在场的县人武部干部胡世中命令道:“中国人民解放军王震上将命令中尉同志，跑步到王馀美家捉鸭子，全部交给供销社。”

          　　王震将军一侄女，以将军老战友之关系，迁户口于北京。王震将军闻之，大怒，严令有关部门“遣送”其回乡。临行，将军对侄女曰:“我年事已高，记性不好。只认得同辈人，不认得下一辈人。”

          　　1982年，王震将军病重，需做气管切开手术。初，将军拒绝手术，无人能劝。邓小平闻之，急委托夫人卓琳至医院。卓琳见王震将军曰:“小平同志问候你，让你一定要服从医生。”是时，将军口不能言，含泪点头，取纸笔写道:“尊重邓主席的命令！”

          　　1993年3月12日，王震将军病逝于广州。次日，佛山机场举行隆重仪式，送将军遗体返京，余与同事郑国联随行采访。回首八年前，余随郭林祥、向守志、张希钦诸将军于南京机场迎候王震将军情景，仍历历在目:将军皓首长身，风骨棱棱，策杖而下，且以杖指诸将军，一一直呼其名。是时，将军抱拳与诸将军戏言曰:“我先去见马克思，向毛主席、朱总司令、周总理报到。”真恍如隔世也。王震将军秘书李慎明告余，将军去世前留遗墨曰:“向党致敬！向人民致敬！向解放军致敬！”

          　　壮哉，“王胡子”！


          转自 澳洲澳宝社区：http://www.aobo.com.au/bbs/thread-102352-1-1.html
          Tags -  ,  ,  ,  ,  , 
]]>
          
          
http://www.zhanghongbiao.com/post/799/
<![CDATA[温瑞安简介]]> 
mlzy <mlzy@live.com>

Mon, 01 Sep 2008 02:09:13 +0000 
http://www.zhanghongbiao.com/post/799/ 


            一九五四年一月一日，出生于马来西亚霹雳州美罗埠火车头。
                 一九五九年尚未入学，已开始念遍家藏书，写第一部以少量文字作为说明的连环图故事《三只驴子》。尝试用所知的少量文字写信、作文、日记。  
            　　一九六一年小学一年级。因怕生，抵死不肯上课，故由姊姊陪同上学，并要其姊留在课室外不去，足有一年半。年来未交一友，未离开过课堂一步，得全第一名，七科平均九十九分，极得教师疼爱，曾罚站一次，已引为耻大辱，毕生难忘。至次年始性情大变。在班上极其活跃，成为班上的锋头人物。  
          　　一九六三年当选级长及全校模范生。开始以班上同学为正邪人物，撰写自绘插画的长篇小说《龙虎风云录》，致使全校高低年班同学争相传闻：看自己如何下场。次年开始每天讲述武侠长篇《血河车》等故事，有过一口气讲八小时而放学後又讲八小时之纪录。同年，第一首诗发表于香港《世界儿童》，诗名《月亮》，八行，由温执笔，结义兄弟廖雁平出资（邮费）投稿，故发表时写名两人。

                一九六五至六六年正式建立「刚击道集团」，兼修文武。在各种儿童、少年刊物杂志上发表作品无数。办校内、校外文艺活动极频。升初中一，转校至中华中学，在功课压力沉重之馀，创办日後足足办了十三年的《绿洲期刊》。并正式在马来西亚极具份量的文艺刊物《学生周报》上频密发表作品。
                 一九六八至七零年以初二之龄，在校际辩论赛中击败高中三年班对手，并协助高年班同学执编《华中月刊》。得班上导师黄因明支持，及兄长温任平勉励下，两年内举辨活动无数，推动各类文艺风气。写成长篇文艺爱情小说：《偶然》。
                 一九七一至七二年华文学校停办高中课程，考上高中，转至巫、英文为主、各族子弟共处的综合中学，在学校力争开授华文课程。其时开始在新马文坛重要文学刊物《蕉风》及《学报》频密发表作品，专攻现代诗、纯散文及新批评，并开始为外间刊物执编《诗专号》、《评论专号》。同年举办《月光会》、《满天星斗》大会等。开始矢力苦修美学、精神分析学，同年，与《绿林分社》怡保区负责人方娥真（寥湮）相识，从此相知联袂十六年。开始在台湾《中国时报》、《现代文学杂志》、《纯文学月刊》、各诗刊发表作品，并在香港《武侠春秋》发表武侠小说。  
                 一九七三年正式创办天狼星诗社，一年内扩充成十大分社，镇日奔波於联络组合，推动文学风气，但仍不忘写作，（逾万字纯散文《龙哭千里》及小说《凿痕》和逾一千四百行的长诗《图腾》四部曲等），习武（举办武术比赛）。在台湾《中外文学》、《幼狮文艺》、《中华文艺》等刊物密集发表作品，以诗及散文为主。年底赴台深造。出版第一部个人诗集：《将军令》。在台举办五方文学座谈会，半工半读，并为筹钱办《天狼星诗刊》而写武侠小说（《四大名捕会京师》便是当时作品）。  


                 一九七六至八零年于福隆大聚创办神州诗社，以“发扬民族精神，复兴中华文化”为己任。八零年九月二十五日深夜与方娥真遭扣押解在军法处监狱后遭遗送出境。
                  一九八一年温、方二人蒙上这种不白之冤，使得在新马老家也杯弓蛇影、风声鹤泪，无法久留，从此开始逃亡的颠沛岁月、苦不堪言。年中，逃亡达香港，适逢港府收紧移民政策，数度申请，皆告失败，赴台亦予严拒。年底，方终得以海外雇员身份留港。温依然飘泊流浪，温氏武侠《神州奇侠》、《血河车》等重要作品，已在明报日报、明报晚报连载发表并出书。

               一九八三年下半年，亚视招揽温氏为创作经理。年底，几经波折，屡遭突变，终於批准来港居留。同年开始在无线电视附属机构博益出版社出书，武侠作品亦终在台由万盛重印推出。作品《四大名捕会京师》及《神相李布衣》在亚洲电视开拍。武侠作品及剧本屡为电影公司改编推出。
                 一九八五至八六年长篇小说在香港《东方日报》连载，并在同一报上连写三个小说专栏。写作量之全盛期，在新马港台美加泰等地手上每月（周、日）有十八个专栏及连载撰写。武侠系列开始在香港敦煌出版，并在台湾《时报周刊》连载。次年始，在武侠创作上始创“超新派”笔路，流风所及影响甚巨。
                 一九八七年成为香港作家协会及香港艺术家联盟之会员。武侠小说译成韩文於韩国报刊连载并出书。同年，武侠小说《杀了你好吗》於台湾最畅销报刊《联合报》副刊连载，此为现代派武侠创作之一大始点。是年起《四大名捕会京师》等作品亦在中国大陆连续出版。
                 一九八八年台湾中视推出剧集《四大名捕会京师》。是年起之三年内，在台各大报刊刊登或连载作品，均为刊登频密度最高者。并在台最大报刊之一的《中国时报》人间版长期连载武侠小说：《刀丛里的诗》，及在《联合报》缤纷版频频发表现代派武侠精品。年底，在港（自由人）台（皇冠）同时同步推山全面创新的温瑞安（超新派）武侠周刊，出版十二至十六集不等，引起热烈反应。在港成立自成一派合作社。
                 一九九零至九八年致力发展中国市场，大部份时间留驻中国。最新著作《打老虎》、《捕老》、《猿猴月》于九七年中由香港皇冠出版社推出。不少新作仍在创作中。


          【温瑞安作品集】

          四大名捕系列

          《四大名捕震关东》 《四大名捕会京师》 《碎梦刀》 《大阵仗》 《开谢花》 《谈亭会》 《骷髅画》 《逆水寒》
          《少年冷血》 《少年追命》 《少年铁手》 《四大凶徒》
          《阿拉丙神灯》 《粉红色的老太婆》 《四大名捕斗将军》 《四大名捕斗僵尸》 《四大名捕打老虎》


          神州奇侠系列

              —正传·神州奇侠—
          《神州奇侠》 《剑气长江》 《两广豪杰》 《江山如画》
          《英雄好汉》 《闯荡江湖》 《神州无敌》 《寂寞高手》
          《天下有雪》
              —外传·血河车—
          《幽冥血河车》 《大宗师》 《逍遥游》 《养生主》
          《人世间》
              —后传·大侠传奇—
          《大侠传奇》
              —别传·唐方一战—
          《侠少》 《唐方一战》
              —续传·蜀中唐门—
          《蜀中唐门》


          七大寇系列

          《七大寇》 《凄惨的刀口》 《祭剑》
              —将军的剑法—
          《战将》 《闯将》 《悍将》 《锋将》


          游侠纳兰系列

          《游侠纳兰故事》 《杀了你好吗》 《绝对不要惹我》 《杀亲》
          《晚上的消失》 《雪在烧》 《战僧与何平》 《杀手善哉》
          《爱上她的和尚》 《爱上和尚的她》 《请你动手晚一点》 《请借夫人一用》


          杀楚系列

          《杀楚》 《破阵》

          白衣方振眉系列

          《龙虎风云》 《试剑山庄》 《长安一战》 《落日大旗》
          《小雪初晴》

          《说英雄 谁是英雄》系列

          《温柔一刀》
          《一怒拔剑》
          《惊艳一枪》
          《伤心小箭》
          《朝天一棍》
          《群龙之首》
          《天下有敌》
          《天下无敌》
          《天下第一》
          《天　敌》


          神相李布衣

          《杀人的心跳》 《叶梦色》 《刀巴记》


          其他武侠作品

          《空手道》 《台风》 《石头拳》 《铁线拳》
          《乱世情怀》 《金血》 《吞火情怀》 《傲慢与偏剑》
          《弹指相思》 《迷神引》 《女神捕》 《大刺杀》
          《请、请、请请请》 《老哥，借头一用》 《朋友，你死过未？》 《失去舌头了吗？》
          《猪脸的岁月》 《喜欢颜色的门徒》 《你死了没有？》 《打不亮的打火机》
          《落叶新芽》 《人形莲藕》 《杀手的慈悲》 《达明王》
          《斗天王之纵横》 《斗天王之风流》 《四大名捕打老虎》 《断了》
          《了断》 《祭刀》 《诈》 《炸》
          《红电》 《绿发》 《蓝电》 《黑火》


          文艺/推理小说

          《凿痕》 《结局》 《七杀》 《杀人》
          《杀人者死》 《杀死雪山飞狐》 《杀人者》 《收拾》
          《杀机》


          武侠文学系列

          《江湖闲话》 《杀人者唐斩》 《刀丛里的诗》


          散文/杂文

          《乳房》《西江月》   
          Tags -  ,  ,  ,  , 
]]>
          
          
http://www.zhanghongbiao.com/post/798/
<![CDATA[给dedecms V4/5 增加自定义文件名功能]]> 
mlzy <mlzy@live.com>

Sun, 31 Aug 2008 06:30:00 +0000 
http://www.zhanghongbiao.com/post/798/ 


          以下修改能实现DEDE自定义网页文件名的功能，例如：

          zi-ding-yi.html/zidingyi.html/defined-pagename.html/自定义某某某.html 等 (注意：Unix类系统不支持中文url。)

          (反正你填什么就是什么，除了短横杠连词符号　-，最好别乱填其它特殊符号特别是单、双引号、空格等，以免出错)。

          如果你不填自定义文件名，则默认为文章的aid，如：

          138.html/65.html　等。

          以下皆以文章模型为例作修改。强烈建议初学者在对文件进行修改前备份之。

          以下为针对 DEDE V5 的修改：

          =====================================================================

          1、在 后台 频道管理 -> 修改栏目(或者增加栏目) -> 高级选项 -> 文章命名规则：

          把 {typedir}/{Y}{M}/{D}-{aid}.html 修改成　{typedir}/{aa}.html

          （{aa} 用来接收自定义文件名。因个人不大喜欢年月日之类的，所以把{Y}、{M}、{D}、{aid}等都去掉了，你喜欢的话，自己加上即可）

          2、修改数据库表 dede_archives 增加 pagename 字段 varchar 100　（100够用了，如果不够用，自己改大（255之内）即可）

          在　后台　-＞　功能菜单　-＞　SQL命令运行器　中输入：

           alter table dede_archives add column pagename varchar(100);

          按确定执行即可。

          3、增加对 {aa} 的处理：

          修改文件：include/inc_channel_unit_functions.php

          把大约73行的：

          $articleRule = str_replace("{cc}",dd2char($m.$d.$aid.$y),$articleRule);

          改为：

          $articleRule = str_replace("{aa}",GetPagename($aid),$articleRule);

          （因为{cc}实在没什么用，扔掉得了）

          4、针对上面　GetPagename($aid)　的处理：

          修改文件： include/inc_functions.php

          在文件最后面　?>　前加入以下函数：

          //获取自定义文件名的函数，检测如果输入了自定义文件名则文件名为所输入的，否则默认为文章的aid
          function GetPagename($dd){
           $sql = "select pagename from #@__archives where id = '$dd'";
           $dsql = new DedeSql(false);
           $row = $dsql->GetOne($sql);
           $pagename = $row["pagename"];
           if($pagename!=""){
            $pagename = $pagename;
           }else{
            $pagename = $dd;
           }
           return $pagename;
          }

          5、修改文章添加和修改页面，在里面加入 pagename 的 input

          （1）修改文件：dede/templets/article_add.htm

          在：
                

              
                    
                      
                      
                    
                 
           Tag标签：
             
             (用空格或','分开)
                      

            

             
                          
                            
                            
                          
                        
           自定义文件名：

                        
           

              
                    
                      
                      
                    
                 
           Tag标签：
             
             
             (用空格或','分开)
                      

               

             
                          
                            
                            
                          
                        
           自定义文件名：" />