The invisible byte that changes a command
A Windows text file usually ends each line with two bytes: a carriage return (`CR`) and a line feed (`LF`). Unix-style systems use just `LF` to mark the end of a line. When a script moves between them without conversion, the Unix reader stops the line at `LF` but may leave the preceding `CR` attached to its contents.
That leftover character is hard to see in an ordinary text editor, but a computer still treats it as part of the text. A command that looks like `echo hello` can effectively end with an extra character, so the shell may search for a command whose name includes that invisible mark and fail to find it.
Why the first line can break everything
Many scripts begin with a shebang: a line such as `#!/bin/sh` that tells Unix which program should run the file. With Windows line endings, the system can read the interpreter’s name as `/bin/sh` followed by a carriage return. That is a different path from `/bin/sh`, so the script may fail before its commands even start, often with a confusing “not found” error.
The file has not necessarily been corrupted in any visible way; its line-ending convention simply does not match what the Unix tools expect. Converting the script to Unix line endings removes the extra carriage returns. After that, the shebang and command names end where Unix expects them to, and the same script can run normally.
