为什么正确的 shell 脚本会给出包装/截断/损坏的错误消息? [英] Why would a correct shell script give a wrapped/truncated/corrupted error message?

查看:21
本文介绍了为什么正确的 shell 脚本会给出包装/截断/损坏的错误消息?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个带有命令的 shell 脚本,看起来它应该可以工作,但它失败了,并显示奇怪的包装/截断/损坏的错误消息.示例:

I have a shell script with a command that seems like it should work, but instead it fails with an odd wrapped/truncated/corrupted error message. Example:

$ ls -l myfile
-rw-r----- 1 me me 0 Aug  7 12:36 myfile
$ cat myscript 
ls -l myfile
$ bash myscript
: No such file or directory

该文件显然存在,但即使我不存在,这也是我通常会收到的那种错误消息:

The file clearly exist, but even if I didn't, this is the kind of error message I would normally get:

$ ls -l idontexist
ls: cannot access idontexist: No such file or directory

注意它如何包含工具名称 ls、一个消息字符串和文件名,而我的没有.

Notice how it includes the tool name ls, a message string and the filename while mine does not.

这是我尝试使用 mysql 时得到的结果.错误消息看起来像是被包装了,现在以引号开头:

Here's what I get if I try to use mysql instead. The error message looks like it's been wrapped, and now starts with a quote:

Command:  mysql -h myhost.example.com
Expected: ERROR 2005 (HY000): Unknown MySQL server host 'myhost.example.com' (0)
Actual:   ' (0) 2005 (HY000): Unknown MySQL server host 'myhost.example.com

这是我应该可以工作的简单 ssh 命令,或者至少给出一个正常的错误消息,但它被包装成以冒号开头并以奇怪的破坏结束:

And here's my trivial ssh command that should work, or at least give a normal error message, but which instead is wrapped to start with a colon and ends with strange clobbering:

Command:  ssh myhost
Expected: ssh: Could not resolve hostname myhost: Name or service not known
Actual:   : Name or service not knownname myhost

为什么会发生这种情况,我该如何解决?

Why does this happen, and how do I fix it?

推荐答案

TL;DR:您的脚本或数据具有 Windows 样式的 CRLF 行尾.

TL;DR: Your script or data has Windows style CRLF line endings.

通过删除回车符转换为 Unix 样式.

Convert to Unix style by deleting the carriage returns.

它们在 cat -v yourscript 的输出中可以被检测为 ^M:

They're detectable as ^M in the output of cat -v yourscript:

$ cat -v myscript
ls -l myfile^M

如果您的脚本没有它们,您的数据可能会 -- 特别是从 ini/csv 文件或 curl 读取时:

If your script doesn't have them, your data might -- especially if reading from ini/csv files or curl:

hostname=$(curl https://example.com/loginhost.txt)
ssh "$hostname"            # Shows strange error
echo "$hostname" | cat -v  # Shows myhost^M

如何删除它们?

设置您的编辑器以使用 Unix 行结尾(又名行终止符"或行尾字符")保存文件,然后重新保存.

How do I remove them?

Set your editor to save the file with Unix line endings, aka "line terminators" or "end-of-line characters", and resave it.

您也可以使用 dos2unix yourscriptcat yourscript | 从命令行中删除它们.tr -d ' ' >固定脚本.

You can also remove them from a command line with dos2unix yourscript or cat yourscript | tr -d ' ' > fixedscript.

如果在您的数据中找到,您可以通过 tr -d ' ' 管道您的源:

If found in your data, you can pipe your source through tr -d ' ':

hostname=$(curl https://example.com/loginhost.txt | tr -d '
')

为什么回车会导致奇怪的错误信息?

回车"字符,又名 CR 或 ,使光标移动到行首,并从那里继续打印.换句话说,它从头开始覆盖该行.这就是它们奇怪地包装的原因:

Why do carriage returns cause strange error messages?

The "carriage return" character, aka CR or , causes the cursor to move to the start of the line, and continue printing from there. In other words, it starts overwriting the line from the start. This is why they wrap strangely:

Intended:     ssh: Could not resolve hostname myhost
: Name or service not known

Written:      ssh: Could not resolve hostname myhost
Overwritten:  : Name or service not known
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  
Result:       : Name or service not knownname myhost

这篇关于为什么正确的 shell 脚本会给出包装/截断/损坏的错误消息?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆