首先介绍下,在ASCII中存在这样两个字符CR(编码为13)和 LF(编码为10),在编程中我们一般称其分别为’\r’和’\n’。他们被用来作为换行标志,但在不同系统中换行标志又不一样。下面是不同操作系统采用不同的换行符: Unix和类Unix(如Linux):换行符采用 \n Windows和MS-DOS:换行符采用 \r\n Mac OS X之前的系统:换行符采用 \r Mac OS X:换行符采用 \n Linux中查看换行符 第一种使用"cat -A [Filename]" 查看,如下图所示,看到的为一个Windows形式的换行符,\r对应符号^M,\n对应符号$.
前段时间,有个朋友碰到由于Windows的换行符和Linux换行符不一样,导致程序编译不通过。这个问题之前自己也碰到过,网上资料也蛮多,不过还是借此总结总结,因为发现总结+实践的方式能够让自己更好的提升。
大多数原因是因为 shell 脚本是在 Windows 编写导致的换行问题,具体原因是 Windows 的换行符号为 CRLF(\r\n),而 Unix\Linux 为 LF(\n)。
dos2unix 是将 Windows 格式文件转换为 Unix/Linux 格式的实用命令。
在 ASCII 码中,我们会看到有一类不可显示的字符,叫控制字符,其中就包含\r 和 \n 等控制字符。
我们有时在Windows编辑的文件,放到了Linux环境中,打开文件,可能发现每行结尾多了一个“^M”,导致一些在Windows下能执行的解析程序,放到了Linux中,执行就会报错,问题就出在这个"^M"。
在ASCII码中,我们会看到有一类不可显示的字符,叫控制字符,其中就包含\r 和 \n 等控制字符。
不同操作系统 换行符 标准不统一, 秦始皇听了都要落泪。 多少年前, 我曾也被这东西坑过无数次, 往事不堪回首。
使用 Git 进行版本管理时,可能会遇到换行符不一致的问题。这个问题是由于不同的操作系统使用不同的换行符导致的。例如,Windows 系统使用 CRLF(回车换行)作为换行符,而 Linux 和 MacOS 系统使用 LF(换行)作为换行符。
Windows下是CRLF(\r\n或0d0a),Linux下是LF(\n或0a)。在Linux下有时会遇到从Windows过来的文本文件,这些文件带了Windows换行符,Linux下进行脚本处理时有可能会出一些莫名其妙的错误。因此需要将这些文件转换为Linux换行符。
Git提供了一个换行符检查功能(core.safecrlf),可以在提交时检查文件是否混用了不同风格的换行符。这个功能的选项如下:
windows和Linux的换行符存在差异,Windows下写的脚本拷贝到Linux系统,会导致#!/bin/bash后面多个^M,因此提示找不到文件。
什么是数据?数据是指对客观事件进行记录并可以鉴别的符号,是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。它是可识别的、抽象的符号。数据可以是连续的值,也可以是离散的。
CRLF, LF 是用来表示文本换行的方式。CR(Carriage Return) 代表回车,对应字符 '\r';LF(Line Feed) 代表换行,对应字符 '\n'。由于历史原因,不同的操作系统文本使用的换行符各不相同。主流的操作系统一般使用CRLF或者LF作为其文本的换行符。其中,Windows 系统使用的是 CRLF, Unix系统(包括Linux, MacOS近些年的版本) 使用的是LF。
在各操作系统下,文本文件所使用的换行符是不一样的。UNIX/Linux 使用的是 0x0A(LF),早期的 Mac OS 使用的是0x0D(CR),后来的 OS X 在更换内核后与 UNIX 保持一致了。但 DOS/Windows 一直使用 0x0D0A(CRLF)作为换行符。Git提供了一个“换行符自动转换”功能。这个功能默认处于“自动模式”,当你在签出文件时,它试图将 UNIX 换行符(LF)替换为 Windows 的换行符(CRLF);当你在提交文件时,它又试图将 CRLF 替换为 LF。Git 的“换行符自动转换”功能听起来似乎很智能、很贴心,因为它试图一方面保持仓库内文件的一致性(UNIX 风格),一方面又保证本地文件的兼容性(Windows 风格)。但遗憾的是,这个功能是有 bug 的,而且在短期内都不太可能会修正。
经过一番检索我发现,在使用命令行时,如果samplelist文件中的文本使用了DOS换行符(\r\n),则可能会导致输出结果不正确。
Shell是一个命令行解释器,它为用户提供了一个向Linux内核发送请求以便运行程序的界面系统级程序,用户可以用Shell来 启动、挂起、停止甚至是编写一些程序。
水电费在git中,我们使用git config 命令用来配置git的配置文件,git配置级别主要有以下3类:
前几天编写的shell小脚本,测试自动安装MySQL的,今天测试运行,然后出现如下错误
将文件导入到Hive中,需要文件编码格式为UTF-8,\n为换行符,否则就需要进行预处理。处理过程分为两部分:编码格式、换行符。
其实有很多种请客。git status可能有一些不同的原因,但git diff可能没有。
不同操作系统使用的换行符是不一样的。Unix/Linux使用的是LF,Mac后期也采用了LF,但Windows一直使用CRLF【回车(CR, ASCII 13, \r) 换行(LF, ASCII 10, \n)】作为换行符。
程序员免不了要与windows和linux打交道,在windows写启动脚本时要要用到bat,而在linux时则要使用到shell脚步。shell脚步具有严格的格式,稍不注意就会出问题,今天分享一个小经验,但是受益程序员终身。下面是网上找来的一段shell脚本:
此文主要分享了如何将自己博客园的文章自动导出到 Markdown 文档进行存储,以便在本地进行归档管理,程序中也对文章的分类、tag、代码块以及文章中的图片进行了保存处理,以便上传到自己的图。 整理后的 Markdown 可以在本地整理成册或者发布到自己的个人博客上,比如我使用 Markdown 书写的 个人博客 。 文章目录 支持的功能 基本原理 几个知识点 将 HTML 转换成 Markdown 注意 Mac 和 Windows 以及 Linux 下的换行的区别 文章分类、tag 的获取 文章中图片保存
在计算机还没被发明之前,人们通过「电传打字机」(Teletype Model 33)来打印文字,每秒可以打印 10 个字符。然而,该机器存在一个问题:在打完一行换行的时候,要用去 0.2 秒,正好可以打两个字符,如果在这 0.2 秒里,又有新的字符传过来,那么该字符将会丢失。
在很多UNIX说明文件里,都有RLF控制字符,当我们把说明文件的内容输出成纯文本文件时,控制字符会变成乱码,col命令则能有效滤除这些控制字符。
昨天,同事告诉我发现一个诡异的问题,grep 无法搜索 shell 中的变量,着实很惊讶。到他所说的服务器上试了下,还真是不行! 大概就是这样一个要求: ①、有个文本为 userid.txt,里面每一行一个用户 id,类似如下: 0001 0003 0005 0007 0009 ②、另外还有一个文本为 record.txt,里面是所有用户的操作记录,一行一条,并且包含有 id,类似如下: [12 11 2014 11:03,198 INFO] userId:0001 gilettype:3 [12 11 2
git的一些安装和基本的配置比较简单,我们安装完毕后。经常会针对Git配置一些全局信息,或者围绕某个本地仓库做一些配置。例如配置项目提交的作者邮箱等信息。
Windows平台下 如果以“文本”方式打开文件,当读取文件的时候,系统会将所有的”/r/n”转换成”/n”;当写入文件的时候,系统会将”/n”转换成”/r/n”写入。 如果以”二进制”方式打开文件,则读/写都不会进行这样的转换。
项目中可能出现这么一种情况,A提交的代码,B使用Git拉下来之后都是ESlint报的警告。
一直对换行符这个东西概念比较模糊,直到最近花了一点时间仔细研究了一下,才彻底搞清楚这个问题,本文前面介绍部分是外文转载,后面例子是个人总结,希望能对大家有一些帮助。 回车符号和换行符号产生背景 关于“回车”(carriage return)和“换行”(line feed)这两个概念的来历和区别。 在计算机还没有出现之前,有一种叫做电传打字机(Teletype Model 33)的玩意,每秒钟可以打10个字符。但是它有一个问题,就是打完一行换行的时候,要用去0.2秒,正好可以打两个字符。要是在这0.2秒里面,
在Windows环境下用Notepad++写了个shell脚本,上传到Linux平台后运行报错如下:
描述:nano 是一个字符终端的文本编辑器,有点像DOS下的editor程序。它比vi/vim要简单得多,比较适合Linux初学者使用。某些Linux发行版的默认编辑器就是nano。
\r:全称:carriage return (carriage是“字车”的意思,打印机上的一个部件)
原来没有仔细注意C++读写文件的二进制模式和文本模式,这次吃了大亏。(平台:windows VS2012) BUG出现: 写了一个程序A,生成一个文本文件F保存在本地,然后用程序B读取此文件计算MD5值。 将该文件上传到服务器,再用程序B将文件从服务器上下载下来计算MD5值,神奇的发现两次计算的MD5值不一样,文件被谁改了?? 排除问题: 1.首先对比了生成文件F和上传到服务器的文件,发现文件复制过程无差错,是同一个文件。 2.用程序B下载文件F后,保存在本地,发现文件与原文件F不一致,对比二进制发现每行
原因是换行机制不一样,Unix下是\n(0A),mac下是\r(0D),win下是\r\n(0D0A)。导致的结果是在程序中会造成一定的混乱。
linux文件到windows中出现编译错误,不一定提示conflicting types for错误,可以通过转码的方式修改错误
pico是一个简单易用、以显示导向为主的文字编辑程序,具有pine电子邮件编写器的风格。在现代Linux系统上,nano即pico的GNU版本是默认安装的,在使用上和pico一模一样。
sed命令是利用脚本来处理文本文件,可依照脚本的指令来处理、编辑文本文件,主要用来自动编辑一个或多个文件、简化对文件的反复操作、编写转换程序等。
这个错误的意思,就是文件中存在两种环境的换行符,git 会自动替换 CRLF 为 LF ,所以提示警告。
到目前为止,我们已经阐述了 Git 基本的运作机制和使用方式,介绍了许多 Git 提供的工具来帮助你简单且有效地使用它。 在本章,我们将演示如何借助 Git 的一些重要的配置方法和钩子机制,来满足自定义的需求。 通过这些工具,它会和你、你的公司或你的团队配合得天衣无缝。
Editor的说明信息,翻译过来的意思大概是:通过调整字体、高亮、缩进等方式,个性化源代码的风格;通过行号、插入符号、源代码的缩进,设定代码模板,文件编码配置来定制化编辑器
在windows 中编辑的文件上传到 Linux 后,使用 curl 等工具调用时会报一个curl: (3) Illegal characters found in URL 的错误,这是因为 Linux 与 Windows 在文本文件中添加的换行符不一样。Linux 在每行只会添加一个\n,Windows系统会在每行后加入\n\r, 所以在 Windows 下的文件放到 Linux上时就会出这个问题。
echo 在linux帮助文档的描述是显示一行文本,类似于python和java等编程语言中的print语句,实际上它的作用不仅仅如此。可以使用man echo查看详细的参数说明。
工欲善其事必先利其器,工作中在使用Git之前,最先做的一件事就是安装它,但是因为不同的开发需求,工作中可能会用到的系统不一样,有使用Linux的,有使用Mac的,也有使用Windows的。不过Git在这几个系统中都有比较好的支持,只要能够进行正确的安装和配置都可以正常使用Git,本章主要介绍Git在Windows下的安装。
利用今天一天的时间,研究了一下ANSI编码和Unicode编码的不同,下面把我的研究成果写下来,以备日后参考。
1)、Linux用户(以Ubuntu为例) sudo apt-get install openssl
领取专属 10元无门槛券
手把手带您无忧上云