line-endings

I'm trying to create this script that will check the computer host name then search a master list for the value to return a corresponding value in the csv file. Then open another file and do a find an replace. I know this should be easy but haven't done so much in python before. Here is what I have so far... masterlist.txt (tab delimited) Name UID Bob-Smith.local bobs Carmen-Jackson.local carmenj David-Kathman.local davidk Jenn-Roberts.local jennr Here is the script that I have created thus far #GET CLIENT HOST NAME import socket host = socket.gethostname() print host #IMPORT MASTER DATA

with open(fn, 'rt') as f: lines = f.readlines() This reads CR LF text file (WinXP, Py 2.6) with LF line ends. So lines contain '\n' ends. How to get lines as is: for CRLF file get lines with '\n\r' ends for LF file get lines with '\n' ends Instead of the built-in open() function, use io.open() . This gives you more control over how newlines are handled with the newline argument: import io with io.open(fn, 'rt', newline='') as f: lines = f.readlines() Setting newline to the empty string, leaves universal newline support enabled but returns line endings untranslated; you can still use .readlines

I run Windows, and when npm modifies my package.json file, it writes it using Unix-style line endings ( LF ). I want it to use Windows-style line endings ( CR LF ). Is there a global config setting, or even a command-line option to make npm use the correct EOL characters? Update: The even easier fix is to use npm@5.8.0 or newer. Assuming Git, the easiest "solution" to this problem is to use a .gitattributes file to specify that package.json (and now package-lock.json ) should always use LF: # .gitattributes in project root package.json text eol=lf package-lock.json text eol=lf 来源： https:/

I create a CSV file for download by our client using $output = fopen('php://output', 'w'); and using fputcsv() to write data to a CSV file which is downloaded by the client. I am running PHP on Linux and consequently the line endings are not interpreted by many Windows applications. I could write the CSV file to a directory on the server, read it back in and perform a str_replace() from \n to \r\n , but this seems a rather clunky way of solving the problem. Is there a way to perform the conversion without creating a physical file? You could use stream filters to accomplish this. This example

I have a bunch of files. Some are Unix line endings, many are DOS. I'd like to test each file to see if if is dos formatted, before I switch the line endings. How would I do this? Is there a flag I can test for? Something similar? You could search the string for \r\n . That's DOS style line ending. EDIT: Take a look at this Python can automatically detect what newline convention is used in a file , thanks to the "universal newline mode" ( U ), and you can access Python's guess through the newlines attribute of file objects: f = open('myfile.txt', 'U') f.readline() # Reads a line # The

I have a bunch (hundreds) of files that are supposed to have Unix line endings. I strongly suspect that some of them have Windows line endings, and I want to programmatically figure out which ones do. I know I can just run flip -u or something similar in a script to convert everything, but I want to be able to identify those files that need changing first. stimms You could use grep egrep -l $'\r'\$ * You can use the file tool, which will tell you the type of line ending. Or, you could just use dos2unix -U which will convert everything to Unix line endings, regardless of what it started with.

I want to execute bash scripts that happen to use Windows/CRLF line endings. I know of the tofrodos package, and how to fromdos files, but if possible, I'd like to run them without any modification. Is there an environment variable that will force bash to handle CRLF? Perhaps like this? dos2unix < script.sh|bash -s EDIT: As pointed out in the comments this is the better option, since it allows the script to read from stdin by running dos2unix and not bash in a subshell: bash <(dos2unix < script.sh) Here's a transparent workaround for you: cat > $'/bin/bash\r' << "EOF" #!/bin/bash script=$1

I understand that Windows uses CRLF and that it's good practice to let Git change line endings to LF before committing and back to CRLF when checking out. For that reason, I have core.autocrlf set to true. However, contrary to what other threads say (e.g., this ), I am still getting this warning: warning: LF will be replaced by CRLF in [FILE_NAME]. The file will have its original line endings in your working directory. Firstly, I thought setting core.autocrlf to true was supposed to stop these warnings. Secondly, isn't Git supposed to convert LF to CRLF when committing, not the other way