PowerShell 3 - अंत में DLR पर!

जो लोग टैंक में हैं, उनके लिए हम आपको सूचित करते हैं: PowerShell 3 को आधिकारिक तौर पर विंडोज 8 के साथ जारी किया जाएगा। CTP विंडोज 8 डेवलपर प्रीव्यू (कॉन्फ्रेंस में / बिल्ड / सितंबर 2011 में माइक्रोसॉफ्ट से) के रिलीज के साथ दिखाई दिया। दूसरी CTP रिलीज़ क्रिसमस से ठीक पहले दिखाई दी।
कई महीनों तक मुझे PowerShell 3 के साथ खेलने का अवसर मिला और अब मैं आपको अपने छापों के बारे में बताना चाहता हूं।

परिचय

इस रिलीज़ के साथ बहुत कुछ जारी किया गया है, लेकिन मेरे लिए ( और मुझे - लगभग। अनुवाद। ) मुख्य बदलाव यह है कि अब पावरशेल डायनेमिक भाषा रनटाइम पर आधारित है, अर्थात्। ऐसे वातावरण पर, जो आपको सामान्य भाषा रनटाइम (CLR) में डायनेमिक भाषा ( उदा। आयरनरुबी, आयरनपाइथन - लगभग अनुवाद ) लागू करने की अनुमति देता है, जो बदले में .NET फ्रेमवर्क का मूल है। DLR .NET फ्रेमवर्क पर चलने वाली गतिशील भाषाओं को विकसित करना आसान बनाता है। बेशक, PowerShell मूल रूप से .NET फ्रेमवर्क में एक गतिशील भाषा थी, लेकिन यह पहले दिखाई दिया, इसलिए ऐतिहासिक रूप से यह DLR से संबंधित नहीं था। और अब, केवल अब PowerShell को अंततः DLR में पोर्ट कर दिया गया है।
हालाँकि PowerShell 3 को DLR का उपयोग करके कार्यान्वित किया जाता है, लेकिन यह आयरनपाइथन या आयरनरुबी की तुलना में हर दृष्टि से एक गतिशील भाषा नहीं है। मुझे DLR के लिए प्रलेखन से कुछ आरेख दें।

DLR अवलोकन

आरेख पर आप तीन मुख्य खंड (कोडप्लेक्स पर डीएलआर कार्यान्वयन में) देख सकते हैं: होस्टिंग, रनटाइम और भाषा। लेकिन हो सकता है कि जैसा भी हो, उन सभी को .NET फ्रेमवर्क 4.0 CLR में पोर्ट नहीं किया जाता है।

पोर्ट किए गए डीएलआर

* गुलाबी रंग में हाइलाइट किया गया आरेख है जो CLR 4.0 में रखा गया है - लगभग। ट्रांस।
PowerShell 3 सीएलआर में पोर्ट किए गए सभी (या लगभग सभी) का लाभ उठाता है, लेकिन अनिच्छा के कारण, विकास टीम ने ऑपरेटिंग सिस्टम के बाकी DLR को पोर्ट करना शुरू नहीं किया। इस प्रकार, PowerShell 3 में साझा एएसटी और अभिव्यक्ति पेड़ों के साथ-साथ डायनामिकऑब्जेक्ट और कॉल साइट कैशिंग रनटाइम के साथ DLR भाषा कार्यान्वयन कार्यक्षमता का उपयोग किया जाता है, लेकिन सामान्य होस्टिंग - ScriptRuntime, ScriptScope, ScriptSource या CompiledCode से कुछ भी उपयोग नहीं होता है।
इसका अर्थ है कि आप PowerShell के लिए API की मेजबानी करने वाले IronRuby और IronPython स्क्रिप्ट का उपयोग नहीं कर सकते। लेकिन आप उसी API का उपयोग कर सकते हैं जिसका उपयोग PowerShell 2 होस्टिंग के लिए किया जाता है, केवल PSObject के बजाय C # में आउटपुट आउटपुट करते समय आपको डायनामिक का उपयोग करने की आवश्यकता होगी। और यह वास्तव में एक महत्वपूर्ण बात है।
मैं उन सभी परिवर्तनों पर विचार नहीं करना चाहूंगा जो आप PowerShell 3 में सामना करेंगे और जो DLR में परिवर्तन का प्रत्यक्ष परिणाम थे। हालाँकि, कुछ गंभीर चीजें हैं जिन पर आपको ध्यान देने की आवश्यकता है। सबसे पहले, आप प्रदर्शन और प्रदर्शन में अंतर देख सकते हैं। स्क्रिप्ट और बायनेरिज़ के लोड समय, साथ ही स्क्रिप्ट और बायनेरिज़ के प्रदर्शन अनुपात के बारे में आप जो जानते थे, वह PowerShell 3 की रिलीज़ से गुम हो गया है, क्योंकि स्क्रिप्ट और फ़ंक्शंस की व्याख्या अब प्रत्येक कॉल से पहले नहीं की जाती है, बल्कि संकलित, निष्पादित और यहां तक ​​कि कैश की जाती है (समय-समय पर)। नतीजतन, स्क्रिप्ट का पहला लॉन्च और पहला आयात कुछ हद तक उम्मीद से अधिक लंबा है, लेकिन स्क्रिप्ट और उनके बाद के कार्यों के बाद के सभी कॉल तेजी से प्रदर्शन किए गए हैं। और यह मॉड्यूल में फ़ाइलों और पूर्वनिर्धारित कार्यों में सभी लिपियों पर लागू होता है। एक ही फ़ंक्शन का अनुक्रमिक लॉन्च कई बार कंसोल में एक और एक ही कोड को कई बार चिपकाने की तुलना में बहुत तेज़ होता है।
एक और महत्वपूर्ण परिवर्तन PSObject का परित्याग है।
PowerShell 3 में, PSObject वास्तव में एक गतिशील वस्तु है, जिसका अर्थ है कि C # से बुलाए गए cmdlets और लिपियों के आउटपुट का उपयोग डायनामिक कीवर्ड के साथ किया जा सकता है बजाय कि PSObject के साथ उपयोग किए गए छद्म-परावर्तन विधियों का उपयोग करने के बजाय। वैसे, यह केवल हिमशैल का टिप है।

PowerShell 2 में, विस्तारित प्रकार प्रणाली (ETS) में सब कुछ PSObject पर आधारित था। नए सदस्यों को हमेशा PSObject में जोड़ा गया है कि BaseObject चारों ओर से लपेटता है - चाहे वह type.ps1xml फ़ाइल से आता हो या ऑब्जेक्ट पर ऐड-मेंबर कॉल से। यदि Add-Member विधि को PSObject में लिपटे हुए ऑब्जेक्ट पर नहीं बुलाया गया था, तो आपको -Passthru पैरामीटर को निर्दिष्ट करना होगा और आउटपुट को PSObject में लपेटे जाने के लिए प्रोसेस करना होगा, जिसमें एक नया सदस्य जोड़ा जा सकता है। इसके अलावा, यदि किसी वस्तु को एक निश्चित प्रकार के लिए डाला गया था, तो जोड़ा गया ईटीएस सदस्य अधिकांश मामलों में खो गए थे। नीचे एक उदाहरण स्क्रिप्ट है:

$psObject = Get-ChildItem $psObject.Count $Count1 = ($psObject | where { $_.PSIsContainer }).Count [IO.FileSystemInfo[]]$ioObject = Get-ChildItem $ioObject.Count $Count2 = ($ioObject | where { $_.PSIsContainer }).Count $Count3 = ($ioObject | where { $_ -is [IO.DirectoryInfo] }).Count 

PowerShell 2 में, $ Count1 और $ Count3 में वर्तमान निर्देशिका में फ़ोल्डर्स की संख्या होगी, और $ Count2 हमेशा 0 होगा, क्योंकि PSIsContainer प्रॉपर्टी वास्तव में एक ETS प्रॉपर्टी है जो FileSystemInfo को कास्टिंग करते समय खो जाती है, यही वजह है कि इस वेरिएबल का हमेशा शून्य के रूप में मूल्यांकन किया जाता है।
PowerShell 3 में, परिणाम अलग होगा। PowerShell अब गतिशील वस्तुओं के रूप में सब कुछ के साथ काम करता है, और ऐड-सदस्य को अब इन ईटीएस सदस्यों को ट्रैक करने के लिए PSObject की आवश्यकता नहीं है। तो अब ऊपर प्रस्तुत स्क्रिप्ट $ Count1, $ Count2 और $ Count3 को समान रूप से वापस कर देगी, जैसा कि अपेक्षित था। जाहिर है, एड-मेंबर में "-पश्चरु" विकल्प केवल टनल चीजों के लिए आवश्यक है, न कि साधारण असाइनमेंट के लिए। लेकिन जैसा कि यह हो सकता है, अभी भी ऐसे मामले हो सकते हैं जब इकाइयां अभी भी PSObject में लपेटने लायक हैं।
मुझे लगता है कि आप सहमत होंगे कि PowerShell को DLR में पोर्ट करना एक बड़ा कदम है! लेकिन बड़े बदलावों के लिए तैयार रहें जो पहले से लागू कार्यक्षमता को तोड़ सकते हैं। उदाहरण के लिए, ऊपर की स्क्रिप्ट में निम्नलिखित तीन पंक्तियों को जोड़ने का प्रयास करें और उन्हें PowerShell 2 और PowerShell 3 CTP2 में निष्पादित करें:

 $Count1 -eq $Count2 $e = $ioObject[0] | Add-Member NoteProperty Note "This is a note" -Passthru $f = $ioObject[0] | Add-Member NoteProperty Note "This is a note" -Passthru 

PowerShell 2 में, आपको गलत मिलेगा, और अगली दो पंक्तियाँ ठीक काम करेंगी। PowerShell 3 में, पहली पंक्ति ट्रू वापस आएगी, और Add-Member के अंतर्निहित ऑब्जेक्ट को संशोधित करने के बावजूद भी PSObject में लिपटे नहीं, तीसरी पंक्ति "ऐड-मेंबर: त्रुटि उत्पन्न करेगी" नाम के साथ एक सदस्य नहीं जोड़ा जा सकता है क्योंकि "नोट" उस नाम के साथ एक सदस्य क्योंकि पहले से मौजूद है। ”
किसी भी स्थिति में, मुझे यकीन है कि भविष्य में मैं DLR के बारे में कुछ और लिखूंगा और इसके संक्रमण के साथ PowerShell में क्या परिवर्तन हुए हैं। लेकिन अभी के लिए, मुझे लगता है कि मन के लिए पर्याप्त भोजन होगा।