開玩笑的啦，沒有LFCR這種沙雕東西 為什麼突然想起來寫這個呢，是因為先前照著shell畫llehs的時候，總報錯，改正了以後又因為看不見而在上一篇博客上沒有寫明，所以過來好好寫一寫咯。 可以看出報錯裡面出了各種稀奇古怪的東東：無法識別#!bin/sh以及覺得每一行代碼後面都多了\r 故事開始於上古 ...
開玩笑的啦，沒有LFCR這種沙雕東西
為什麼突然想起來寫這個呢，是因為先前照著shell畫llehs的時候，總報錯，改正了以後又因為看不見而在上一篇博客上沒有寫明，所以過來好好寫一寫咯。
可以看出報錯裡面出了各種稀奇古怪的東東：無法識別#!bin/sh以及覺得每一行代碼後面都多了\r
故事開始於上古時期，那個時期的人們還在用打字機幫助自己不用筆。最早的時候打字機是純機械不用電的，按下Enter是沒有辦法讓游標挪動到下一行的（事實上那個時候既沒有Enter也沒有游標啦），需要人們拉一下手柄讓傳動裝置把紙張往上面挪一下，然後戳一個釋放按鈕把打字頭彈回紙張最左邊。這兩個操作被翻譯作換行（LineFeed, LF）和回車（Carriage Return, CR）。
當今世界的QWERTY鍵盤則是由後來大型機、小型機出現以後興起的電傳打字機（Teletype, TTY）繼承而來，此時，ENTER、Ctrl之類的現代案件才被加上去。
這就引出了今天我們的主角：LF和CR。雖然現在的電腦已經不用喂紙就能輸入輸出，可是這兩個很久以前就定義，並被寫進了ASCII編碼表的功能字元還是被繼承了下來，最直觀的體現就是我們在Word裡面看到的小小的箭頭符號
Word很形象地告訴了我們什麼是換行什麼是換行回車，雖然本質上沒啥區別
說了這麼多看似無關的歷史話題，你可能會問，為什麼他會影響到我們的腳本呢？原因在這裡：在Microsoft家族中，無論是CMD、POWERSHELL還是其他東東，他們都使用LFCR(\n\r)來當作“該使用下一行”的識別依據；然而，Linux之類的Unix、類Unix系統則使用LF(\n)當作本行結束，而把CR當作執行命令的標誌（如果在shell裡面）；MAC OSX則使用CR當作本行結束。在文本文檔里倒無所謂（最多就是排版混亂），可是在代碼里，這小小的換行符就變成編譯器不認識的怪東西了。上面圖片中的^M 和\r都是 CR 先生的傑作。
這個故事告訴我們一個道理，如果你是跨平臺開發者，一定要用一個能簡便更換換行符的開發工具！而且一些奇奇怪怪的問題，很有可能是因為換行符這樣的小細節導致的！
VS Code 裡面雖然很不起眼，但是很重要的小功能
