Yesterday helped people debug a Perl program. The program runs under the Windows platform, the purpose is to read the string from the parameter file, each string is single line, and after reading, go off the line. Probably code Similar:
$ Name =
Chomp ($ Name);
Print ("$ Name");
The problem now is that after being read out, printing is empty. Moreover, if the read string is "FRED", it is found that $ name is not equal to "fred", which causes the following program logic unable to carry.
This problem, later discovered that the cause of the error is not in the program, but the parameter file used is built under Windows, so the wrapper is "/ r / n" instead of UNIX standard "/ n".
If there is a line in the file is "fred", $ name is "FRED / R / N" after reading, and the chomp has dropped the last "/ n" of $ name "/ n", and the value of $ name is "FRED / R) ".
Generally speaking, "/ r" means that putting the input pointer back to the head, "/ N" means that the input pointer is placed in the next line. So when printing $ name, since there is a "/ r" behind, the cursor returns to the head, and the "fred" that has been output, the result is an empty string.
In the subsequent program, the $ name is always with "/ r", so it is not possible to perform program logic. Naturally leading an error.
In fact, if this parameter file is converted into UNIX style with dos2unix, the program is normal.
In fact, this question says that it is Perl's Windows version without considering Week, which is a problem with CHOMP. For example, the libc under the Windows platform will inevitably interpret "/ N" as "/ r / n", this platform-related thing, theoretically, should not be concerned by programmers.
But when you are struggling, you must demand programmers.
Similar questions, under Linux is very common, many of Linux will assume "/ n" as a newline, then "/ r / n" in the Windows file is a disaster.
For example, people who write scripts may encounter such a difficult to understand, execute the Run script, the result:
~ # ./run
: Bad Interpreter: No Such File or Directory
The most likely reason here is that the Run script is Windows style, so the first line of the kernel script found a "/ R" behind the host shell file name, natural EXEC will fail, then print the error message, it is negotiable I want
Printf ("% s: Bad Interpreter: no so file or directory / n", shell_name);
However, because there is a "/ R" behind the shell_name, after printing shell_name, returning to the head, printing the following information. As a result, this inexplicable error prompt.
In addition to scripts, if you use the AutoConf / Automake tool, then configure.in/makefile.am These need to be processed should be guaranteed to be "/ N".
Finally, let's talk about the tool problem. Under Windows, many editors support file format conversions between UNIX and Windows, such as Ultra-Edit32 under Linux, is Dos2Unix / Unix2dos. What needs to be explained is that VIMs that can be supported by two formats, which will be displayed normally, rather than "/ r" is displayed as ^ M like an old version, which will not easily find problems, so pay attention to VIM The following prompts, if [DOS] words appear in the prompt, then this file is the file of the Windows style.
