【Linux】一步一步学Linux——tr命令(55)

00. 目录

文章目录

01. 命令概述

tr命令可以对来自标准输入的字符进行替换、压缩和删除。它可以将一组字符变成另一组字符，经常用来编写优美的单行命令，作用很强大。

tr的英文全称是“ transform ”，即转换的意思。tr他只能从标准输入中读取数据，因此，tr要么将输入文件重定向到标准输入，要么从管道读入数据。

注意：tr类似于sed命令，但是比sed简单，所以tr能实现的功能，sed都能实现。

02. 命令格式

用法：tr [选项]... SET1 [SET2]

  • 1

03. 常用选项

从标准输入中替换、缩减和/或删除字符，并将结果写到标准输出。

  -c, -C, --complement        首先补足SET1
  -d, --delete            删除匹配SET1 的内容，并不作替换
  -s, --squeeze-repeats    如果匹配于SET1 的字符在输入序列中存在连续的
                重复，在替换时会被统一缩为一个字符的长度
  -t, --truncate-set1        先将SET1 的长度截为和SET2 相等
      --help        显示此帮助信息并退出
      --version        显示版本信息并退出

SET 是一组字符串，一般都可按照字面含义理解。解析序列如下：

  \NNN    八进制值为NNN 的字符(1 至3 个数位)
  \\        反斜杠
  \a        终端鸣响
  \b        退格
  \f        换页
  \n        换行
  \r        回车
  \t        水平制表符
  \v        垂直制表符
  字符1-字符2    从字符1 到字符2 的升序递增过程中经历的所有字符
  [字符*]    在SET2 中适用，指定字符会被连续复制直到吻合设置1 的长度
  [字符*次数]    对字符执行指定次数的复制，若次数以 0 开头则被视为八进制数
  [:alnum:]    所有的字母和数字
  [:alpha:]    所有的字母
  [:blank:]    所有呈水平排列的空白字符
  [:cntrl:]    所有的控制字符
  [:digit:]    所有的数字
  [:graph:]    所有的可打印字符，不包括空格
  [:lower:]    所有的小写字母
  [:print:]    所有的可打印字符，包括空格
  [:punct:]    所有的标点字符
  [:space:]    所有呈水平或垂直排列的空白字符
  [:upper:]    所有的大写字母
  [:xdigit:]    所有的十六进制数
  [=字符=]    所有和指定字符相等的字符

仅在SET1 和SET2 都给出，同时没有-d 选项的时候才会进行替换。
仅在替换时才可能用到-t 选项。如果需要SET2 将被通过在末尾添加原来的末字符的方式
补充到同SET1 等长。SET2 中多余的字符将被省略。只有[:lower:] 和[:upper:]
以升序展开字符；在用于替换时的SET2 中以成对表示大小写转换。-s 作用于SET1，既不
替换也不删除，否则在替换或展开后使用SET2 缩减。

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43

04. 参考示例

4.1 将输入字符由大写转换为小写

[deng@localhost ~]$ echo "HELLO ITCAST" | tr 'A-Z' 'a-z'
hello itcast
[deng@localhost ~]$ 

  • 1
  • 2
  • 3

‘A-Z’ 和 ‘a-z’都是集合，集合是可以自己制定的，例如：‘ABD-}’、‘bB.,’、‘a-de-h’、‘a-c0-9’都属于集合，集合里可以使用’\n’、’\t’，可以可以使用其他ASCII字符。

4.2 删除出现的数字

[deng@localhost ~]$ echo "hello 1234 itcast 7890" | tr -d '0-9'
hello  itcast 
[deng@localhost ~]$ 

  • 1
  • 2
  • 3

4.3 从输入文本中将不在补集中的所有字符删除

[deng@localhost test]$ echo aabbcc..#dd2 */dk4 | tr -d -c '0-9 \n'
2 4
[deng@localhost test]$ 

  • 1
  • 2
  • 3

补集中包含了数字0~9、空格和换行符\n，所以没有被删除，其他字符全部被删除了。

4.4 将连续重复的字符以单独一个字符表示

[deng@localhost test]$ echo "helloooooooooo is   heimamaaaaaaaaaa" | tr -s 'oa'
hello is   heimama
[deng@localhost test]$ 

  • 1
  • 2
  • 3

4.5 使用替换操作执行+操作

[deng@localhost test]$ echo 1 2 3 4 5 6 7 8 9 | xargs -n1 | echo $[ $(tr '\n' '+') 0 ]
45
[deng@localhost test]$ 

  • 1
  • 2
  • 3

4.6 删除由于Windows文件造成的’^M’字符

[deng@localhost test]$ cat txt | tr -s '\r' '\n' > file
[deng@localhost test]$ 

  • 1
  • 2

或者

[deng@localhost test]$ cat txt | tr -d '\r' > file

  • 1

4.7 将小写字母转换为大写字母

[deng@localhost test]$ echo "hello itcast" | tr '[:lower:]' '[:upper:]'
HELLO ITCAST
[deng@localhost test]$ 

  • 1
  • 2
  • 3

4.8 将换行符替换成制表符

[deng@localhost test]$ cat txt | tr '\n' '\t'
    1111        1111    2222    2222    5555    [deng@localhost test]$ 
[deng@localhost test]$ 

  • 1
  • 2
  • 3

05. 附录

参考：【Linux】一步一步学Linux系列教程汇总

id="article_content" class="article_content clearfix"> id="content_views" class="markdown_views prism-atom-one-light">

配置完毕产品解决方案、芯片开发板解决方案，就可以执行 hb build进行编译。但是产品解决方案代码是如何被调用编译的？
芯片开发板解决方案代码是如何被调用编译的？内核代码如何被调用编译的？解决了这些疑惑，会对build lite编译构建过程有个更深入的理解。

1、产品解决方案代码是如何被调用编译的

在文件build\lite\BUILD.gn配置文件中的构建目标//build/lite:product的代码片段如下，可以看出产品解决方案是被//build/lite:product调用的。其中⑴处的ohos_build_target，由hb build -T XX 构建参数指定，一般不指定时为空。

    group("product") {
    deps = []

    # build product, skip build single component scenario.
⑴  if (ohos_build_target == "") {
        deps += [ "${product_path}" ]
    }
    }
 class="hljs-button signin active" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

//build/lite:product 又进一步被什么模块调用？在恒玄的代码配置文件device\soc\bestechnic\bes2600\BUILD.gn中使用了，非恒玄的没有调用//build/lite:product。所以，除了//build/lite:product，还有其他调用编译产品解决方案代码的地方。

以vendor\goodix\gr5515_sk_iotlink_demo为例，来了解下什么地方会调用编译产品解决方案代码。产品解决方案根目录下有文件vendor\goodix\gr5515_sk_iotlink_demo\ohos.build，片段如下。可以看到，有子系统subsystem和部件信息parts。

{
  "parts": {
    "product_gr5515_sk_iotlink_demo": {
      "module_list": [
        "//vendor/goodix/gr5515_sk_iotlink_demo:gr5515_sk_iotlink_demo",
        "//vendor/goodix/gr5515_sk_iotlink_demo:image"
      ]
    }
  },
  "subsystem": "product_gr5515_sk_iotlink_demo"
}
 class="hljs-button signin active" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

在编译构建时，会基于ohos.build文件，解析子系统和部件信息，生成到out\gr5515_sk\gr5515_sk_iotlink_demo\build_configs\parts_info\subsystem_parts.json文件中，片段如下。这些解析出来的子系统和部件信息，编译构建构建hb会组织进行编译构建。

  "product_gr5515_sk_iotlink_demo": [
    "product_gr5515_sk_iotlink_demo"
  ],
 class="hljs-button signin active" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">
  • 1
  • 2
  • 3

2、芯片开发板解决方案代码是如何被调用编译的

在文件kernel\liteos_m\BUILD.gn中定义的名为modules构建目标，这个modules构建目标依赖芯片开发板解决方案的代码。。⑴处判断芯片和开发板是否是否进行了文件夹解耦，如果开发板路径包含“/board/”,说明soc和board进行了解耦。根据是否解耦，依赖的芯片开发板的构建配置文件路径是不同的，见⑵。

    # board and soc decoupling feature, device_path should contains board
⑴  BOARD_SOC_FEATURE = device_path != string_replace(device_path, "/board/", "")
    ......
    group("modules") {
    deps = [
        "arch",
        "components",
        "kal",
        "kernel",
        "testsuites",
        "utils",
        HDFTOPDIR,
    ]

⑵  if (BOARD_SOC_FEATURE) {
        deps += [ "//device/board/$device_company" ]
        deps += [ "//device/soc/$LOSCFG_SOC_COMPANY" ]
    } else {
        if (HAVE_DEVICE_SDK) {
        deps += [ device_path ]
        }
    }
    }
 class="hljs-button signin active" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">
class="hide-preCode-box">

名为modules构建目标又被libkernel构建目标、进一步被名为kernel的构建目标调用，如下所示。内核的kernel构建目标如何被调用，下一小节分析。

static_library("libkernel") {
  deps = [ ":modules" ]
  complete_static_lib = false
}

group("kernel") {
  deps = [ ":libkernel" ]
}
 class="hljs-button signin active" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">

4、内核代码如何被调用编译的

上文分析了产品解决方案、芯片开发板解决方案如何被调用的。本小节，追踪下内核代码是如何被调用编译的。

在生成的文件out\v200zr\display_demo\build_configs\kernel\liteos_m\BUILD.gn中，会调用名为kernel、build_kernel_image的构建目录。怎么生成的这个文件，需要研究下hb的代码，深入了解下后台的机制，希望后续有时间可以继续深入一些。

    import("//build/ohos/ohos_kits.gni")
    import("//build/ohos/ohos_part.gni")
    import("//build/ohos/ohos_test.gni")

    ohos_part("liteos_m") {
    subsystem_name = "kernel"
    module_list = [
        "//kernel/liteos_m:kernel",
        "//kernel/liteos_m:build_kernel_image",
    ]
    origin_name = "liteos_m"
    variant = "phone"
    }
 class="hljs-button signin active" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">

构建目标build_kernel_image可以生成bin文件，该目标依赖copy_liteos，copy_liteos依赖liteos构建目标，该目标会进一步调用//build/lite:ohos。//build/lite:ohos文件会依次调用各个子系统和部件的构建目标。

    executable("liteos") {
    configs += [
        ":public",
        ":los_config",
    ]

    ldflags = [
        "-static",
        "-Wl,--gc-sections",
        "-Wl,-Map=$liteos_name.map",
    ]

    output_dir = target_out_dir

    if (liteos_kernel_only) {
        deps = [ ":kernel" ]
    } else {
        deps = [ "//build/lite:ohos" ]
    }
    }

    copy("copy_liteos") {
    deps = [ ":liteos" ]
    sources = [ "$target_out_dir/unstripped/bin/liteos" ]
    outputs = [ "$root_out_dir/$liteos_name" ]
    }

    build_ext_component("build_kernel_image") {
    deps = [ ":copy_liteos" ]
    exec_path = rebase_path(root_out_dir)

    objcopy = "${compile_prefix}objcopy$toolchain_cmd_suffix"
    objdump = "${compile_prefix}objdump$toolchain_cmd_suffix"

    command = "$objcopy -O binary $liteos_name $liteos_name.bin"
    command +=
        " && sh -c '$objdump -t $liteos_name | sort >$liteos_name.sym.sorted'"
    command += " && sh -c '$objdump -d $liteos_name >$liteos_name.asm'"
    }
 class="hljs-button signin active" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}"> class="hide-preCode-box">

5、名为public的config

在文件kernel\liteos_m\BUILD.gn中，名为public的config定义如下。⑴处判断芯片和开发板是否是否进行了文件夹解耦，如果开发板路径包含“/board/”,说明soc和board进行了解耦。根据是否解耦，依赖的public的配置集的位置是不同的，见⑵。在芯片、开发板代码目录中的BUILD.gn文件中并没有发现config(“public”)，这个比较奇怪。

    # board and soc decoupling feature, device_path should contains board
⑴  BOARD_SOC_FEATURE = device_path != string_replace(device_path, "/board/", "")

    config("public") {
    configs = [
        "arch:public",
        "kernel:public",
        "kal:public",
        "components:public",
        "utils:public",
    ]

⑵  if (BOARD_SOC_FEATURE) {
        configs += [ "//device/board/$device_company:public" ]
        configs += [ "//device/soc/$LOSCFG_SOC_COMPANY:public" ]
    } else {
        if (HAVE_DEVICE_SDK) {
        configs += [ "$device_path:public" ]
        }
    }
    }
 class="hljs-button signin active" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}"> class="hide-preCode-box">

小结

本文介绍了build lite 轻量级编译构建系统编译构建过程，调用依赖关系等等。因为时间关系，仓促写作，或能力限制，若有失误之处，请各位读者多多指正。

如果大家想更加深入的学习 OpenHarmony 开发的内容，不妨可以参考以下相关学习文档进行学习，助你快速提升自己：

OpenHarmony 开发环境搭建：https://qr18.cn/CgxrRy

《OpenHarmony源码解析》：https://qr18.cn/CgxrRy

系统架构分析：https://qr18.cn/CgxrRy

OpenHarmony 设备开发学习手册：https://qr18.cn/CgxrRy

在这里插入图片描述

OpenHarmony面试题（内含参考答案）：https://qr18.cn/CgxrRy

写在最后

data-report-view="{"mod":"1585297308_001","spm":"1001.2101.3001.6548","dest":"https://blog.csdn.net/maniuT/article/details/139785309","extend1":"pc","ab":"new"}">>
注：本文转载自blog.csdn.net的沧海一笑-dj的文章"https://blog.csdn.net/dengjin20104042056/article/details/96567773"。版权归原作者所有，此博客不拥有其著作权，亦不承担相应法律责任。如有侵权，请联系我们删除。
复制链接
复制链接
相关推荐
发表评论

评论记录：

未查询到任何数据！