分类 技术 下的文章

不知道多少次了,我在微信公众号后台收到询问“你们的微信文章版式是怎么做的”等问题了。其实,我本来觉得这没什么值得问的,也不值得保密,但是总是有人问,我觉得还是写一篇小文来介绍一下吧,下次有人问我,我就直接丢链接好了~

我本身不是做美工和 UI/UE 出身的,但是我们的(前)联合创始人 DeadFire 是专门做这个的,奈何他再也不可能为 Linux 中国做任何的 UE 调整了,/cry。不过我们的 UE 在他的努力之下,目前还算不错,也仅以这些样式来纪念他吧。

下面我来说说我们的微信文章版式的几个算是亮点的地方吧。

先说一个前提,Linux 中国的文章都是通过自身网站的 CMS 进行编辑的,并没有使用外部的那些第三方的微信编辑器。因此,如果你有一个可以编辑内容并形成网页的 CMS,那么以下技巧可能就比较适合你使用;如果你没有 CMS ,理论上说你手工编辑 HTML 页面也是可以的;或者,其实你可以复制我们的文章的格式到一个可视化 HTML 编辑器中,修改内容也可以。

1、代码高亮

作为技术网站,刊载的文章中出现代码是必不可少的,之前我们也用过一些代码高亮插件,但是因一些不足后来就放弃了。

目前我们使用的代码高亮插件是 Google 的 code-prettify,最初它是放在 Google Code 上的,现在也托管到了 GitHub: https://github.com/google/code-prettify 。

code-prettify 的优点是体积小,使用简单,而且自动识别所高亮的语言(虽然有时候识别的不对,但是其实没几个人真的在意对不对,大致能区分不同的语言成分就好了)。目前这个软件已经有比较长的时间不更新了,虽然还有 bug,不过大致上的功能没有什么问题。

使用方法很简单,首先你得在页面中引入 code-prettify 的 js 文件,然后在你要高亮代码外使用 <pre class="prettyprint">...</pre> 或 <code class="prettyprint">...</code> 标签即可。比如:

<script src="run_prettify.js"></script>
<pre class="prettyprint">class Voila {
public:
  // Voila
  static const string VOILA = "Voila";
}</pre>

然后看起来效果就是:

class Voila {
public:
  // Voila
  static const string VOILA = "Voila";
}

可能你使用了 code-prettify 之后也发现和我们的代码样式不同,其实,这只是我们使用了自己定制的一个 CSS 样式罢了,稍微研究下我们的页面代码,你就能找到这个 CSS 的,你可以根据你的喜好进行修改。

当你做好了一个可以在浏览器中满意呈现的页面之后,你只需要复制该页面内容,贴到你的微信后台的编辑器中即可。

2、英文注释标签

我们经常会发布各种英文文章的译文,但是有时候,一些词汇需要附上英文才能比较好的避免歧义。通常大家的做法都是在中文后面用括号圈上对应的英文,但是随着 HTML5 规范的普遍支持,其实还有另外一种新的标签可以更好的用于这种情况。那就是 RUBY 标签。

RUBY 是振假名的意思,用于在 HTML 中标注注音。各个浏览器对 RUBY 标签的支持程度不同,不过最基本的用法都是支持的,包括微信内的浏览器。

简单的来说,RUBY 标签的基本格式如下:<ruby>这里写中文<rt>English here<rt><ruby>,这个标签用浏览器看的效果是这样的: 这里写中文 ( English here ) 。

当然,实际上 RUBY 标签还许多子标签和不同的格式变体,但是一方面各个浏览器支持效果不同,另外一方面对微信浏览器而言仅支持这种基本格式。需要深入研究的同学可以自行搜索。

目前应该还没有支持 RUBY 的 CMS,所以,一般情况下你需要手工编辑你的页面的 HTML 来插入这种标签——当然,我是自己开发了一个我的 CMS 的插件。

此外, RUBY 标签也是可以嵌入链接的,这种情况也比较常见。你可以自行摸索下。

最后,RUBY 标签自然有默认的显示样式,显然,作为在意用户体验的你,肯定会给它单独调整下 CSS 的,是吧?

3、其它

实际上,除了以上两点,我们并没有特别不同的地方,不过用户体验的细节还是有所调整的,但是这些就是见仁见智的地方了,大家可以根据需要参考我们或其它一些在页面体验方面有所特长的页面进行学习。

除此以外,做了几年的微信文章发布,我还有一点点小经验可以分享给大家:

  • 不建议调整正文字号,就用默认的 16px 即可,虽然看起来比较大——但是现在移动设备分辨率越来越高了,所以较小的字号可能会让部分用户看起来比较累。当然,也可以考虑使用 14px,如果你的文章不全是密密麻麻的字的话。
  • 正文文字的颜色不要出现太多,除了黑色以外,最多有两种为宜。此外,在特殊情况下,你还可以考虑使用加粗,甚至斜体效果。
  • 中英文混排时,以及掺杂数字时,尽量在英文单词与汉字之间加个空格,关于这方面,网上有篇《中文排版指北》,会有更详细的建议,不过我认为最重要、最基本的就是这条了。
  • 文内配图,如果有可能尽量尺寸一致,最少要考虑保证图片宽度一致比较好。配图下方,必要时可以用另外一种文字样式来做图片说明。比如我们就是用斜体、灰色、下划线样式的字体作为图片说明。模糊的配图不要也罢,除非必要,用动图会显得很 low——有些老网友或许还记得 20 年前的网页上的那种 GIF 动画展览吧?
  • 题图,如果你的标题不够好,那就选张好的题图吧,如果你能有一张切题的壁纸级题图,那显然会让你的公众号订阅者更高兴一些——如果细心的话,或许你可以放上这张壁纸级题图的高分辨率原图的 URL 地址?
  • 微信后台的文章编辑器对很多 HTML 标签是不支持的,比如 DIV。所以,大家如果采用 div 布局的话,会发现桌面浏览器上看的好好的样式,复制到微信后台的编辑器中会变得惨不忍睹。这种情况下,你可以考虑用一些新的块级元素,比如 SECTION。
  • 链接,微信文章仅在一些特定的情况下支持文内链接,所以,对于大部分公众号的微信文章来说,都是没办法在文内加上链接的。但是作为 Web 世界,有时候明明有链接的地方你不提供链接,你可以想象读者的怒火。这时候,我们有两种方式可以稍微补救。

    1. 对链接的文字加上特定样式(如加上下划线),以暗示此处有链接,然后在后面加个上标,比如 [1],并在文末单独对这个上标提供链接,这样需要的读者可以复制该链接访问。不过要注意的是,微信文章不支持 SUP 标签,你可以用 SPAN 标签来达成类似效果。
    2. 如果文内链接不多,链接本身也不算长,你可以用括号圈起来写上链接,不过如果链接太多,也太长时,这会影响正文阅读效果的。其实这两种方式都是仿照纸质书籍这种无法做到超链接的出版物的。
  • 对于长文章,你应该考虑在文内提供不同层次的大小标题。如果有可能,你还应该在页首提供一个目录、摘要等信息。当然,我们使用了 CMS,这种信息是自动提取生成的,可能要方便一些。

好了,大致我就总结这些,希望对大家有所帮助,如果有什么问题,请留言讨论,也欢迎大家分享自己的经验。

(题图来自:picswalls.com)

gcc 编译器提供了几乎数不清的命令行选项列表。当然,没有人会使用过或者精通它所有的命令行选项,但是有一些命令行选项是每一个 gcc 用户都应该知道的 - 即使不是必须知道。它们中有一些很常用,其他一些不太常用,但不常用并不意味着它们的用处没前者大。

在这个系列的文章中,我们集中于一些不常用但是很有用的 gcc 命令行选项,在第一节已经讲到几个这样的命令行选项。

不知道你是否能够回想起,在这个系列教程的第一部分的开始,我简要的提到了开发者们通常用来生成警告的 -Wall 选项,并不包括一些特殊的警告。如果你不了解这些特殊警告,并且不知道如何生成它们,不用担心,我将在这篇文章中详细讲解关于它们所有的细节。

除此以外,这篇文章也将涉及与浮点值相关的 gcc 警告选项,以及在 gcc 命令行选项列表变得很大的时候如何更好的管理它们。

在继续之前,请记住,这个教程中的所有例子、命令和指令都已在 Ubuntu 16.04 LTS 操作系统和 gcc 5.4.0 上测试过。

生成 -Wall 选项不包括的警告

尽管 gcc 编译器的 -Wall 选项涵盖了绝大多数警告标记,依然有一些警告不能生成。为了生成它们,请使用 -Wextra 选项。

比如,下面的代码:

#include <stdio.h>
#include <stdlib.h>
int main()
{
    int i=0;
    /* ...
       some code here 
       ...
    */

    if(i);
        return 1;
     return 0; 
}

我不小心在 if 条件后面多打了一个分号。现在,如果使用下面的 gcc 命令来进行编译,不会生成任何警告。

gcc -Wall test.c -o test

但是如果同时使用 -Wextra 选项来进行编译:

gcc -Wall -Wextra test.c -o test

会生成下面这样一个警告:

test.c: In function ‘main’:
test.c:10:8: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
 if(i);

从上面的警告清楚的看到, -Wextra 选项从内部启用了 -Wempty-body 选项,从而可以检测可疑代码并生成警告。下面是这个选项启用的全部警告标记。

  • -Wclobbered
  • -Wempty-body
  • -Wignored-qualifiers
  • -Wmissing-field-initializers
  • -Wmissing-parameter-type (仅针对 C 语言)
  • -Wold-style-declaration (仅针对 C 语言)
  • -Woverride-init
  • -Wsign-compare
  • -Wtype-limits
  • -Wuninitialized
  • -Wunused-parameter (只有和 -Wunused 或 -Wall 选项使用时才会启用)
  • -Wunused-but-set-parameter (只有和-Wunused或-Wall` 选项使用时才会生成)

如果想对上面所提到的标记有更进一步的了解,请查看 gcc 手册。

此外,遇到下面这些情况, -Wextra 选项也会生成警告:

  • 一个指针和整数 0 进行 <, <=, >, 或 >= 比较
  • (仅 C++)一个枚举类型和一个非枚举类型同时出现在一个条件表达式中
  • (仅 C++)有歧义的虚拟基底
  • (仅 C++)寄存器类型的数组加下标
  • (仅 C++)对寄存器类型的变量进行取址
  • (仅 C++)基类没有在派生类的复制构建函数中进行初始化

浮点值的等值比较时生成警告

你可能已经知道,浮点值不能进行确切的相等比较(如果不知道,请阅读与浮点值比较相关的 FAQ)。但是如果你不小心这样做了, gcc 编译器是否会报出错误或警告?让我们来测试一下:

下面是一段使用 == 运算符进行浮点值比较的代码:

#include<stdio.h>

void compare(float x, float y)
{
    if(x == y)
    {
        printf("\n EQUAL \n");
    }
}

int main(void)
{
    compare(1.234, 1.56789);

    return 0; 
}

使用下面的 gcc 命令(包含 -Wall 和 -Wextra 选项)来编译这段代码:

gcc -Wall -Wextra test.c -o test

遗憾的是,上面的命令没有生成任何与浮点值比较相关的警告。快速看一下 gcc 手册,在这种情形下可以使用一个专用的 -Wfloat-equal 选项。

下面是包含这个选项的命令:

gcc -Wall -Wextra -Wfloat-equal test.c -o test

下面是这条命令产生的输出:

test.c: In function ‘compare’:
test.c:5:10: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
 if(x == y)

正如上面你所看到的输出那样, -Wfloat-equal 选项会强制 gcc 编译器生成一个与浮点值比较相关的警告。

这儿是gcc 手册关于这一选项的说明:

这背后的想法是,有时,对程序员来说,把浮点值考虑成近似无限精确的实数是方便的。如果你这样做,那么你需要通过分析代码,或者其他方式,算出这种计算方式引入的最大或可能的最大误差,然后进行比较时(以及产生输出时,不过这是一个不同的问题)允许这个误差。特别要指出,不应该检查是否相等,而应该检查两个值是否可能出现范围重叠;这是用关系运算符来做的,所以等值比较可能是搞错了。

如何更好的管理 gcc 命令行选项

如果在你使用的 gcc 命令中,命令行选项列表变得很大而且很难管理,那么你可以把它放在一个文本文件中,然后把文件名作为 gcc 命令的一个参数。之后,你必须使用 @file 命令行选项。

比如,下面这行是你的 gcc 命令:

gcc -Wall -Wextra -Wfloat-equal test.c -o test

然后你可以把这三个和警告相关的选项放到一个文件里,文件名叫做 gcc-options:

$ cat gcc-options&nbsp;
-Wall -Wextra -Wfloat-equal

这样,你的 gcc 命令会变得更加简洁并且易于管理:

gcc @gcc-options test.c -o test

下面是 gcc 手册关于 @file 的说明:

从文件中读取命令行选项。读取到的选项随之被插入到原始 @file 选项所在的位置。如果文件不存在或者无法读取,那么这个选项就会被当成文字处理,而不会被删除。

文件中的选项以空格分隔。选项中包含空白字符的话,可以用一个由单引号或双引号包围完整选项。任何字符(包括反斜杠: '\')均可能通过一个 '\' 前缀而包含在一个选项中。如果该文件本身包含额外的 @file 选项,那么它将会被递归处理。

结论

在这个系列的教程中,我们一共讲解了 5 个不常见但是很有用的 gcc 命令行选项: -Save-temps、-g、 -Wextra、-Wfloat-equal 以及 @file。记得花时间练习使用每一个选项,同时不要忘了浏览 gcc 手册上面所提供的关于它们的全部细节。

你是否知道或使用其他像这样有用的 gcc 命令行选项,并希望把它们在全世界范围内分享?请在下面的评论区留下所有的细节。


via: https://www.howtoforge.com/tutorial/uncommon-but-useful-gcc-command-line-options-2/

作者:Ansh 译者:ucasFL 校对:jasminepeng

本文由 LCTT 原创编译,Linux中国 荣誉推出

脚本是存储在一个文件的一系列命令。在终端上输入一个个命令,按顺序执行的方法太弱了,使用脚本,系统中的用户可以在一个文件中存储所有命令,反复调用该文件多次重新执行命令。

在学习脚本或写脚本的初期阶段,我们通常从写小脚本或者几行命令的短脚本开始,调试这样的脚本时我们通常无非就是通过观察它们的输出来确保其正常工作。

然而,当我们开始写非常长或上千行命令的高级脚本,例如改变系统设置的脚本,在网络上执行关键备份 等等,我们会意识到仅仅看脚本输出是不足以在脚本中找到 Bug 的!

因此,在 Linux 系列中这篇介绍 Shell 脚本调试, 我们将看看如何启用 Shell 脚本调试,然后在之后的系列中解释不同的 Shell 脚本调试模式以及如何使用它们。

如何开始写一个脚本

一个脚本与其它文件的区别是它的首行,它包含 #! (She-Bang - 释伴:定义文件类型)和路径名(解释器路径),通知系统该文件是一个命令集合,将被指定程序(解释器)解释。

下面是不同类型脚本 首行 示例:

#!/bin/sh          [sh 脚本]
#!/bin/bash        [bash 脚本] 
#!/usr/bin/perl    [perl 程序]
#!/bin/awk -f      [awk 脚本]   

注意:如果脚本仅包含一组标准系统命令,没有任何内部 Shell 指令,首行或 #! 可以去掉。

如何在 Linux 操作系统执行 Shell 脚本

调用一个脚本脚本的常规语法是:

$ 脚本名  参数1 ... 参数N

另一种可能的形式是明确指定将执行这个脚本的 Shell,如下:

$ shell 脚本名  参数1 ... 参数N

示例:

$ /bin/bash   参数1 ... 参数N     [bash 脚本]
$ /bin/ksh   参数1 ... 参数N      [ksh 脚本]
$ /bin/sh   参数1 ... 参数N       [sh 脚本]

对于没有 #! 作为首行,仅包含基础系统命令的脚本,示例如下:

### 脚本仅包含标准系统命令
cd /home/$USER
mkdir tmp
echo "tmp directory created under /home/$USER"

使它可执行并运行,如下:

$ chmod +x  脚本名
$ ./脚本名 

启用 Shell 脚本调试模式的方法

下面是主要的 Shell 脚本调试选项:

  • -v (verbose 的简称) - 告诉 Shell 读取脚本时显示所有行,激活详细模式。
  • -n (noexec 或 no ecxecution 简称) - 指示 Shell 读取所有命令然而不执行它们,这个选项激活语法检查模式。
  • -x (xtrace 或 execution trace 简称) - 告诉 Shell 在终端显示所有执行的命令和它们的参数。 这个选项是启用 Shell 跟踪模式。

1、 改变 Shell 脚本首行

第一个机制是改变 Shell 脚本首行,如下,这会启动脚本调试。

#!/bin/sh 选项

其中, 选项可以是上面提到的一个或多个调试选项。

2、 调用 Shell 调试选项

第二个是使用如下调试选项启动 Shell,这个方法也会打开整个脚本调试。

$ shell 选项   参数1 ... 参数N

示例:

$ /bin/bash 选项   参数1 ... 参数N

3、 使用 Shell 内置命令 set

第三个方法是使用内置命令 set 去调试一个给定的 Shell 脚本部分,如一个函数。这个机制是重要的,因为它让我们可以去调试任何一段 Shell 脚本。

我们可以如下使用 set 命令打开调试模式,其中选项是之前提到的所有调试选项。

$ set 选项 

启用调试模式:

$ set -选项

禁用调试模式:

$ set +选项

此外,如果我们在 Shell 脚本不同部分启用了几个调试模式,我们可以一次禁用所有调试模式,如下:

$ set -

关于启用 Shell 脚本调试模式,先讲这些。正如我们看到的,我们可以调试一整个 Shell 脚本或者特定部分脚本。

在此系列下面的两篇文章中,我们会举例介绍如何使用 Shell 脚本调试选项,进一步了解 详细 ( verbose ) 、 语法检查 ( syntax checking ) 、 跟踪 ( tracing ) 调试模式。

更重要的是,关于这个指南,欢迎通过下面评论提出任何问题或反馈。


via: http://www.tecmint.com/enable-shell-debug-mode-linux/

作者:Aaron Kili 译者:imxieke 校对:jasminepeng

本文由 LCTT 组织编译,Linux中国 荣誉推出

简介:这篇详细的指南将向你展示如何在 Linux 和 Windows 之间共享 Steam 的游戏文件以节省下载的总用时和下载的数据量。我们将展示给你它是怎样为我们节约了 83% 的数据下载量。

假如你决心成为一名 Linux 平台上的玩家,并且在 Steam 上拥有同时支持 Linux 和 Windows 平台的游戏,或者基于同样的原因,拥有双重启动的系统,则你可以考虑看看这篇文章。

我们中的许多玩家都拥有双重启动的 Linux 和 Windows。有些人只拥有 Linux 系统,但同时拥有当前还没有被 Linux 平台上的 Steam 支持的游戏。所以我们同时保留这两个系统以便我们可以在忽略平台的前提下玩我们喜爱的游戏。

幸运的是 Linux 游戏社区应运而生,越来越多在 Windows 平台上受欢迎的 Steam 游戏也发布在 Linux 平台上的 Steam 中。

我们中的许多人喜欢备份我们的 Steam 游戏,使得我们不再苦苦等待游戏下载完成。这些游戏很大程度上是 Windows 平台下的 Steam 游戏。

现在,很多游戏也已经登陆了 Linux 平台上的 Steam,例如 奇异人生 ( Life is Strange ) 、 古墓丽影 2013 ( Tomb Raider 2013 ) 、 中土世界:魔多阴影 ( Shadow of Mordor ) 、 幽浮:未知敌人 ( XCOM: Enemy Unknown ) 、幽浮 2、 与日赛跑 ( Race The Sun ) 、 公路救赎 ( Road Redemption ) 、 燥热 ( SUPERHOT ) 等等,并且这份名单一直在增长。甚至还有 杀出重围:人类分裂 ( Deus Ex: Mankind Divided ) 和 疯狂的麦克斯 ( Mad Max ) !!!在一些游戏的 Windows 版发布之后,现在我们不必再等候多年,而只需等待几月左右,便可以听到类似的消息了,这可是大新闻啊!

下面的实验性方法将向你展示如何使用你现存的任何平台上游戏文件来在 Steam 上恢复游戏的大部分数据。对于某些游戏,它们在两个平台下有很多相似的文件,利用下面例子中的方法,将减少你在享受这些游戏之前的漫长的等待时间。

在下面的方法中,我们将一步一步地尝试利用 Steam 自身的备份与恢复功能或者以手工的方式来达到我们的目的。当涉及到这些方法的时候,我们也将向你展示这两个平台上游戏文件的相同和不同之处,以便你也可以探索并做出你自己的调整。

下面的方法中,我们将使用 Ubuntu 14.04 LTS 和 Windows 10 来执行备份与恢复 Steam 的测试。

1、Steam 自身的备份与恢复

当我们尝试使用 Windows 平台上 Steam 中《 燥热 ( SUPERHOT ) 》这个游戏的备份(这些加密文件是 .csd 格式)时,Linux 平台上的 Steam 不能识别这些文件,并重新开始下载整个游戏了!甚至在做了验证性检验后,仍然有很大一部分文件不能被 Steam 识别出来。我们在 Windows 上也做了类似的操作,但结果是一样的!

现在到了我们用某些手工的方法来共享 Windows 和 Linux 上的 Steam 游戏的时刻了!

2、手工方法

首先,让我们先看看 Linux 下这些游戏文件所处的位置(用户目录在 /home 中):

这是 Linux 平台上 Steam 游戏的默认安装位置。 .local 和 .steam 目录默认情况下是不可见的,你必须将它们显现出来。我们将推荐使用一个自定义的 Steam 安装位置以便更容易地处理这些文件。这里 SUPERHOT.x86_64 是 Linux 下原生的可执行文件,与 Windows 中的 .exe 文件类似。

下图展示的位置包含我们需要的大部分文件(在 Windows 和 Linux 平台上相同):

下面我们来看看这些 .acf 格式的文件。appmanifest_322500.acf 便是那个我们需要的文件。编辑并调整这个文件有助于 Steam 识别在 common 这个目录下现存的非加密的原始文件备份:

为了确认这个文件是一样的,用编辑器打开这个文件并检查它。我们越多地了解这个文件越好。这个链接是来自 Steam 论坛上的一个帖子,它展示了这个文件的主要意义。它类似于下面这样:

“AppState”
{
“appid”        “322500”
“Universe”        “1”
“name”        “SUPERHOT”
“StateFlags”        “4”
“installdir”        “SUPERHOT”
“LastUpdated”        “1474466631”
“UpdateResult”        “0”
“SizeOnDisk”        “4156100762”
“buildid”        “1234395”
“LastOwner”       “<SteamID>”
“BytesToDownload”        “909578688”
“BytesDownloaded”        “909578688”
“AutoUpdateBehavior”        “0”
“UserConfig”
{
“Language”        “english”
}
“MountedDepots”
{
“322503”        “1943012315434556837”
}
}

在 Linux 平台上卸载游戏后我们再进行测试。现在让我们看看在 Windows 10 上相同的游戏安装目录里包含哪些内容:

我们复制了 SUPERHOT 目录和 .acf 格式的清单文件(这个文件在 Windows 的 Steam 上格式是一样的)。在复制 .acf 文件和游戏目录到 Linux 中 Steam 它们对应的位置时,我们需要确保 Steam 没有在后台运行。

在转移完成之后,我们运行 Steam 并看到了这个:

所以下图显示只需要有 235.5 MB 的文件需要下载,而不是整个 867.4 MB,这意味着超过 70% 的文件已经被 Steam 识别了:) !相对来说,节省了一笔大量的时间开销。当然不同的游戏可能有所不同,但对于那些网速居于平均水平或以下的玩家来说,这种方法绝对值得一试,尤其是考虑到当前那些 40-50 GB 大小的重量级游戏。

我们还进行了其他几种尝试:

  • 我们尝试使用 Linux 下原有的清单文件(.acf)和来自 Windows 的手工备份文件,但结果是 Steam 重新开始下载游戏。
  • 我们看到当我们将 SUPERHOT_Data 这个目录中的 SH_Data 更换为 Windows 中的对应目录时,同上面的一样,也重新开始下载整个游戏。

理解清单目录的一个尝试

清单目录绝对可以被进一步地被编辑和修改以此来改善上面的结果,使得 Steam 检测出尽可能多的文件。

在 Github 上有一个项目,包含一个可以生成这些清单文件的 python 脚本。任何 Steam 游戏的 AppID 可以从SteamDB 上获取到。知晓了游戏的 ID 号后,你便可以用你喜爱的编辑器以下面的格式创建你自己的清单文件 appmanifest_<AppID>.acf。在上面手工方法中,我们可以看到 SUPERHOT 这个游戏的 AppID 是 322500,所以对应的清单文件名应该是 appmanifest_322500.acf。

下面以我们知晓的信息来尝试对该文件进行一些解释:

“AppState”                                   // 应用(游戏)的状态
“appid”        “322500”                    // 游戏的 AppID
“Universe”        “1”
“name”        “SUPERHOT”                   // 游戏的名称
“StateFlags”        “4”
“installdir”        “SUPERHOT”             // 安装目录的名称
“LastUpdated”        “1474466631”
“UpdateResult”        “0”
“SizeOnDisk”        “4156100762”
“buildid”        “1234395”
“LastOwner”        “<SteamID>”             // 唯一的帐号拥有者的 <SteamID> 
“BytesToDownload”        “909578688”       // 将这个数字除以 1073741824(1024 x 1024 x 1024) 便可以计算出还需要下载的数据大小,以 GB 记。
“BytesDownloaded”        “909578688”       // 已下载数据的大小, 以 Bytes 记。
“AutoUpdateBehavior”        “0”            // 当这个设为 0 时,该游戏将自动升级。

“UserConfig”                                 // 用户的配置信息
{
“Language”        “english”
}
“MountedDepots”                              //  这个部分大多与游戏的 DLC 相关。
{
“322503”        “1943012315434556837”
}
}

通过计算下载的数据的大小,你可以将它与 Steam 展现的信息进行比较并进行更多的调整。

假如你知道更多关于清单文件或者手工方式中另外可以改进的方法,请在评论中分享给大家。我们打算去发现更多的关于这些文件格式的信息,当前在官方的 Valve 开发者社区 或者 Steam 论坛 上我们还没有发现完整的文档。

至少现在为止,这些便是我们知道的在 Linux 和 Windows 之间分享 Steam 游戏的最好方法了。


via: https://itsfoss.com/share-steam-files-linux-windows/

作者:Avimanyu Bandyopadhyay 译者:FSSlc 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

软件工具通常情况下会提供多个功能以供选择,但是如你所知的,不是所有的功能都能被每个人用到的。公正地讲,这并不是设计上的错误,因为每个用户都会有自己的需求,他们只在他们的领域内使用该工具。然而,深入了解你所使用的工具也是很有益处的,因为你永远不知道它的某个功能会在什么时候派上用场,从而节省下你宝贵的时间。

举一个例子:编译器。一个优秀的编程语言编译器总是会提供极多的选项,但是用户一般只知道和使用其中很有限的一部分功能。更具体点来说,比如你是 C 语言开发人员,并将 Linux 作为你的开发平台,那么你很有可能会用到 gcc 编译器,这个编译器提供了 (几乎) 数不清的命令行选项列表。

你知道,你可以让 gcc 保存每个编译阶段的输出吗?你知道用于生成警告的 -Wall 选项,它并不会包含一些特殊的警告吗?gcc 的很多命令行选项都不会经常用到,但是它们在某些特定的情况下会变得非常有用,例如,当你在调试代码的时候。

所以在本文中,我们会介绍这样的几个选项,提供所有必要的细节,并通过简单易懂的例子来解释它们。

但是在开始前,请注意本文中所有的例子所使用的环境:基于 Ubuntu 16.04 LTS 操作系统,gcc 版本为 5.4.0。

在每个编译阶段查看中间代码的输出

你知道在通过 gcc 编译 c 语言代码的时候大体上共分为四个阶段吗?分别为预处理 -> 编译 -> 汇编 -> 链接。在每个阶段之后,gcc 都会产生一个将移交给下一个阶段的临时输出文件。但是生成的都是临时文件,因此我们并不能看到它们——我们所看到的只是我们发起编译命令,然后它生成的我们可以直接运行的二进制文件或可执行文件。

但是比如说在预处理阶段,如果调试时需要查看代码是如何进行处理的,你要怎么做呢?好消息是 gcc 编译器提供了相应的命令行选项,你可以在标准编译命令中使用这些选项获得原本被编译器删除的中间文件。我们所说的选项就是-save-temps。

以下是 gcc 手册中对该选项的介绍:

永久存储临时的中间文件,将它们放在当前的文件夹下并根据源文件名称为其命名。因此,用 -c -save-temps 命令编译 foo.c 文件时会生成 foo.i foo.s 和 foo.o 文件。即使现在编译器大多使用的是集成的预处理器,这命令也会生成预处理输出文件 foo.i。

当与 -x 命令行选项结合使用时,-save-temps 命令会避免覆写与中间文件有着相同扩展名的输入源文件。相应的中间文件可以通过在使用 -save-temps 命令之前重命名源文件获得。

以下是怎样使用这个选项的例子:

gcc -Wall -save-temps test.c -o test-exec

下图为该命令的执行结果,验证其确实产生了中间文件:

因此,在截图中你所看到的 test.i、test.s、 test.o 文件都是由 -save-temps 选项产生的。这些文件分别对应于预处理、编译和链接阶段。

让你的代码可调试和可分析

你可以使用专有的工具调试和分析代码。如 gdb 就是专用于调试的工具,而 gprof 则是热门的分析工具。但你知道 gcc 特定的命令行选项也可以让你的代码可调试和可分析吗?

让我们开始调试之路吧!为了能在代码调试中使用 gdb,你需要在编译代码的时候使用 gcc 编译器提供的 -g 选项。这个选项让 gcc 生成 gdb 需要的调试信息从而能成功地调试程序。

如果你想要使用此选项,建议您详细阅读 gcc 手册提供的有关此选项的详细信息——在某些情况下,其中的一些内容可能是至关重要的。 例如,以下是从手册页中摘录的内容:

GCC 允许在使用 -g 选项的时候配合使用 -O 选项。优化代码采用的便捷方式有时可能会产生意想不到的结果:某些你声明的变量可能不复存在;控制流可能会突然跳转到你未曾预期的位置;一些语句也许不会执行,因为它们已经把常量结果计算了或值已经被保存;一些语句可能会在不同地方执行,因为它们已经被移出循环。

然而优化的输出也是可以调试的。这就使得让优化器可以合理地优化或许有 bug 的代码。

不只是 gdb,使用 -g 选项编译代码,还可以开启使用 Valgrind 内存检测工具,从而完全发挥出该选项的潜力。或许还有一些人不知道,mencheck 工具被程序员们用来检测代码中是否存在内存泄露。你可以在这里参见这个工具的用法。

继续往下,为了能够在代码分析中使用 gprof 工具,你需要使用 -pg 命令行选项来编译代码。这会让 gcc 生成额外的代码来写入分析信息,gprof 工具需要这些信息来进行代码分析。gcc 手册 中提到:当编译你需要数据的源文件时,你必须使用这个选项,当然链接时也需要使用它。为了能了解 gprof 分析代码时具体是如何工作的,你可以转到我们的网站专用教程进行了解。

注意:-g 和 -pg 选项的用法类似于上一节中使用 -save-temps 选项的方式。

结论

我相信除了 gcc 的专业人士,都可以在这篇文章中得到了一些启发。尝试一下这些选项,然后观察它们是如何工作的。同时,请期待本教程系列的下一部分,我们将会讨论更多有趣和有用的 gcc 命令行选项。


via: https://www.howtoforge.com/tutorial/uncommon-but-useful-gcc-command-line-options/

作者:Ansh 译者:dongdongmian 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在 Linux 终端下处理文件时,有时我们想直接清空文件的内容但又不必使用任何 Linux 命令行编辑器 去打开这些文件。那怎样才能达到这个目的呢?在这篇文章中,我们将介绍几种借助一些实用的命令来清空文件内容的方法。

注意:在我们进一步深入了解这些方法之前,请记住: 由于在 Linux 中一切皆文件,你需要时刻注意,确保你将要清空的文件不是重要的用户文件或者系统文件。清空重要的系统文件或者配置文件可能会引发严重的应用失败或者系统错误。

前面已经说道,下面的这些方法都是从命令行中达到清空文件的目的。

提示:在下面的示例中,我们将使用名为 access.log 的文件来作为示例样本。

1. 通过重定向到 Null 来清空文件内容

清空或者让一个文件成为空白的最简单方式,是像下面那样,通过 shell 重定向 null (不存在的事物)到该文件:

# > access.log

Empty Large File Using Null Redirect in Linux

在 Linux 下使用 Null 重定向来清空大文件

2. 使用 ‘true’ 命令重定向来清空文件

下面我们将使用 : 符号,它是 shell 的一个内置命令,等同于 true 命令,它可被用来作为一个 no-op(即不进行任何操作)。

另一种清空文件的方法是将 : 或者 true 内置命令的输出重定向到文件中,具体如下:

# : > access.log
或 
# true > access.log

Empty Large File Using Linux Commands

使用 Linux 命令清空大文件

3. 使用 cat/cp/dd 实用工具及 /dev/null 设备来清空文件

在 Linux 中, null 设备基本上被用来丢弃某个进程不再需要的输出流,或者作为某个输入流的空白文件,这些通常可以利用重定向机制来达到。

所以 /dev/null 设备文件是一个特殊的文件,它将清空送到它这里来的所有输入,而它的输出则可被视为一个空文件。

另外,你可以通过使用 cat 命令 显示 /dev/null 的内容然后重定向输出到某个文件,以此来达到清空该文件的目的。

# cat /dev/null > access.log

Empty File Using cat Command

使用 cat 命令来清空文件

下面,我们将使用 cp 命令 复制 /dev/null 的内容到某个文件来达到清空该文件的目的,具体如下所示:

# cp /dev/null access.log

Empty File Content Using cp Command

使用 cp 命令来清空文件

而下面的命令中, if 代表输入文件,of 代表输出文件。

# dd if=/dev/null of=access.log

Empty File Content Using dd Command

使用 dd 命令来清空文件内容

4. 使用 echo 命令清空文件

在这里,你可以使用 echo 命令 将空字符串的内容重定向到文件中,具体如下:

# echo "" > access.log
或者
# echo > access.log

Empty File Using echo Command

使用 echo 命令来清空文件

注意:你应该记住空字符串并不等同于 null 。字符串表明它是一个具体的事物,只不过它的内容可能是空的,但 null 则意味着某个事物并不存在。

基于这个原因,当你将 echo 命令 的输出作为输入重定向到文件后,使用 cat 命令 来查看该文件的内容时,你将看到一个空白行(即一个空字符串)。

要将 null 做为输出输入到文件中,你应该使用 -n 选项,这个选项将告诉 echo 不再像上面的那个命令那样输出结尾的那个新行。

# echo -n "" > access.log

Empty File Using Null Redirect

使用 Null 重定向来清空文件

5. 使用 truncate 命令来清空文件内容

truncate 可被用来将一个文件缩小或者扩展到某个给定的大小。

你可以利用它和 -s 参数来特别指定文件的大小。要清空文件的内容,则在下面的命令中将文件的大小设定为 0:

# truncate -s 0 access.log

Truncate File Content in Linux

在 Linux 中截断文件内容

我要介绍的就是这么多了。在本文中,我们介绍了几种通过使用一些简单的命令行工具和 shell 重定向机制来清除或清空文件内容的方法。

上面介绍的这些可能并不是达到清空文件内容这个目的的所有可行的实践方法,所以你也可以通过下面的评论栏告诉我们本文中尚未提及的其他方法。


via: http://www.tecmint.com/empty-delete-file-content-linux/

作者:Aaron Kili 译者:FSSlc 校对:jasminepeng

本文由 LCTT 原创编译,Linux中国 荣誉推出