2015-02-21 1 views
11

में यूनिक्स एलएफ मुद्दों के लिए विंडोज सीआरएलएफ Vagrant का उपयोग कर कुछ वीएम प्रावधान पर काम कर रहा हूं। यहाँ की स्थिति है:विंडोज सीआरएलएफ वैगेंट

होस्ट: विंडोज 7 (64-बिट)

अतिथि: Ubuntu 14.04 (64-बिट)

मैं एक मुद्दा कन्वर्ट करने के लिए CRLF लाइन अंत हो रही हो रहा है एलएफ के लिए। यह साझा मशीन में बैश स्क्रिप्ट को अतिथि मशीन के भीतर विफल होने का कारण बन रहा है (नीचे देखें)।

[email protected]:/vagrant/bin$ sudo bash build-ubuntu-14.04.1-c 
make.sh 
build-ubuntu-14.04.1-cmake.sh: line 5: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 19: $'\r': command not found 
: invalid option04.1-cmake.sh: line 21: set: - 
set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...] 
build-ubuntu-14.04.1-cmake.sh: line 22: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 24: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 26: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 29: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 36: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 42: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 46: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 48: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 50: $'\r': command not found 
build-ubuntu-14.04.1-cmake.sh: line 226: syntax error: unexpected end of file 

मेरी Vagrantfile में मैं गलत पर खोल privisioner पैरामीटर binary निर्धारित किया है।

# Provision the VM 
ubuntu.vm.provision "shell" do |s| 
    # replace Windows line endings with Unix line endings 
    s.binary = false 

    s.inline = "sudo apt-get update; 
       sudo bash vagrant/bin/build-ubuntu-14.04.1-cmake.sh" 
end 

प्रति Vagrant प्रलेखन के रूप में:

binary (बुलियन) - Vagrant स्वचालित रूप से यूनिक्स लाइन अंत के साथ विंडोज लाइन अंत बदल देता है। यदि यह सच है, तो वाग्रेंट ऐसा नहीं करेगा। डिफ़ॉल्ट रूप से यह "झूठा" है। यदि शेल प्रावधान WinRM पर संचार कर रहा है, तो यह "सत्य" पर डिफ़ॉल्ट है।

यहां क्या समस्या है? क्या मैं प्रलेखन में कुछ दिख रहा हूं?


अद्यतन 1: मैं के रूप में this Stack Overflow answer में सिफारिश की अपने स्थानीय Git सेटिंग को संपादित करने की कोशिश की है, लेकिन कोई किस्मत। इसके अलावा, मैं इस परियोजना के मूल में एक .gitattributes फ़ाइल को शामिल किया है और कहा कि फाइल में निम्नलिखित:

# detect all text files and automatically normalize them (convert CRLF to LF) 
*  text=auto 

मैं भी "Dealing with line endings" Git द्वारा प्रदान की दस्तावेज़ से अधिक पढ़ा है। जब मैं अपने भंडार सीआरएलएफ को प्रतिबद्ध करता हूं तो एलएफ में परिवर्तित हो जाता है, लेकिन जब मैं विंडोज वर्कस्पेस में चेकआउट परिवर्तन करता हूं तो एलएफ को सीआरएलएफ में परिवर्तित कर दिया जाता है। यह मेरा सटीक व्यवहार है जो मैं अपने गिट वर्कफ़्लो में चाहता हूं। मुद्दा वग्रेंट के साथ है। binary ध्वज जो मैंने सेट किया है वह दस्तावेज़ीकरण का वर्णन नहीं करता है।


अद्यतन 2: बदलने s.binary = true समस्या का समाधान हो। हालांकि, मुझे लगता है कि प्रलेखन में शब्द को फिर से संबोधित किया जाना चाहिए। दस्तावेज़ीकरण में कहा गया है कि "यदि यह [ध्वज] सत्य है, तो Vagrant ऐसा नहीं करेगा [सीएफएलएफ को एलएफ में बदलें]।" जैसा कि मैं समझता हूं, वग्रंट इस ध्वज सेट होने पर सीएफएलएफ को एलएफ में बदल देगा। हालांकि, सीआरएलएफ एलएफ में बदल गए हैं यदि यह सत्य पर सेट है।

+1

आपको इसे हल करने के बाद से आपको अपने प्रश्न का उत्तर देना चाहिए। साथ ही, 'गिट' की लाइन एंडिंग स्टफ का केवल फाइल सिस्टम और गिट डेटाबेस के बीच चलने वाले डेटा पर असर पड़ता है। यह आपके साझा फ़ोल्डर पर एक रिकर्सिव डॉस 2unix नहीं करेगा। यह प्रभावी होगा यदि आपके पास विंडोज़ और लिनक्स के लिए एक अलग काम करने वाली निर्देशिका थी, और हालांकि, 'गिट पुल' के साथ उनके बीच कोड ले जाया गया। आपके पास एलएफ एंडिंग के साथ कैननिकल प्रतिबद्ध संस्करण हो सकता है, और सीआरएलएफ लाइन एंडिंग के साथ विंडोज चेकआउट हो सकता है। (और लिनक्स चेकआउट बिना रूपांतरण के, या मजबूर-से-एलएफ अंतराल के साथ।) –

+0

उस समय आप किस संस्करण का उपयोग कर रहे थे? –

+0

@DeanRather मैं नवीनतम का उपयोग कर रहा था, '1.7.1' – Jonathan

उत्तर

5

जैसा कि मेरे अपडेट में ऊपर निर्दिष्ट किया गया था, s.binary = true बदलकर समस्या को हल किया गया। हालांकि, मुझे लगता है कि प्रलेखन में शब्द को फिर से संबोधित किया जाना चाहिए। दस्तावेज़ीकरण में कहा गया है कि "यदि यह [ध्वज] सत्य है, तो वाग्रेंट ऐसा नहीं करेगा [सीएफएलएफ को एलएफ में बदलें]।" जैसा कि मैं समझता हूं, वगेंट सीएफएलएफ को एलएफएस में नहीं बदलता है, तो यह ध्वज सेट हो जाएगा। हालांकि, सीआरएलएफ एलएफ में बदल गए हैं यदि यह सत्य पर सेट है।

6

आप सही हैं, documentation about binary भ्रामक था। मैंने a pull-request का प्रस्ताव दिया है और इसे दस्तावेज़ पृष्ठ पर ठीक किया गया है।

तो अब यह कहा गया है:

binary (बुलियन) - Vagrant स्वचालित रूप से विंडोज लाइन अंत यूनिक्स लाइन अंत के साथ बदल देता है। यदि यह false है, तो Vagrant यह नहीं करेगा। डिफ़ॉल्ट रूप से यह false है। यदि शेल प्रावधान WinRM पर संचार कर रहा है, तो यह true पर डिफ़ॉल्ट है।

तो यूनिक्स लाइन अंत के साथ विंडोज लाइन अंत बदलने के लिए (CRLF) (LF) आप निर्धारित करने की आवश्यकता:

s.binary = true 

वैकल्पिक समाधान में शामिल हैं:

  • बदलने लाइन मैन्युअल रूप से अंत:

    • dos2unix आदेश,
    • ex आदेश का उपयोग करता है, उदा का उपयोग कर

      ex +'bufdo! %! tr -d \\r' -scxa *.sh 
      
  • अपने bashrc फ़ाइल में निम्नलिखित पंक्तियां जोड़ें (जैसे ~/.bashrc) gist:

    export SHELLOPTS 
    set -o igncr 
    

आप अपने कोड वर्ज़निंग के लिए Git उपयोग कर रहे हैं, आपको चाहिए:

  • या false पर core.autocrlf विकल्प सेट करके लाइन एंडिंग को सही तरीके से संभालने के लिए ओएस एक्स पर गिट कॉन्फ़िगर करें।

    आप Windows पर Git स्थापित किया है, सबसे आम गलती चेकआउट विंडोज शैली का चयन करने के स्थापना के दौरान विकल्प है, तो आप चाहिए इसे फिर से स्थापित करने और एक चुनें: चेकआउट के रूप में है और यूनिक्स शैली के लिए प्रतिबद्ध लाइन एंडिंग्स (core.autocrlfinput पर सेट है) या चेकआउट जैसा है, (core.autocrlffalse पर सेट है) के रूप में कार्य करें।

  • , अपने भंडार (.gitattributes) में Git सामान्य फ़ाइल बनाने जो, कोई CRLF लाइन अंत स्थान पर हैं सुनिश्चित करता है न चेकआउट पर और न ही चेकइन के विचार करें उदाहरण के लिए:

    *.sh  text eol=lf 
    

    तो अपने प्रावधानीकरण स्क्रिप्ट संपादन लोग , वे लाइन के अंतराल तोड़ नहीं देंगे।

  • यह भी पढ़ें: Dealing with line endings गिटहब सहायता पर।

  • संबंधित: '\r': command not found - .bashrc/.bash_profile
+0

यह अच्छी खबर है! धन्यवाद। – Jonathan

संबंधित मुद्दे