Is there an option to tell SharpDevelop (specifically version 3.2.1) to always save files in unix line endings?
I want it to also automatically convert all dos endings to unix endings when it saves.
oops. I just missed the option the first time I looked.
tools > options > General > Load/Save ; there you will see a dropbox where you specify 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/
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.
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 am migrating my code from UNIX to LINUX and I know unix2dos command is not available in SUSE 11.0. Please let me know if
alias unix2dos='recode lat1..ibmpc'
will have the same effect as that of unix2dos?
I'm not sure about recode, but sed -i 's/$/\r/' would do the same thing as unix2dos.
Using recode seems risky, it's used for converting character sets, not just changing newline characters. I haven't used recode but I'm afraid that you could break your files if they are encoded in e.g. UTF-8 instead of Latin1.
I don't know what packages are found in SUSE, but perhaps there is one of the alternatives to unix2dos, like todos (on Debian found in package tofromdos).
Using sed as other suggested should work well. If you are really worried about performance, you could compare sed's performance to awk '{print $0 "\r"}' - I can't say for sure which will be faster in your case but it won't hurt to measure both on a sample of your files.
Load your file(s) into vim, then
:set ff=dos -- Changes to DOS line endings (CRLF)
:set ff=unix -- Changes to unix line endings (LF)
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.