I wrote a python program in Windows env, but it needs to be display and run in Linux env. I realize every line has a ending of \r. I did go into edit -> current file setting-> line ending, and change the option to 'Unix(\n)'. However, I am still seening the same issue, and \r is still there.
Anyone know why?
Once you've changed the line endings in your preferences you need to "Clean" the lines endings; Code > Clean Line Endings.
Related
I have a Python file that is developed under Windows, so it naturally has CR LF line endings. I added the Python shebang on it using #!/usr/bin/env python3 to make it directly executable under Linux. The loader prints out an error message:
/usr/bin/env: ‘python3\r’: No such file or directory
I know I can simply execute the file using python3 x.py, but for various reasons I want to have it with the #! on the first line.
My current solution is to have the first line in a separate file that has Unix line endings, and use cat prefix.py x.py > y.py to generate an executable with mixed line endings. But I would prefer to have the first line being handled differently by ViM. Is that possible?
If I edit y.py I get a ^M on each but the first line since this is a mixed line endings file, so a solution for me would be to not display the ^M and use DOS line endings everywhere, but keep the UNIX line ending on the first line.
The easy and obvious solution is to run dos2unix on the python script
and strip out the insidious \r character.
The hackish solution is to create a symlink literally named
/usr/local/bin/python^M which points to /usr/local/bin/python. This
will let you run all such python scripts in the future without running
dos2unix on them first.
Source: https://natanyellin.com/posts/shebang-python-bad-interpreter-m/
When I pipe output to a file in a cron job using the > operator, it always appends a ^M to the end of the file name. This shows up as a ? when I run ls in the directory but reveals itself as ^M when I edit the file in nano and go to save.
For example this command:
locale > locale.txt
Outputs a file named "locale.txt?" (i.e. "locale.txt^M")
I don't know why it does this, but I'm guessing it has something to do with environment variables. When I use > from a terminal it behaves properly. I've searched Google for this problem but apparently it doesn't like all these special characters in the query so I haven't found anything.
I've tried using mv to change the file name back to normal but it doesn't recognize the ? or the ^M character when I type in the file name.
I've seen that perhaps this is the carriage return "\r" character but I don't know why cron would put a Windows newline on the end of my file name. All help is appreciated. Thanks!
The problem is with the cron or script file itself: it has DOS line separators (CRLF) instead of Unix (LF only). You can fix it using dos2unix.
I exported results in a text file from a program running on Windows 7, and copied the file on Xubuntu 14.04. In a terminal, I ran dos2unix file.txt, which tells me converting file out_mapqtl.txt to Unix format. However, when I look at the file with less, I still see the Windows end-of-line as ^M, and wc -l returns me "0".
I tried several things described here, but none works. I then opened the file in Vim and did :%s/\r/\r/g as explained there, which worked fine. So any idea why dos2unix didn't work? Would there be a way to avoid opening Vim every time?
I know you have gotten this resolved, but I wanted to add a note for reference, based on some testing I've done.
If less is showing ^M, then like Sybren I suspect it is a MAC style ending (\r), not DOS (\r\n). You can determine that easily using cat:
$ cat -e filename
Unix endings (\n) show as $
MAC endings (\r) show as ^M (less shows these)
DOS\Windows endings (\r\n) show as ^M$ (less does not appear to show these)
Use dos2unix to get rid of the DOS (^M$) endings
Use mac2unix to get rid of the MAC (^M) endings - dos2unix won't get rid of these.
I had a file where I had to use dos2unix and mac2unix to get rid of all the non-Unix endings.
\r denotes a carriage return, and on MAC it is used without \n to denote a line break. Are you sure the file is in DOS (\r\n) format and not MAC (\r)?
If VIM really turns out to be the only thing that'll repair your files, you can also invoke it as:
vim somefile.txt +"%s/\r/\r/g" +wq
This will open the file, perform the operation, save it, then quit.
Can you give us an example of the file, so that we can investigate further?
Try this:
tr -d '\r' < file
I have used Notepad++ feature:
Edit>EOL Conversions>Unix(LF).
Now export this file to the Unix machine using pscp.exe.
Let me know if that worked for you.
I'm trying to compile the NIST Biometric Image Software, and I have been having trouble all day. I finally got the source checked out right, and I installed cygwin with no problems (I have used it in the past), but when I went to compile, I get this error:
$ sh setup.sh </cygdrive/c/NBIS> [--without-X11]
setup.sh: line 94: syntax error near unexpected token `$'in\r''
'etup.sh: line 94: ` case $1 in
Now I'm sure any advanced coder would head to the setup.sh and look for problems, but I'm not really much of a coder (I'm only compiling this because there are no pre-compiled packages) so I don't know what to do. I didn't install any libraries with cygwin, I just left everything default. I'm trying to follow the NBIS manual, but I don't really understand it that well and so I'm struggling badly. Maybye taking a look at it you may notice something I missed: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=51097
run
sed -i 's/\r//' setup.sh
to fix your line endings
That's a symptom of line-ending mismatch.
To convert setup.sh to Unix line endings on Cygwin, use
dos2unix setup.sh
Easy way to convert example.sh file to unix is use NotePad++ (Edit>EOL Conversion>UNIX/OSX Format)
You can also set the default EOL in notepad++ (Settings>Preferences>New Document/Default Directory>select Unix/OSX under the Format box)
Windows uses two characters (CR and LF, or \r\n) to mark the end of a line in a text file. Unix, Linux, and (by default) Cygwin use a single LF or '\n' character. Some Cygwin tools are able to deal with either format, but sh typically can't.
It looks like setup.sh uses Windows-style line endings -- or at least line 94 does.
I didn't find the download for the sources, but if they're distributed as a zip file, you might need to extract them using the Cygwin unzip command with the -a option, so any line endings are automatically converted.
But I suspect there's more to it than that. The distributed setup.sh file shouldn't have had any Windows-style line endings in the first place, and if it did, I don't know why the problem wouldn't show up until line 94.
If you can post the URL for the source download, I'll take a look at setup.exe.
In pycharm you can quickly change the line endings by clicking on the letters CRLF at the bottom right of the screen and selecting LF.
I often have to edit script files, the interpreter for which treats files that have an EOL marker on the last line of the file as an error (i.e. the file is treating CRLF as "newlines", not as "line endings").
Currently, I open these files in Vim using binary mode (-b on the command line). It autodetects the lack of EOL on the final line and sets the "noeol" option appropriately, which prevents it from writing an EOL on the last line.
Because the file has CRLF line endings, I get lots of ^Ms at the end of my lines (because it interprets only Unix-style line endings in binary mode, it seems). I can't open it in text mode because the "noeol" option is ignored for non-binary files.
This is very annoying, and I always have to remember to manually type the ^M at the end of each line! Is there some way I can force it to accept DOS-style line endings in binary mode, or force it to listen to the EOL option in text mode?
can you run the dos2unix command before editing?
Yes, you shouldn't need to manually enter a ^M on every line; that would be tedious! Try entering this:
:set ff=dos
You may also find this article useful: change end-of-line format for dos-unix
On further review, a global search and replace is probably neccessary, so give this a shot. (I tested this out earlier today and it worked on a unix file being edited with gvim in Windows XP, and not in binary mode.)
:%s/^M//g
Type that command exactly as shown except for the ^M, which is a special character. The way you produce it is to press Ctrl and v together then hit Enter (let up on CRTL+V prior to hitting enter)