Python 脚本给出`:没有这样的文件或目录`
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/19764710/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Python script gives `: No such file or directory`
提问by Bas Jansen
I have several python scripts which work just fine but one script has (as of this morning) started giving me this error if I try to run it from the bash:
我有几个运行良好的 python 脚本,但是如果我尝试从 bash 运行它,一个脚本(截至今天早上)开始给我这个错误:
: No such file or directory
: 无此文件或目录
I am able to run the 'broken' script by doing python script_name.py
and after looking around a bit the general idea that I picked up was that maybe my line ending of the hashbang got changed (silently) so I looked at the line ending of a working script and a broken script via the :set list
option in VI as indicated in this question -> View line-endings in a text file
我可以通过这样做来运行“损坏的”脚本python script_name.py
,在环顾四周后,我发现的一般想法是,也许我的 hashbang 的行尾发生了变化(悄悄地),所以我查看了工作脚本的行尾和通过:set list
VI 中的选项损坏的脚本,如本问题所示 ->查看文本文件中的行尾
Both files appear to end using the same character (a $
) so I am kind of at a loss on how to proceed from here. Specifically, how to actually 'see' the line ending in case the set list
was not the right method.
这两个文件似乎都以相同的字符 (a $
)结尾,所以我对如何从这里开始有点不知所措。具体来说,如果set list
不是正确的方法,如何实际“看到”行结尾。
PS: The script is executable and the shebang is in there, I stated that it's just this 1 script that was working fine before the weekend but it started giving me this error as of this morning.
PS:脚本是可执行的,shebang 就在那里,我说这 1 个脚本在周末之前运行良好,但从今天早上开始,它开始给我这个错误。
-- edit: --
- 编辑: -
Running the script through dos2unix
does get it working again but I would like to know of any way to visualize the line ending somehow in VI(M) or why Geany somehow converted the line endings in the first place (as I never work on a dos/windows system anyhow).
运行脚本dos2unix
确实让它再次工作,但我想知道有什么方法可以可视化在 VI(M) 中以某种方式结尾的行,或者为什么 Geany 首先以某种方式转换了行结尾(因为我从来没有在 dos/无论如何Windows系统)。
采纳答案by rodrigo
From the comments above it looks like you have dos line endings, and so the hashbang line is not properly processed.
从上面的评论看起来你有 dos 行结尾,所以 hashbang 行没有正确处理。
Line ending style are not shown with :set list
in Vim because that option is only used when reading/writing the file. In memory line endings are always that, line-endings. The line ending style used for a file is kept in a Vim per-file option, weirdly called fileformat
.
:set list
Vim中不显示行结束样式,因为该选项仅在读/写文件时使用。在内存中,行尾始终是行尾。用于文件的行结束样式保存在 Vim per-file 选项中,奇怪地称为fileformat
.
To see/change the line ending style from Vim, you can use the following commands:
要在 Vim 中查看/更改行尾样式,可以使用以下命令:
:set fileformat
:set ff
It will show dos
or unix
. You want unix
, of course ;-).
它将显示dos
或unix
。你unix
当然想要;-)。
To change it quickly you can save the file with:
要快速更改它,您可以使用以下命令保存文件:
:w ++ff=unix
Or if you prefer:
或者,如果您更喜欢:
:set ff=unix
And then save the file normally.
然后正常保存文件。
So see all the gory details just do :help fileformat
, :help file-formats
and :help fileformats
所以看看所有的血腥细节就做:help fileformat
,:help file-formats
并且:help fileformats
回答by Filip Malczak
Personally, I find it kinda wrong using direct path to python interpreter. As you dont use windows platform, you should have program env, usually in /usr/bin (/usr/bin/env). Try using following shebang:
就个人而言,我发现使用 python 解释器的直接路径有点错误。由于您不使用 windows 平台,您应该有程序 env,通常在 /usr/bin (/usr/bin/env) 中。尝试使用以下shebang:
#!/usr/bin/env python
Different distros store python binary in /bin or /usr/bin (or some weird locations), and this one makes your script config-independent (as far as possible, here we have possibility that env is stored elsewhere; still - it is less possible that env is not in /usr/bin than that python is mislocated).
不同的发行版将 python 二进制文件存储在 /bin 或 /usr/bin (或一些奇怪的位置),这使您的脚本配置独立(尽可能,在这里我们有可能将 env 存储在其他地方;仍然 - 它更少可能 env 不在 /usr/bin 中,而不是 python 位置错误)。
I had similiar problem (if not exactly the same) and that worked for me.
我有类似的问题(如果不完全相同),这对我有用。
Also, I have both python interpreters (2.7.x and 3.x) installed, so I need to use "python3" argument for env. AFAIR usually distros link different names to different binaries, so "env python" will run python2.7 on my system, "env python3" (also python33, or smth like that) will run p3k, and "env python2" (also python27, etc) will run python 2.7.x. Declaring which version of interpreter should be used seems like a good idea too.
另外,我安装了两个 python 解释器(2.7.x 和 3.x),所以我需要对 env 使用“python3”参数。AFAIR 通常发行版将不同的名称链接到不同的二进制文件,因此“env python”将在我的系统上运行 python2.7,“env python3”(也是 python33,或类似的)将运行 p3k,而“env python2”(也是 python27,等)将运行 python 2.7.x。声明应该使用哪个版本的解释器似乎也是一个好主意。
回答by Giridhara Kalkere
You can also use the dos2unix command to convert the file format
也可以使用 dos2unix 命令来转换文件格式
dos2unix
dos2unix
This helped me to run the python scripts
这帮助我运行 python 脚本
This normally happens when we open files in windows do changes and save it. if you open the file locate the ^M characters at the end of every line
当我们在 Windows 中打开文件进行更改并保存时,通常会发生这种情况。如果您打开文件,请在每一行的末尾找到 ^M 字符
Thanks
谢谢
回答by Dan H
I came across this problem editing my code on Windows, checking it in with git, and checking out and running it on Linux.
我在 Windows 上编辑我的代码时遇到了这个问题,用 git 签入,然后在 Linux 上签出和运行它。
My solution was: tell git to Do The Right Thing. I issued this command on the Windows box:
我的解决方案是:告诉 git 做正确的事。我在 Windows 框上发出了这个命令:
git config --global core.autocrlf true
Modified the files and checked them in; voila, no such problem any more.
修改文件并签入;瞧,没有这样的问题了。
As discussed on the Git documentation.
正如Git 文档中所讨论的那样。