दिलचस्प। मैंने हमेशा सोचा है कि क्यों 1 .ps1 का उपयोग PowerShell लिपियों में एक प्रकार के शब्दार्थ वर्जन को जोड़ने के लिए किया जाएगा, जिससे स्क्रिप्ट को यह इंगित करने की अनुमति मिलती है कि क्या यह संभव ब्रेकिंग परिवर्तनों के अनुकूल है।

उन समस्याओं को ठीक करने के लिए महंगा है जो मुझे लगता है कि पावरशेल के तकनीकी ऋण के रूप में नए .NET अवधारणाओं को अपनाने के रूप में वे साथ नहीं आए

• जेनरिक विधियों के लिए टाइप पैरामीटर के लिए भाषा सिंटैक्स # 5146

• प्रकार प्रणाली में स्वचालित रूप से सतह के लिए Extension Methods लिए इंजन समर्थन (जैसे वे _compiled_ .Net भाषाओं में) करते हैं। # 2226

• Async APIs के लिए भाषा समर्थन # 6716 (और RFC )

कुछ अफसोसजनक विशेषताएं हैं:

• हम कुछ प्रकार संकेत पर के आधार पर (@KirkMunro की तरह कर सकता है FormatPx ) के बजाय cmdlets के उत्पादन वस्तुओं स्वरूपण? # 4594 # 4237 # 3886

• क्या आप रजिस्ट्री प्रदाता को _content_ आधारित होने के लिए सामान्य करेंगे - बजाय यह महसूस करने के कि एक संपत्ति प्रदाता कैसे काम कर सकता है? # 5444

• क्या आप PSProviders को गहराई से लिखना आसान बना देंगे? यह शर्म की बात है कि "SHPS" पर पहुंचने के लिए अमूर्तता की दो परतें लगती हैं और अंत में लोगों को प्रदाताओं को लिखने का एक तरीका देता है जिसका वे उपयोग करने के लिए तैयार हैं

कैसे एक बड़े सवाल के बारे में:

क्या हम "कई तरीके बेहतर है" दृष्टिकोण पर पुनर्विचार करने और "सफलता के गड्ढे" दृष्टिकोण पर काम करने के लिए तैयार होंगे? मेरा मतलब है कि क्या हम "आसान तरीका" मानी जाने वाली सुविधाओं को हटाने के लिए तैयार होंगे, लेकिन जो मूल रूप से बदतर हैं, चीजों को करने के लिए केवल "सही तरीका" होने के पक्ष में हैं? उदाहरण के लिए:

• CmdletBinding हमेशा चालू रखें
• Make @ () अंकन का अर्थ है List[PSObject]
• @ {} का अर्थ Dictionary[PSObject, PSObject] (या Dictionary[string, PSObject] a) है
• _Process_ को डिफ़ॉल्ट ब्लॉक करें
• शायद यहां तक ​​कि _ValueFromPipelineByPropertyName_ को डिफ़ॉल्ट बनाएं; ;-)

सभी महान सुझाव, @ जयकुल।

पुनः @() संकेतन का अर्थ List[PSObject] : मुझे लगता है कि हम इसे आगे ले जा सकते हैं और PowerShell के मौलिक संग्रह प्रकार के रूप में कुशलतापूर्वक एक्स्टेंसिबल संग्रह प्रकार का उपयोग कर सकते हैं, ताकि [object[]] का उपयोग किया जाए। वर्तमान में है (और इसका उपयोग आंतरिक रूप से और साथ ही संग्रह को वापस करते समय, बिना किसी प्रकार के रूपांतरण प्रदर्शन दंड के साथ किया जाता है); + उपयोग के आसपास चुनौतियां हैं, लेकिन @PetSerAl ने इससे निपटने के लिए एक कस्टम सूची कार्यान्वयन का सुझाव दिया है ।

Process {} को डिफ़ॉल्ट फ़ंक्शंस में ब्लॉक करना, एक तरफ के रूप में: यह वही है जो Filter वर्तमान में करता है, लेकिन यह सीमित है - निहित - Process ब्लॉक, और यह फ़ंक्शन संस्करण वास्तव में कभी नहीं पकड़ा गया प्रतीत होता है; Function के संदर्भ में दोनों को एकीकृत करने से मुझे समझ में आता है।

अजीब बात है, Azure PowerShell कम्युनिटी स्टैंडअप कॉल पर अभी, और वे AzureRm से एक नए Az मॉड्यूल में जाने जा रहे हैं, जो क्रॉस प्लेटफॉर्म (कोई अलग AzureRm.Core) नहीं है, और सभी कमांड उपसर्गों के साथ AzureRm से बदलकर Az हो गया है। दोनों थोड़ी देर के लिए साथ रहेंगे, लेकिन वे नए कमांड सेट पर जा रहे हैं।

बहुत बुरा PowerShell के पास अभी तक एक नया निष्पादन योग्य बनाने का अवसर नहीं था जो Windows PowerShell के साथ कंधे से कंधा मिलाकर चलेगा, लेकिन इससे कुछ विरासत संकट से दूर हो सकता है जो इसे नीचे गिरा देता है।

जरा सोचिए कि इसके लिए हमें क्या करना चाहिए:
वास्तविक रूप से यह कहते हुए कि 'नो पछतावा' संस्करण के साथ आने के लिए कम से कम 6 महीने का प्रयास करना होगा और इस पर फिर से कहना होगा। तब 3 पार्टी मॉड्यूल को इस संस्करण के लिए उपयोगी होने के लिए इसे अनुकूलित करने की आवश्यकता है, जो एक उचित कवरेज प्राप्त करने में कम से कम 6 महीने का समय लेगा (और ध्यान रखें कि कुछ मॉड्यूल कभी नहीं होगा) ... फिर इसके लिए खाते देरी और अप्रत्याशित समस्याएं, आदि ... इसलिए, नहीं, मुझे लगता है कि यह केवल इच्छाधारी सोच है कि एक ही बार में एक संस्करण में सभी तकनीकी ऋणों से छुटकारा मिल सकता है (और अभी भी विकास और पुराने संस्करण को बनाए रखना नहीं है)।

जितना मैंने चाहा कि इस तरह के संस्करण का अस्तित्व है, मुझे लगता है कि यह केवल एक समय में धीरे-धीरे एक परिवर्तन को प्राप्त करना संभव होगा। V6 के साथ बहुत सारे ब्रेकिंग परिवर्तन पहले ही स्वीकार कर लिए गए थे लेकिन मुझे लगता है कि अगर किसी एक संस्करण में बहुत अधिक ब्रेकिंग परिवर्तन शामिल हैं, तो यह मौजूदा स्क्रिप्ट / मॉड्यूल को अपग्रेड करने के लिए बहुत जटिल हो जाएगा। सबसे मूल्यवान ब्रेकिंग परिवर्तनों पर चर्चा करना अच्छा है, लेकिन जब तक कि pwsh का एलटीएस संस्करण नहीं है, मुझे नहीं लगता कि मौजूदा मुख्यधारा के संस्करण के समानांतर अधिक परिवर्तन के साथ pwsh की दूसरी ट्रेन होने के बारे में सोचने का समय है।

@bergmeister सहमत हैं। हालांकि, मुख्य पथ पर अपेक्षाकृत छोटे परिवर्तन भी गोद लेने में गंभीरता से बाधा डाल सकते हैं। पाइथन को देखें 3. वास्तव में इसे पकड़ने में 10 _years_ लगे। बहुत बड़े परिवर्तनों के साथ, कौन जानता है कि पर्ल 6 को प्रभावी होने में कितना समय लगेगा (और उन्हें अपने सही सामान के साथ आने में 15 साल लग गए इसलिए पावरशेल ++ के लिए 1.5 साल आशावादी :-) लगता है) दूसरी ओर PHP लगता है नियमित रूप से चीजों को तोड़ना, संभवतः रास्ते के कारण और इसके लिए क्या उपयोग किया जाता है।

अजगर 3 निश्चित रूप से हॉरर शो है, क्या यह वास्तव में अभी तक पकड़ा गया है? मैं अभी भी 2.7 चला रहा हूँ, और जल्द ही किसी भी समय उन्नयन की योजना नहीं है। लेकिन मैंने हाल ही में पर्ल 6 के बारे में ज्यादा नहीं सुना है ...

मुझे लगता है कि पायथन से सीखने के सबक इंजन के एक संस्करण परिवर्तन से भाषा में अलग-अलग ब्रेकिंग परिवर्तन हैं। Hypothetically, एक PS 7 इंजन अभी भी पहले की स्क्रिप्ट (.PS1) फ़ाइलों को नो-ब्रेकिंग परिवर्तन मोड में चला सकता है, जबकि यदि स्क्रिप्ट को 7 जागरूक (a .PS7 एक्सटेंशन के साथ कहते हैं) के रूप में चिह्नित किया गया था, तो वे घोषणा कर सकते थे कि उन्हें अद्यतन किया गया है _और। चलाने के लिए कम से कम PS 7 की आवश्यकता होती है। आशा है कि समझ में आता है।

शायद सबसे अच्छी सफलता की कहानी जावास्क्रिप्ट / टाइपस्क्रिप्ट / बैबेल है। एक ट्रांसपिलर (स्रोत-मानचित्र समर्थन के साथ) भाषा के विकास के लिए रास्ता-जैसा लगता है।

जावास्क्रिप्ट एक विशेष मामला है। आप बहुत ज्यादा इसके साथ फंस गए हैं इसलिए ट्रांसप्लिंग करना वास्तव में एकमात्र विकल्प है। टाइपस्क्रिप्ट एक्सटेंशन के साथ "बस" जावास्क्रिप्ट है, इसलिए लोगों को अपनाना आसान है। कोई भी जावास्क्रिप्ट प्रोग्राम एक टाइपस्क्रिप्ट प्रोग्राम है, इसलिए आप जो कुछ भी है उससे शुरू करते हैं और बस वहां से एनोटेशन जोड़ते हैं। दूसरी ओर, डार्ट, यह स्वयं की भाषा है लेकिन क्रोम में या तो जावास्क्रिप्ट या देशी रनटाइम के लिए ट्रांसपाइल्स (कम से कम एक बिंदु पर योजना) थी। डार्ट को Google के बाहर बहुत अधिक गोद लेने की संभावना नहीं लगती है, क्योंकि यह अपनी भाषा है।

@BurtHarris

अजगर 3 निश्चित रूप से हॉरर शो है, क्या यह वास्तव में अभी तक पकड़ा गया है?

मैं पिछले सप्ताह एक लेख पढ़ रहा था जहां लेखक दावा कर रहा था कि पायथन 3 के लिए महत्वपूर्ण द्रव्यमान प्राप्त किया गया है। यह सभी मुख्य मॉड्यूल उपलब्ध थे और अब लोग जहां ड्राव में प्रवास कर रहे थे। हम देखेंगे..

दिलचस्प। मैंने हमेशा सोचा है कि क्यों 1 में .ps1 का उपयोग पॉवरशेल लिपियों में एक प्रकार के शब्दार्थ संस्करण को जोड़ने के लिए किया जाएगा, एक स्क्रिप्ट को यह इंगित करने की अनुमति देता है कि क्या यह संभव ब्रेकिंग बदलावों के अनुकूल था।

WRT .ps1 , हम मामले में विस्तार को बदलने का अधिकार सुरक्षित रखते हैं क्योंकि हमें भाषा पूरी तरह से गलत मिली है, जिसके परिणामस्वरूप रनटाइम के लिए भयावह परिवर्तन हुए हैं जैसे कि पिछले संस्करण की स्क्रिप्ट बस काम नहीं करेगी। लेकिन विस्तार को बदलने से भी काम का एक बड़ा ढेर हो जाता है क्योंकि पारिस्थितिकी तंत्र में बहुत सी चीजें एक विस्तार से जुड़ी होती हैं। तो यह कुछ हल्का करने के लिए नहीं है। और हां, विंडोज का हिस्सा होने के नाते, अगर हम एक्सटेंशन को भूल गए, तो हमें अभी भी दोनों संस्करणों (जैसे पायथन 2/3) को बनाए रखना होगा।

@bergmeister :

मान्य चिंताएं, लेकिन की भावना में:

सबसे मूल्यवान ब्रेकिंग परिवर्तनों पर चर्चा करना अच्छा है

कृपया आपके मन में जो भी हो उसे साझा करें।

एक समय में धीरे-धीरे एक ब्रेकिंग परिवर्तन

जबकि असंगत परिवर्तन के लिए (lexically scoped) ऑप्ट-इन तंत्र एक समाधान है, मैं दो चीजों के बारे में चिंतित हूं:

• टुकड़ा-टुकड़ा परिचय किसी को यह याद रखने में सक्षम नहीं हो सकता है कि किस विशेषता के लिए कौन से संस्करण की आवश्यकता है; पर्ल (v5-) के दिमाग में आता है।

• कोड बेस फूला हुआ और बनाए रखने में कठिन होता है, और परिणामस्वरूप बाइनरी समान रूप से फूला हुआ होता है, जो (कम से कम) स्टार्टअप प्रदर्शन को नुकसान पहुंचाता है।

मैंने पहले कहा है: मेरे लिए - और यह सिर्फ एक कूबड़ है - v6 जीए पुराने समय-टाइमर बनाने के बीच एक दुर्भाग्यपूर्ण समझौता था जो परिवर्तनों को तोड़ने से नाखुश था जबकि गोद लेने में बाधा के लिए पर्याप्त सामान आगे ले जाने में यूनिक्स-जैसे-दुनिया में।

कहा कि, यूनिक्स [जैसे] दुनिया में पॉवरशेल के रिश्तेदार युवाओं को देखते हुए, शायद (अभी भी) असंगत परिवर्तनों के माध्यम से समस्याओं को हल करने की इच्छा से अधिक है। @BrucePay के अनुसार, Windows PowerShell को वैसे भी बनाए रखना होगा, और यह पिछड़े संगतता के लिए सुरक्षित आश्रय बन सकता है।

मुझे लगता है कि इस तरह के ब्रेकिंग परिवर्तनों के नकारात्मक परिणामों के पैमाने को पहले ही कवर किया गया है, और मैं उन अधिकांश बिंदुओं से सहमत हूं। मैं यह इसलिए लिख रहा हूं क्योंकि मुझे संदेह है कि अधिक संदर्भ में, इन परिवर्तनों से पहली जगह में महत्वपूर्ण लाभ होगा। कम से कम जिस तरह से मैं पॉवरशेल का उपयोग करता हूं।

ओपी में निम्नलिखित कथन शामिल है:

दूसरी तरफ, अपरिहार्य उप-उत्पाद तकनीकी ऋण का संचय था जिसमें अपवादों को याद रखने की आवश्यकता होती है और नए लोगों के लिए एक बाधा है।

इस कथन का निहितार्थ यह प्रतीत होता है कि इन विभिन्न परिवर्तनों को बनाने से अपवादों को याद रखने का बोझ कम हो जाएगा। वास्तव में यह एक महान परिणाम होगा। हालांकि, मुझे संदेह है कि इसका परिणाम होगा। पॉवरशेल का व्यवहार जानबूझकर समृद्ध है। यह इसे अभिव्यंजक और अप्रत्याशित दोनों बनाता है। स्पष्टता और पूर्वानुमेयता एक दूसरे के खिलाफ काम करने लगती है, कम से कम उन भाषाओं के बीच जो मैं परिचित हूं।

जबकि मैं इस बात से सहमत हूं कि ऊपर उल्लिखित कई परिवर्तनों में से कुछ मामलों में कुछ हद तक भविष्यवाणी में सुधार होगा, भाषा के कई अप्रत्याशित और आश्चर्यजनक पहलू बने रहेंगे। PowerShell लिखने में वर्षों बिताने के बावजूद, मैं अभी भी PowerShell व्यवहार से अक्सर आश्चर्यचकित हूं जो डिजाइन द्वारा प्रतीत होता है और शायद इसे बदला नहीं जाना चाहिए। हाल के कुछ उदाहरण जो मन में आते हैं वे इस प्रकार हैं:

• सशर्त देरी [scriptblock] तर्कों (# 6419) के बंधन में देरी
• जब, वास्तव में, निहितार्थ होता है (# 5832)
• पैरामीटर बाइंडिंग के दौरान [AutomationNull]::Value से $null रूपांतरण (# 6357 संबंधित है)
• पाइपलाइन में नियंत्रण के प्रवाह पर break और continue का प्रभाव (# 5811)
• जब आप $null ( SO ) बंटते हैं तो क्या होता है
• सत्र राज्यों में स्क्रिप्टब्लॉक का उपयोग $_ ( SO 1 , SO 2 ) को कैसे प्रभावित करता है

मुझे उम्मीद है कि ये उदाहरण कई अन्य सावधानीपूर्वक डिज़ाइन किए गए लेकिन अभी तक खोजे गए आश्चर्यजनक बारीकियों का एक छोटा सा अंश हैं। मैंने इन उदाहरणों को चुना क्योंकि

1. वे ऐसे व्यवहार का प्रतिनिधित्व करते हैं जो शायद PowerShell में सुधार नहीं किया जा सकता है, और
2. पावरशेल पढ़ते या लिखते समय मुझे उनके सभी निहितार्थों के बारे में जानने की उम्मीद नहीं है।

मैं इसके साथ ठीक हूं। आश्चर्यजनक पॉवरशेल व्यवहार का भारी बहुमत पॉवरशेल के साथ मेरी सफलता पर स्थायी प्रभाव नहीं डालता है। विकास के दौरान परीक्षण करके आश्चर्यचकित करने वाला व्यवहार लगभग हमेशा पकड़ा जाता है। मैं उन चीजों से सीखता हूं जो मेरी परीक्षण रणनीति को बेहतर बनाने के लिए उपयोग करते हैं। यह सच है कि क्या वे आश्चर्यजनक व्यवहार ऐसे हैं जिन्हें समाप्त किया जा सकता है या जिस तरह का रहना चाहिए।

ऊपर प्रस्तावित ब्रेकिंग परिवर्तन किए गए हैं या नहीं, PowerShell कभी भी इतना अनुमानित नहीं होगा कि मैं परीक्षण कवरेज को काफी कम कर सकता हूं। दूसरे शब्दों में, जिस तरह से मैं पॉवरशेल का उपयोग करता हूं, मुझे नहीं लगता कि इसमें कोई उल्टा-सीधा है, जो उपरोक्त प्रस्तावित परिवर्तनों को बदलकर संभव है।

(BTW, इस सवाल को सीधे पूछने के लिए @ mklement0 का शुक्रिया। यह मेरे दिमाग में कुछ समय के लिए रहा है। सभी को अपना अंश कहने का अवसर देखना अच्छा है।)

धन्यवाद, @ alx9r

मुझे लगता है कि _intrinsic_ जटिलता और _extrinsic_ जटिलता के बीच अंतर करना महत्वपूर्ण है:

• _Irrinsic_ जटिलता उन अवधारणाओं की अंतर्निहित जटिलता से उपजी है, जो PowerShell के मामले में दो प्राथमिक स्रोत हैं: _internal_ जटिलता एक नए प्रतिमान (वस्तु-आधारित पाइपलाइन) को शुरू करने और दो अलग-अलग दुनिया (शेल सिंटैक्स और प्रोग्रामिंग-भाषा-वाक्यविन्यास) से शादी करने से ), और _external_ जटिलता से कई के साथ अंतर करने से, बाहर की दुनिया से अलग।

  • आंतरिक जटिलता का प्रबंधन अवधारणाओं और विशेषताओं को ठीक से करने के द्वारा किया जाता है और उन्हें _names_ भी दिया जाता है।

  • 6419 एक प्रमुख उदाहरण है: एक शक्तिशाली और व्यापक रूप से उपयोगी सुविधा इसे रेखांकित करती है, लेकिन यह ~ वर्तमान में बिल्कुल भी प्रलेखित नहीं है, जहां तक ​​मुझे पता है, और इसका कोई स्थापित नाम नहीं है ~; https://github.com/PowerShell/PowerShell-Docs/issues/2338 [_delay-bind_ script ब्लॉकों के रूप में प्रलेखित] देखें

  • _Member enumeration_ सुविधा में समान रूप से एक स्थापित नाम और केंद्रित प्रलेखन का अभाव है - https://github.com/PowerShell/PowerShell-Docs/issues/2198 देखें

    • # 6802 में सदस्य गणना के एक _extrinsic_ पहलू पर चर्चा की गई है।

  • 5832 उचित वैचारिक प्रलेखन के लिए एक और उम्मीदवार है।

    • हालाँकि, आपने वर्तमान व्यवहार के दो _extricic_ पहलुओं की खोज की है: सभी स्केलरों को न केवल .Count , बल्कि एक .Length प्रॉपर्टी और पैरामीटर-बाइंडिंग एन्यूमरेशन व्यवहार को पाइप लाइन / ऑपरेटर के साथ समान रूप से भिन्न किया जा रहा है। व्यवहार ।

• _Extrinsic_ जटिलता लीक के सार और विसंगतियों से उपजी है।

  • इस तरह की जटिलता को कम किया जाना चाहिए।

  • यदि वह पिछड़ी-अनुकूलता की चिंताओं के कारण कोई विकल्प नहीं है, तो ऐसी जटिलता को _Documented ज्ञात समस्याओं के रूप में होना चाहिए।

  • स्क्रिप्ट-मॉड्यूल वैरिएबल स्कोपिंग व्यवहार (जिसे आप $_ संदर्भ में संदर्भित करते हैं) सिर्फ एक उद्धरण से अधिक है: यह एक बड़ी समस्या का मूल कारण है, जो पहले उल्लेख किया गया है # 4568।

  • आपके द्वारा उल्लिखित अन्य सभी मुद्दे मुझे बाहरी श्रेणी में आने के बजाय हड़ताल करते हैं (सावधान डिजाइन का परिणाम होने के बजाय), क्योंकि वे सभी विसंगतियों के रूप में मौजूद हैं जिनका कोई स्पष्ट (प्रलेखित) औचित्य या लाभ नहीं है:

    • यह $null साथ बिखरने के लिए और अधिक समझ में आता है, क्योंकि वह एक $null तर्क के बजाय _no_ तर्कों को पारित करने के लिए है।
    • [System.Management.Automation.Internal.AutomationNull]::Value को $null _ Https://github.com/PowerShell/PowerShell/issues/9150#issuecomment-474743435 देखें
    • कॉल स्टैक के पार, _quiet टर्मिनेशन_ के साथ _ break और continue होने का _ लाभ क्या है, अगर कोई एन्कोडिंग लूप नहीं मिला है?

जबकि सुविधाओं की संपत्ति और असमान दुनिया में शामिल होने से सभी आवश्यक _intrinsic_ जटिलता को याद रखना मुश्किल हो जाता है, _extrinsic_ एक को कम करना अभी भी महत्वपूर्ण है।

केवल जानने और विश्वास किए बिना अपने इच्छित दृष्टिकोण का परीक्षण करने के बाद यह काम करेगा - या आश्चर्यजनक व्यवहार के कारण अप्रत्याशित रूप से चीजों को तोड़ना - एक गंभीर उत्पादकता (और आनंद) बाधा है (भले ही पावरशेल सराहनीय रूप से इंटरेक्टिव परीक्षण व्यवहार के लिए बहुत आसान बनाता है )।

यह ठोस अवधारणाओं के लिए नीचे आता है (जो सहज अपेक्षाओं का उल्लंघन नहीं करता है), वर्णनात्मक नामकरण और अच्छा प्रलेखन:

अगर मुझे यह नहीं पता है / निश्चित नहीं है कि मुझे सही याद है, तो मुझे यह जानना होगा कि इसे कहाँ देखना है, और विश्वास है कि परिचित समस्याएँ और किनारे के मामले_ भी प्रलेखित हैं (या तो नियमित सहायता विषयों के हिस्से के रूप में या लिंक से वहाँ)।

इसलिए अगर हम यह तय करते हैं कि _eliminating_ एक्सट्रिंसिक जटिलता एक विकल्प नहीं है, तो हम कम से कम _document इसे व्यवस्थित रूप से कर सकते हैं - और यहां चर्चा "पिटफॉल गैलरी" संकलन के लिए शुरुआती बिंदु के रूप में काम कर सकती है (जिसमें अपरिहार्य _intrinsic_ जटिलता के मामले भी शामिल हो सकते हैं) आश्चर्य हो सकता है)।

हम कम से कम इसे व्यवस्थित रूप से दस्तावेज कर सकते हैं - और यहां चर्चा "पिटफॉल गैलरी" संकलन के लिए शुरुआती बिंदु के रूप में काम कर सकती है

रोमन कुज़मीन कुछ समय से ऐसी गैलरी बना रहे हैं, यहाँ: https://github.com/nightroman/PowerShellTraps

धन्यवाद, @HumanEquivalentUnit - जो एक महान संग्रह की तरह दिखता है।

इस थ्रेड में एकत्र किए गए मुद्दों के साथ, यह एक गैलरी के लिए आधार बना सकता है जो कि _official_ प्रलेखन का हिस्सा है, उपयुक्त के साथ संवर्धित प्रत्येक प्रविष्टि को डायन:

• एक डिज़ाइन तर्क, जो बताता है कि व्यवहार, हालांकि शायद आश्चर्य की बात है, सब के बाद उचित है (एक उचित रूप से तैयार स्पष्टीकरण आश्चर्य का तत्व दूर हो सकता है)

• इस समस्या को स्वीकार करते हुए, कहा कि:

  • या तो: यह पिछड़े संगतता के हित में तय नहीं किया जाएगा।
  • या: कि भविष्य में बदलाव पर विचार किया जा रहा है
  • या: यह मुद्दा पहले से ही PS _Core_ में ठीक किया गया है

यह अजीब है कि यह पूछा जाना चाहिए कि क्या "PowerShell vZeroTechnicalDebt_ _ के लिए _it का समय है

इसके लिए वास्तव में एक आवश्यक संस्करण कमांड है।

अगर किसी नए संस्करण में कुछ टूटता है, तो हमें जो एकमात्र दर्द होता है, वह यह है कि हमें आमतौर पर छोटे अंतरों का अध्ययन करना और सीखना होता है।

लेकिन हमें (अंत में) एक मंच मिलता है, जो वास्तव में कोर में प्रत्येक पुनरावृत्ति के साथ बेहतर होता है। और बनाए रखने के लिए बहुत आसान है।

नहीं, यह कभी नहीं पता है कि नए डिजाइन और तकनीक द्वारा खराब डिजाइन और फैसलों को किक किया जाए।

इसके अलावा, जीवित घोड़े को मारने के लिए एक मरे हुए घोड़े से बाहर, यह अभी भी मूर्खतापूर्ण रूप से एक अच्छी तरह से व्यवहार किए गए फ़ंक्शन या cmdlet को लिखने के लिए कठिन है जो मेजबान के मूल फाइल सिस्टम और filesystemprovider के बीच जादुई अंतर से संबंधित है। इस तरह के बारीक कोड को लिखना मुश्किल है और अक्सर गलत हो जाता है। यहाँ पर एक पोस्ट है stackoverflow मैं सात या आठ साल पहले के बारे में जवाब दिया कि अभी भी मान्य है:

https://stackoverflow.com/questions/8505294/how-do-i-deal-with-paths-when-writing-a-powershell-cmdlet

Ref: # 8495

कुछ अजीब ऑपरेटर पूर्ववर्ती नियम हैं जो संशोधन के लायक हैं:

PS> 1, 2, 2 + 1, 4, 4 + 1
1
2
2
1
4
4
1

अधिकांश भाषाओं में, एक और अधिक यह उम्मीद करता है कि यह आउटपुट होगा:

1
2
3
4
5

एक विकल्प जिसमें अपने स्वयं के पेशेवरों और विपक्ष हैं, सभी "आदर्श" व्यवहार को सक्षम करने के लिए एक नया फीचर फ्लैग है ताकि यह ऑप्ट-इन हो। यदि हमारे पास कुछ टेलीमेट्री है जो यह दर्शाता है कि अधिकांश उपयोग नए व्यवहार में चले गए हैं, तो हम इसे फ्लिप कर सकते हैं, इसलिए यह ऑप्ट-आउट है। यह सब सिर्फ एक पाइप सपना हो सकता है क्योंकि मैंने कोई वास्तविक दुनिया का मामला नहीं देखा है जहां इस तरह के मॉडल ने काम किया हो ...

वास्तव में यह _nice_ होगा, लेकिन इसके बजाय ... पूरी तरह से ... इस धागे में इनमें से कुछ संशोधनों की प्रकृति, यह संभावित रूप से पूरी तरह से _splitting_ को "सामान्य" और "प्रयोगात्मक" के बीच लिपियों की अनुकूलता और संभवतः कई टुकड़ों में संभावित रूप से जोखिम में डालती है, जिसके आधार पर किसी व्यक्ति ने झंडे सक्षम किए हैं।

इसका मतलब है कि हम वास्तव में उस चीज़ पर भरोसा नहीं कर सकते हैं जो उस तरह से एक प्रायोगिक विशेषता है, और न ही स्क्रिप्ट और मॉड्यूल लिखें जो उन पर भरोसा करते हैं, जब तक कि हम डॉक्स पृष्ठों के लिए एक बड़ी चेतावनी नहीं देते हैं, या संभावित रूप से उन्हें आयात होने से रोकते हैं जब तक कि कुछ झंडे नहीं। सक्षम हैं।

यह _might_ परिहार्य हो सकता है, लेकिन ... यदि हम, प्रति-मॉड्यूल-गुंजाइश के आधार पर विशिष्ट प्रयोगात्मक सुविधाओं को इच्छा, सक्षम और अक्षम कर सकते हैं। लेकिन, यह देखते हुए कि यह केवल मामलों को और जटिल करता है, मुझे यकीन नहीं है कि अगर यह एक विशेष रूप से महान समाधान है, या तो।

@ vexx32 सिर्फ स्पष्ट होने के लिए, मैं experimental ध्वज का सुझाव नहीं दे रहा था जो अंततः गैर-प्रयोगात्मक हो जाएगा। मैं कुछ अलग सोच रहा था (शायद अधिक Enable-PSFeature जैसा कि यह आधिकारिक रूप से समर्थित होगा (और इस तरह प्रायोगिक सुविधाओं के विपरीत परिवर्तन से सुरक्षित है)। मैं यह भी सोच रहा था कि यह एक एकल ध्वज होगा जहां आप व्यक्तिगत रूप से बजाय एक सेट के रूप में इन नए ब्रेकिंग परिवर्तनों को चुनते हैं।

ओह, उस मामले में ... हाँ, बिल्कुल। यह हमें बड़े करीने से एक छत्र के नीचे सब कुछ एक साथ पैकेज करने देगा, और वास्तव में इसका उपयोग करेगा। मैं जो सोच रहा था, उससे बहुत बेहतर! 😄

# 8512 के आधार पर, यहाँ संकलित मुद्दों की सूची के अलावा @ jszabo98 :

-and और -or अप्रत्याशित रूप से _same_ पूर्वता है, जबकि ज्यादातर भाषाओं में (C # सहित) -and की -or से अधिक पूर्वता है।

उदाहरण अभिव्यक्ति जो उम्मीदों को पूरा करती है:

PS> $true -or $true -and $false
False

बाएं-समरूपता और -and और -or एक ही मिसाल होने के कारण, उपरोक्त का मूल्यांकन ($true -or $true) -and $false बजाय अपेक्षित $true -or ($true -and $false)

यह सब सिर्फ एक पाइप सपना हो सकता है क्योंकि मैंने कोई वास्तविक दुनिया का मामला नहीं देखा है जहां इस तरह के मॉडल ने काम किया हो ...

वास्तव में, हमारे पास पहले से ही एक मॉडल है जो पूरी दुनिया में काम करता है - एलटीएस। MSFT विंडोज 10 को विकसित करने के लिए इसका उपयोग करता है। मॉडल का उपयोग यूनिक्स वितरण को विकसित करने के लिए किया जाता है।
हमारे लिए, इसका मतलब है कि हम हर दो साल में एलटीएस पावरशेल कोर संस्करण जारी कर सकते हैं और उन्हें विंडोज 10 एलटीएस संस्करण और यूनिक्स एलटीएस संस्करण में शामिल कर सकते हैं। (एक समस्या एलटीएस संस्करणों के लिए विंडोज और यूनिक्स रिलीज की तारीखों को सिंक करना है। मुझे लगता है कि एमएसएफटी मुख्य यूनिक्स कंपनियों के साथ बातचीत कर सकता है।)
इन दो वर्षों के दौरान, हम छोटे ब्रेकिंग परिवर्तन एकत्र कर रहे हैं, अगले चक्र में अधिक महत्वपूर्ण ब्रेकिंग परिवर्तन स्थानांतरित कर रहे हैं।
प्रत्येक नए LTS संस्करण के लिए, ScriptAnalyzer को स्क्रिप्ट माइग्रेशन की सुविधा के लिए नए नियमों का एक सेट मिलना चाहिए।
इस मॉडल के साथ, महत्वपूर्ण उत्पादों और लिपियों को पूरी तरह से परीक्षण और माइग्रेशन के बाद केवल पिछले संस्करण से कूदना होगा।

मैंने इस दृष्टिकोण का उपयोग तब किया जब मैं PHP 4 संस्करण से अगले PHP संस्करण तक एक पुरानी प्रणाली चरणबद्ध रूप से (संस्करण द्वारा संस्करण) स्थानांतरित कर दिया जब तक कि मैं समर्थित PHP 5.x संस्करण तक नहीं पहुंच गया। प्रत्येक चरण में, मुझे अपेक्षाकृत छोटे और त्वरित बदलाव करने पड़े, जिसके बाद अगले चरण तक कुछ समय तक प्रणाली काम करती रही।

अपडेट: यह .Net कोर LTS संस्करणों के साथ सिंक होना चाहिए। मुझे उम्मीद है कि .net Core 3.1 अगला LTS होगा और वर्जन पर PowerShell Core 6.x होना चाहिए था।

ईमानदारी से? ऐसा लगता है कि PowerShell Core के लिए वास्तव में _great_ विचार है। यह हमें इस तरह से ब्रेकिंग परिवर्तन करने की अनुमति देगा, जो वास्तव में इसे आगे बढ़ने में मदद कर सकता है, न कि इसे संगतता चिंताओं के साथ अतिव्यापी, जबकि _also_ एलटीएस रिलीज के बीच अंतरिम में बहुत अधिक ब्रेकिंग परिवर्तनों के साथ इसे ओवरबर्ड नहीं कर सकता है।

Ref: https://github.com/PowerShell/PowerShell/pull/8407#issuecomment -453221566

Get-Variable -ValueOnly -Name myVar | Should -Be $var जोर तब विफल होता है जब $var एक सरणी हो।

ऐसा इसलिए है क्योंकि Get-Variable -ValueOnly WriteObject() लिए गणना अधिभार का उपयोग नहीं करता है।

पावरशेल के कई संस्करण होने के बारे में जिनके अलग-अलग फीचर सेट और ब्रेकिंग परिवर्तन हैं: हमारे पास विरासत और कोर के साथ यह पहले से ही है। जो पहली नज़र में बुरा लगता है, लेकिन भविष्य के लिए एक कार्यशील मॉडल प्रदान कर सकता है। मेरे साथ रुको...

हमें लगभग सभी प्रक्रियाओं को सेट करना होगा जो वास्तविक स्क्रिप्ट चलाने से पहले कोर pwsh.exe को कॉल करने के लिए पॉवरशेल का उपयोग करते हैं क्योंकि विंडोज शेड्यूल किए गए कार्य, जेनकींस, और कई वातावरण शक्तियां कोर अवगत नहीं हैं। हम ऐसा करते हैं क्योंकि हम उन विशेषताओं का उपयोग कर रहे हैं जो केवल एक विशेष पीएस संस्करण में उपलब्ध हैं।

ऐसे मामलों में जहां हम कोर को कॉल करने के लिए बाध्य नहीं कर सकते हैं, हमारे पास प्रत्येक स्क्रिप्ट की जांच होनी चाहिए कि पीएस का कौन सा संस्करण चल रहा है और फिर मेजबान सिस्टम पर उचित पीएस संस्करण का उपयोग करके खुद को कॉल करें। सही वातावरण में चलने के लिए सही कोड प्राप्त करने के लिए हम जो भी चाल का उपयोग करते हैं, हम अक्सर पर्यावरण और मापदंडों के सभी को उसी स्क्रिप्ट पर पास कर रहे हैं जो पहले से चल रही थी।

यह UNIX दर्शन है। एक उपकरण बनाओ एक काम करो और इसे अच्छी तरह से करो। फिर एक संपूर्ण उपकरण बनाने के लिए उपकरणों को मिलाएं जो इसके भागों के योग से अधिक हो। यह स्क्रीप्टिंग की दुनिया है जहाँ हम हर समय और अन्य परिणाम के लिए अन्य उपयोगिताओं के लिए कॉल करते हैं। ऐतिहासिक रूप से वह स्क्रिप्टिंग है। सभी कोड को मूल रखने की कोशिश करके एक अजीब सम्मेलन की ओर रुझान बढ़ता है लेकिन यह केवल एक सम्मेलन है - आवश्यकता नहीं। PS OS तक पहुंच के साथ चलता है और यूनिक्स शेल स्क्रिप्ट की तरह ही उपलब्ध सभी उपयोगिताओं।

यह बहुत आसान होगा यदि कोर के लिए फ़ाइल एक्सटेंशन को .ps6 में अपडेट किया गया हो, ताकि पावरशेल इंजन हमारे लिए काम कर सके। पॉवरशेल का प्रत्येक बाइनरी संस्करण दूसरों से स्वतंत्र रह सकता है जब तक कि हर कॉल एक वातावरण में जाती है और आउटपुट, त्रुटियों, चेतावनियों, अपवादों को दूसरे को लौटाता है - जो हमें महान प्रयास में अभी मैन्युअल रूप से करना है। इंजन में पिछड़े संगत झंडे होना आवश्यक नहीं है क्योंकि इंजन को पता है कि किस संस्करण को चलाना है। इसमें शामिल संदर्भ स्विचिंग पहले से ही हो रही है इसलिए हम पहले से ही सबसे खराब स्थिति में हैं।

हम हमेशा के लिए भयानक हैक का उपयोग करने के लिए मजबूर हो जाएंगे जब तक हम आगे नहीं जाते हैं और चीजों को अच्छी तरह से परिभाषित तरीके से तोड़ते हैं। परिवर्तनों को तोड़ना हमारे जीवन को पहले से कहीं अधिक कठिन बनाने वाला नहीं है। वैकल्पिक रूप से, अगर हम वृद्धिशील, निरंतर सुधार का उपयोग करते हैं और इंजन को स्विचिंग संदर्भ की भारी उठाने की क्षमता है तो हमारा कोड (और जीवन) बेहतर होगा।

@ jtmoree-kahalamgmt-com आपकी प्रतिक्रिया के लिए धन्यवाद! अपने अनुभव और प्रतिक्रिया साझा करने और नई सहायक सुविधाएँ पूछने के लिए नए मुद्दों को खोलने के लिए स्वतंत्र महसूस करें।

यह बहुत आसान होगा यदि कोर के लिए फ़ाइल एक्सटेंशन को .ps6 में अपडेट किया गया हो, ताकि पावरशेल इंजन हमारे लिए काम कर सके।

Https://github.com/PowerShell/PowerShell/issues/2013#issuecomment -24798797777 देखें

और मैंने आपकी प्रतिक्रिया के आधार पर https://github.com/PowerShell/PowerShell/issues/9138 बनाया।

अजगर 3 निश्चित रूप से हॉरर शो है, क्या यह वास्तव में अभी तक पकड़ा गया है? मैं अभी भी 2.7 चला रहा हूँ, और जल्द ही किसी भी समय उन्नयन की योजना नहीं है। लेकिन मैंने हाल ही में पर्ल 6 के बारे में ज्यादा नहीं सुना है ...

मुझे लगता है कि पायथन से सीखने के सबक इंजन के एक संस्करण परिवर्तन से भाषा में अलग-अलग ब्रेकिंग परिवर्तन हैं। Hypothetically, एक PS 7 इंजन अभी भी पहले की स्क्रिप्ट (.PS1) फ़ाइलों को नो-ब्रेकिंग परिवर्तन मोड में चला सकता है, जबकि यदि स्क्रिप्ट को 7 जागरूक (a .PS7 एक्सटेंशन के साथ कहते हैं) के रूप में चिह्नित किया गया था, तो वे घोषणा कर सकते थे कि उन्हें अद्यतन किया गया है _और। चलाने के लिए कम से कम PS 7 की आवश्यकता होती है। आशा है कि समझ में आता है।

मुझे लगता है कि पायथन 3 को हॉरर शो कहना अत्यधिक नाटकीय है। अगर मैं PyPi के शीर्ष डाउनलोड किए गए पैकेजों को हड़पता हूं, तो मुझे लगता है कि v3 ने अब सभी शीर्ष पैकेजों के लिए 33% प्रवेश को तोड़ दिया है, और केन रेइट्ज के अनुरोध पुस्तकालय जैसे नए पुस्तकालयों के लिए, यह है लगभग 50/50 विभाजन: कल v3 का 685k डाउनलोड था, बनाम 875k का v2।

पायथन 3 को एक लंबे समय के लिए वापस रखने वाली प्रमुख बात पंडों और pysci के लिए वैज्ञानिक समुदाय का समर्थन था। लेकिन, नवीनतम आंकड़ों में, वैज्ञानिक समुदाय अब पायथन 3 को पायथन 2: https://pypistats.org/packages/pandas 231k v3 डाउनलोड, 175k v2 डाउनलोड के रूप में पसंद करता है।

जैसा कि प्रसिद्ध डॉ। डब्ल्यू। एडवर्ड्स डेमिंग कहते हैं, "भगवान में हमें भरोसा है; अन्य सभी, डेटा लाएं!" हो सकता है कि आप PyPi डेटा सेट का विश्लेषण करने के लिए PowerShell स्क्रिप्ट लिख सकते हैं और मुझे बता सकते हैं कि Python 3 डेटा का कितना भयावह उपयोग कर रहा है: https://packaging.python.org/guides/analyzing-pypi-package-ding/

मुझे खुशी होगी (इस सटीक क्रम में):

1. मॉड्यूल का उपयोग करना आसान है जो अच्छे स्टैक के निशान का उत्पादन करता है।

   • उदाहरण के लिए, psm1 फ़ाइल कार्यों को कैसे लोड किया जाता है, के लिए मनमाने ढंग से नियमों का वर्णन करने की अनुमति देता है, लेकिन इससे क्रिप्टिक स्टैक के निशान पैदा हो जाते हैं जहां सभी कार्य psm1 फ़ाइल में तार्किक रूप से ग्लोबेड होते हैं। इसका मतलब स्टैक के निशान पर लाइन नंबर चॉकलेट चायदानी के रूप में उपयोगी हैं।

2. PowerShell डिफ़ॉल्ट त्रुटि ऑब्जेक्ट स्ट्रिंग फ़ॉर्मेटिंग को बदलें जो स्टैक-आधारित वॉन नियॉन आर्किटेक्चर में प्रोग्रामिंग की उपयोगिता का 99% हिस्सा निगलती है।

   • सी # कमोबेश यही अधिकार मिलता है। पॉवरशेल आधे से बहुत चालाक है।

3. नल पुनर्निर्देशन को ठीक करें ताकि अशक्त डिवाइस में आउटपुट स्ट्रीम को पुनर्निर्देशित करने के तीन अलग-अलग तरीके प्रदर्शन में बराबर हों।

4. डायनामिक स्कोपिंग ठीक करें:

function a($f) {& $f}
function main() {
    $f = {write-host 'success'}
    a {& $f} # stack-overflow
    a {& $f}.getnewclosure() # okay
}
[void] (main)

1. चर कैप्चर को ठीक करें:

set-strictmode -version 'latest'
$erroractionpreference = 'stop'

function main() {
    $a = 'foo'
    $f = {
        $g = {$a}.getnewclosure()
        & $g # "variable '$a' cannot be retrieved because it has not been set."
    }.getnewclosure()
    & $f
}

main

1. आउटपुट जमा होता है; return अन्य भाषाओं के समान काम नहीं करता है; इसे ठीक करो।

2. PowerShell में ऑब्जेक्ट्स के बाह्य संसाधनों के निपटान के लिए सिंटैक्टिक चीनी नहीं है

3. पॉवरलाइट को फिर से लिखें। यह बहुत बुरा है। कोड की सैकड़ों लाइनों के साथ कार्य, अपवादों को निगला, कोई परीक्षण कवरेज नहीं।

4. मॉड्यूल कैशिंग कैसे काम करता है से छुटकारा पाएं।

   • कैश थ्रेड-सुरक्षित नहीं है। WTF?
   • विश्लेषण प्रयोजनों के लिए एक मॉड्यूल कैशिंग की पूरी अवधारणा एक कीचड़ / हैक है। मुझे पता है कि Microsoft के भीतर इस सुविधा के लिए बहुत बड़ा समर्थन है क्योंकि PowerShell बहुत धीमी गति से चल रही है, लेकिन एक सच्चे निर्धारण के लिए मेरा अगला सुझाव देखें।
   • केवल अपनी AnalysisCache को
   • विश्लेषण के उद्देश्यों के लिए मॉड्यूल की कैशिंग मॉड्यूल की रन-टाइम स्थिति के लिए कसकर युगल विश्लेषण करती है।

5. "संकलित मॉड्यूल" प्रदान करें कि प्रदर्शन सुधार के लिए पाय फाइलें कैसे संकलित करें।

6. $none शाब्दिक जोड़ें

   • कई जगहों पर $null $none साथ बदलने पर विचार करें
   • इस बात पर पुनर्विचार करें कि पैरामीटर पैरामीटर कैसे काम करता है, और मापदंडों के लिए $none विशेष मूल्य पारित करने की अनुमति देता है, ताकि मुझे कोड 5 को कॉल करने के लिए पागल स्विच स्टेटमेंट लिखने की आवश्यकता न हो। COM और C # डायनामिक इसे सही ढंग से करता है - PowerShell इसे एक आपदा बनाता है। उदाहरण यह होगा कि मुझे सदस्यता के प्रकार पर आधारित ReportingServicesTools मॉड्यूल में SSRS रिपोर्ट के लिए परिनियोजन कॉन्फ़िगरेशन को गतिशील रूप से कैसे मैप करना है। मैं केवल संपत्तियों के एक बैग को पास करना पसंद करूंगा और अंत उपयोगकर्ताओं के लिए बाहरी जटिलता के बजाय बल के साथ आंतरिक रूप से जटिलता से निपटना चाहता हूं। ParameterSetName केवल एक टेम्पलेट के रूप में एक अवधारणा के रूप में उपयोगी है, प्रोग्रामिंग के खिलाफ अच्छा नहीं है। यह अंतर्मुखता के साथ तदर्थ बहुरूपता को पिघलाता है।

@Jzabroski के बारे में ErrorRecord फ़ॉर्मेटिंग के बारे में, इस पर चर्चा करने के लिए एक अलग मुद्दे का उपयोग किया गया है: https://github.com/PowerShell/PowerShell/issues/3647 , क्योंकि फ़ॉर्मेटिंग को ब्रेकिंग परिवर्तन नहीं माना जाता है, हम वहां सुधार कर सकते हैं।

आपके कुछ अन्य अनुरोध संभावित रूप से एडिटिव हैं और ब्रेकिंग नहीं हैं, इसलिए उन्हें अलग-अलग मुद्दे होने चाहिए। यह विशिष्ट मुद्दा अगर हमारे पास एक मौका था तो बदलाव के लिए अनुरोधों पर चर्चा कर रहा है और पीएस के नए प्रमुख संस्करण को करने का औचित्य साबित कर सकता है।

@ जेजब्रोस्की एररकार्ड फॉर्मेटिंग के बारे में, चर्चा करने के लिए इस्तेमाल किया जाने वाला एक अलग मुद्दा है: # 3647, क्योंकि फॉर्मेटिंग को ब्रेकिंग परिवर्तन नहीं माना जाता है, हम वहां सुधार कर सकते हैं।

_ क्यों_ क्या यह ब्रेकिंग चेंज नहीं है? क्योंकि डेवलपर्स को पहली बार में त्रुटि संदेशों में तार पर मिलान नहीं करना चाहिए? मुझे लगता है कि यह मान्य है। लेकिन यह अभी भी डाउनस्ट्रीम उपभोक्ताओं को तोड़ देगा।

आपके कुछ अन्य अनुरोध संभावित रूप से एडिटिव हैं और ब्रेकिंग नहीं हैं, इसलिए उन्हें अलग-अलग मुद्दे होने चाहिए।

आपको क्या लगता है कि आप संभावित रूप से एडिटिव हैं? मैं उनके लिए मुद्दे बना सकता हूं, इसलिए हम इस चर्चा को समाप्त नहीं करेंगे, लेकिन मैंने आज सुबह इस सूची को ध्यान से रखा। मैं रोष के साथ पावरशेल से नफरत करता हूं और गड़गड़ाहट और बिजली का विस्फोट करने के जुनून के साथ। पावरशेल एक कसाई चाकू से गेंदबाजी करने वाली गेंद है। एक शीर्ष 5 सबसे शर्मनाक क्षणों में एक इंजीनियर के रूप में सभी PowerShell का उपयोग करते समय हुआ। मुझे वह समय कभी वापस नहीं मिलेगा।

मैंने अपने सुझावों को यह स्पष्ट करने के लिए अपडेट किया है कि ये क्यों (और भयानक) परिवर्तन सुझावों को तोड़ रहे हैं।

आउटपुट जमा होता है; वापसी अन्य भाषाओं के समान काम नहीं करती है; इसे ठीक करो।

return व्यवहार करता है जैसा कि आप इसे class पद्धति के भीतर की अपेक्षा करते हैं। जिस तरह से एक नियमित / उन्नत पीएस फ़ंक्शन में "आउटपुट जमा होता है" शेल स्क्रिप्टिंग वातावरण जैसे कोर्न शेल और बैश के लिए बहुत विशिष्ट है। यही है, कंसोल से कई कमांड कॉपी करें और उन्हें एक फ़ंक्शन में रखें। जब आप उस फ़ंक्शन को लागू करते हैं, तो यह प्रत्येक कमांड से उसी तरह आउटपुट होता है जैसे आपने कंसोल से उन कमांड को निष्पादित किया था।

PowerShell के साथ मेरा प्राथमिक सार यह है कि नियमित / उन्नत फ़ंक्शन मामले में, return को कभी भी तर्क नहीं लेना चाहिए। क्योंकि कुछ इस तरह:

return $foo

वास्तव में के रूप में निष्पादित किया जाता है:

$foo
return

इससे लोगों को समझ में आता है कि वे रिटर्न का उपयोग करके आउटपुट को नियंत्रित कर सकते हैं और वे नहीं कर सकते।

return व्यवहार करता है जैसा कि आप इसे class पद्धति के भीतर की अपेक्षा करते हैं। जिस तरह से एक नियमित / उन्नत पीएस फ़ंक्शन में "आउटपुट जमा होता है" शेल स्क्रिप्टिंग वातावरण जैसे कोर्न शेल और बैश के लिए बहुत विशिष्ट है।

मैं लोगों को यह कहते हुए सुनता हूं, जिसमें @BrucePay ( जोर मेरा , नीचे, उसे उद्धृत करते हुए देखें) शामिल हैं, लेकिन नीचे की रेखा है:

• कोर्न शेल में, रिटर्न एक फ़ंक्शन , अवधि से
• बैश में, रिटर्न एक फ़ंक्शन , अवधि से

केवल PowerShell में हमारे पास यह अतार्किक "रिटर्न नहीं लौटाता है" गैर-समझ है और आउटपुट जमा होता है। यह एक शानदार मेमोरी लीक है, और आपको इसे इस तरह से सोचना चाहिए।

ईमानदार होने के लिए, पॉवरशेल एक्शन में हर जगह मैं "समस्याओं" वाक्यांश के लिए खोज करता हूं, मैं vZeroTechnicalDebt सूची में कुछ जोड़ सकता हूं। यहाँ ब्रूस ने रिटर्न स्टेटमेंट के बारे में लिखा है:

7.3 पुनर्मूल्यांकन से प्राप्त होने वाले मूल्य
अब कार्यों से लौटने के मूल्यों के बारे में बात करने का समय है। हम यह सब साथ कर रहे हैं, लेकिन हमें कुछ उजागर करने की आवश्यकता है। क्योंकि PowerShell एक शेल है, यह परिणाम नहीं लौटाता है - यह आउटपुट लिखता है या वस्तुओं का उत्सर्जन करता है। जैसा कि आपने देखा है, किसी भी अभिव्यक्ति या पाइपलाइन का परिणाम कॉलर को परिणाम वस्तु का उत्सर्जन करना है। कमांड लाइन पर, यदि आप अर्धविराम द्वारा अलग किए गए तीन भाव टाइप करते हैं, तो तीनों कथनों के परिणाम आउटपुट हैं:
[...]
पारंपरिक दृष्टिकोण में, आपको परिणाम चर को शुरू करना होगा, $result , उत्पादित होने वाले सरणी को पकड़ने के लिए, प्रत्येक तत्व को सरणी में जोड़ें, और फिर सरणी का उत्सर्जन करें:

PS (16) > function tradnum
> {
> $result = @()
> $i=1
> while ($i -le 10)
> {
> $result += $i
> $i++
> }
> $result
> }

यह कोड काफी अधिक जटिल है: आपको एक के बजाय अब फ़ंक्शन में दो चर का प्रबंधन करना होगा। यदि आप किसी ऐसी भाषा में लिख रहे थे जो स्वचालित रूप से सरणी के आकार का विस्तार नहीं करती थी, तो यह और भी जटिल होगी, क्योंकि आपको मैन्युअल रूप से सरणी का आकार बदलने के लिए कोड जोड़ना होगा। और भले ही PowerShell स्वचालित रूप से सरणी का आकार बदल देगा, लेकिन स्ट्रीम किए गए आउटपुट को कैप्चर करने की तुलना में यह कुशल नहीं है। मुद्दा यह है कि आप यह सोचें कि आप उन सुविधाओं का उपयोग कैसे कर सकते हैं जो पॉवरशेल में सुधार के लिए प्रदान करता है
तुम्हारा कोड। यदि आप अपने आप को ऐसा कोड लिखते हैं जो स्पष्ट रूप से सरणियों का निर्माण करता है, तो यह देखने के लिए विचार करें कि क्या इसके बजाय स्ट्रीमिंग का लाभ लेने के लिए इसे फिर से लिखा जा सकता है।

मुझे लगता है कि इस सुविधा के पीछे की प्रेरणा अच्छी है, लेकिन एक ही लक्ष्य को प्राप्त करने के लिए बहुत साफ-सुथरे, आसानी से पढ़े जाने वाले तरीके हैं: एकल वस्तु से वस्तुओं के संग्रह तक प्रोत्साहन। इसके अलावा, PowerShell में पहले से ही पुनर्निर्देशन के लिए आउटपुट वापस करने का एक सरल तरीका है: Write-Output ।

बैश में, रिटर्न एक फ़ंक्शन, अवधि से बाहर निकलता है।

है ना? बैश सिर्फ एक ही उत्पादन जमा करता है:

hillr@Keith-Dell8500:~$ function foo() {
> echo "Hello"
> ls ~
> date
> return
> echo "World"
> }
hillr@Keith-Dell8500:~$ foo
Hello
bar.ps1  date.txt   test.ps1
baz.ps1  dotnet    powershell-preview_6.2.0-rc.1-1.ubuntu.16.04_amd64.deb
Tue Mar 26 16:06:18 DST 2019

पॉवरशेल की तरह, बैश अभी भी return स्टेटमेंट तक प्रत्येक कमांड से सब कुछ आउटपुट करता है।

आह, मुझे लगता है कि आप $? में जो लौटा रहे हैं, उसका जिक्र कर रहे हैं। हाँ, यह एक अंतर है। मुझे लगता है कि सफलता / असफलता को इंगित करने के लिए उन्हें बैश में int रिटर्न मान होना चाहिए। PS में, $? फ़ंक्शन द्वारा उत्पन्न त्रुटियों के आधार पर एक सफलता के रूप में सफलता / विफलता को इंगित करता है। व्यवहार में, मुझे नहीं लगता कि $? का उपयोग इतना अधिक नहीं है। मैं इसके बजाय try/catch/finally माध्यम से अपवाद हैंडलिंग का उपयोग करता हूं।

हाँ। return का उन भाषाओं में केवल एक ही उद्देश्य है। PowerShell में, इसे आउटपुट के साथ मिलाया जाता है। रिटर्न वैल्यू और आउटपुट स्ट्रीम को मिलाना एक बुरा विचार है। यह मेमोरी लीक जैसी प्रदर्शन समस्याओं को भी जन्म दे सकता है। आप वास्तव में क्या चाहते हैं सह-दिनचर्या या "उपज वापसी", या जनरेटर, जनरेटर-बिल्डरों और स्कैनर (चिह्न के रूप में)। इसका कारण यह है कि इनपुट की खपत आलसी है और विफलता गणना के भाग को अनुमति देते हुए गणना को स्थगित कर देती है।

आप "आउटपुट पुनर्निर्देशन" को वास्तव में दो ऑब्जेक्ट के रूप में सोच सकते हैं: एक प्रोसेसर और एक प्रोसेसरऑनटेक्स्ट।

संपादित करें: मैं देखता हूं कि आपने मेरे मूल बिंदु को क्यों दोहराया। आपने सोचा था कि मैं कह रहा था कि आउटपुट देने में सक्षम होना बुरा है। मैं इसके बजाय PowerShell द्वारा इसे करने के तरीके में आउटपुट वापस करने के लिए इसके खराब होने की बात कह रहा हूं।

मैं इसके बजाय try/catch/finally माध्यम से अपवाद हैंडलिंग का उपयोग करता हूं।

यह बहुत टाइपिंग है, और सभी मामलों में स्पष्ट रूप से इरादा व्यक्त नहीं करता है।

खैर, PowerShell .NET पर आधारित है जो कचरा एकत्र किया जाता है, इसलिए इसे मेमोरी "लीक" से पीड़ित नहीं होना चाहिए। इसका मतलब यह नहीं है कि आपके पास मेमोरी होर्ड नहीं हो सकता है। इसलिए आपको बड़े आउटपुट / संग्रह को संभालते समय थोड़ा सावधान रहना होगा जो किसी चर को सौंपा गया है या किसी प्रकार के हैशटेबल में रखा गया है।

मुझे लगता है कि PowerShell के return कथन का केवल एक ही उद्देश्य होना चाहिए और वह यह है कि जल्दी लौटें - और कुछ नहीं। जब कोई क्या करता है return 42 उस पर कोई प्रभाव नहीं होता $? । यह आउटपुट स्ट्रीम के लिए सिर्फ एक और आइटम आउटपुट (उपज) है।

जैसा कि मैंने पहले उल्लेख किया है, $? PowerShell द्वारा प्रबंधित किया गया है और फ़ंक्शन आउटपुट / रिटर्न के साथ इसका कोई लेना-देना नहीं है। $? उत्पन्न त्रुटियों (या इसके अभाव) के आधार पर सेट किया गया है। इसका मतलब है कि जब आप $res = foo - $ res को फंक्शन फू द्वारा हर ऑब्जेक्ट आउटपुट में शामिल करेंगे। यदि आप यह जानना चाहते हैं कि क्या फ़ंक्शन "विफल" है, तो आप अपने द्वारा निष्पादित प्रत्येक एकल आदेश पर $? का निरीक्षण कर सकते हैं या आप try/catch ब्लॉक में आदेशों का एक गुच्छा लपेट सकते हैं। मुझे पूर्व में बहुत कम टाइपिंग आती है (लिपियों में)।

लोगों को यह कहते हुए सुनें, जिसमें @BrucePay शामिल है (नीचे मेरा जोर देखें, उसे उद्धृत करते हुए), लेकिन नीचे की रेखा है:
कोर्न शेल में, रिटर्न एक फ़ंक्शन, अवधि से बाहर निकलता है।
बैश में, रिटर्न एक फ़ंक्शन, अवधि से बाहर निकलता है।

PowerShell में, रिटर्न एक फ़ंक्शन से बाहर निकलता है, भी:

PS C:\> function test { "hello"; return "!"; "world"}
PS C:\> test
hello
!

रिटर्न वैल्यू और आउटपुट स्ट्रीम को मिलाना एक बुरा विचार है। यह मेमोरी लीक जैसी प्रदर्शन समस्याओं को भी जन्म दे सकता है

कोई मिश्रण नहीं है क्योंकि PowerShell में आउटपुट स्ट्रीम और रिटर्न मान के बीच कोई अंतर नहीं है। आप बात कर रहे हैं जैसे कि फ़ंक्शन स्ट्रैडआउट को स्ट्रिंग्स लिखता है और अलग से कॉल करने वाले को विस्मयादिबोधक चिह्न देता है, लेकिन यह नहीं है। write-output ओर इशारा करना एक ही गलती की तरह लगता है; ये सभी: write-output 'x' , 'x' , return 'x' एक ही आउटपुट पथ के नीचे कुछ भेजते हैं, पाइपलाइन के लिए। कोई अलग रिटर्न वैल्यू नहीं है।

आप वास्तव में क्या चाहते हैं सह-दिनचर्या या "उपज वापसी", या जनरेटर, जनरेटर-बिल्डरों और स्कैनर (चिह्न के रूप में)। टी

इसका मतलब यह होगा कि यदि आपने कमांड लाइन पर कमांड लिखा है, तो इसे स्क्रिप्ट या फ़ंक्शन में रखें, यह अलग तरह से व्यवहार करेगा:

PS C:\> robocopy /whatever
PS C:\> "robocopy /whatever" | set-content test.ps1; .\test.ps1
PS C:\> function test { robocopy /whatever }

मुझे तीनों मामलों में एक ही आउटपुट देखना पसंद है, दो मामलों में आउटपुट निगल नहीं गया क्योंकि मैंने बिना किसी कारण के yield return नहीं किया। जिस तरह से PowerShell करता है वह एक शेल और लेखन शेल / बैच स्क्रिप्ट के लिए सुसंगत और सुविधाजनक है - कुछ ऐसा जो आपने कमांड लाइन पर लिखा था और इसे कहीं रखकर आप इसे बार-बार कॉल कर सकते हैं। ऐसा करना पूरी तरह से नहीं बदलना चाहिए कि कोड कैसे व्यवहार करता है।

इसका कारण यह है कि इनपुट की खपत आलसी है और विफलता गणना के भाग को अनुमति देते हुए गणना को स्थगित कर देती है।

PowerShell पाइपलाइन रनटाइम द्वारा नियंत्रित की जाती है, अगर मैं समझता हूं कि आप क्या कह रहे हैं, तो वह पहले से ही ऐसा करने में सक्षम है:

PS D:\> 1..1mb |foreach { write-verbose -Verbose "incoming number: $_"; $_ } |select -first 3
VERBOSE: incoming number: 1
1
VERBOSE: incoming number: 2
2
VERBOSE: incoming number: 3
3

select तीन चीजों के होते ही पाइपलाइन को समाप्त कर दिया जाएगा। बाकी लाखों संख्याओं को foreach में नहीं खिलाया गया। पाइपलाइन के नीचे जाने वाली जानकारी एक "पुश" मॉडल है, लेकिन यह पावरशेल इंजन द्वारा नियंत्रित है।

हालांकि, एक शेल होने के नाते, यह स्पष्ट नहीं है कि "अभिकलन को निलंबित करने में इनपुट विफलता" के लिए इसका क्या अर्थ होगा यदि इनपुट एक मूल कमांड या पीएस cmdlet के बाहर कुछ से आ रहा है।

"संकलित मॉड्यूल" प्रदान करें कि प्रदर्शन सुधार के लिए पाय फाइलें कैसे संकलित करें।

मुझे लगता है कि अधिक प्रदर्शन के लिए इच्छित समाधान C # में मॉड्यूल लिखना है। PowerShell कोड कुछ स्थितियों में JIT संकलित हो जाता है, लेकिन PS टीम के सदस्यों ने कहा है कि इससे पहले कि वे अनुकूलन के लिए उपयोगकर्ताओं को समाप्त करने के लिए इसे उजागर करने की कोई योजना नहीं है, जैसे IIRC डोंगबो वांग के PS Conf Asia ने PS इंजन इंटर्नल Nov 2018

नल पुनर्निर्देशन को ठीक करें ताकि अशक्त डिवाइस में आउटपुट स्ट्रीम को पुनर्निर्देशित करने के तीन अलग-अलग तरीके प्रदर्शन में बराबर हों।

वांछनीय, लेकिन यह संभावना नहीं लगती है; $null = 4 एक सरल चर बाँध है, 4 | out-null को एक पाइपलाइन शुरू करने और कमांड रिज़ॉल्यूशन करने के ओवरहेड की आवश्यकता है - क्या होगा अगर किसी ने जानबूझकर out-null एक प्रॉक्सी-रैपर बनाया है जो इसमें बदलाव कर रहा है कोड? क्या वह तकनीकी ऋण, जिसे चलाने के लिए एक पाइपलाइन और cmdlet के लिए पूछना एक अभिव्यक्ति की तुलना में धीमा है?

डायनामिक स्कोपिंग ठीक करें:

यदि आप "गतिशील स्कूपिंग का उपयोग नहीं करते हैं", तो यह एक जानबूझकर पसंद था, उदाहरण के लिए ब्रूस पेलेट ने कहा कि "डायनेमिक स्कूपिंग, यह लगभग कभी उपयोग नहीं किया जाता है; इससे पहले, 30 साल पहले की तरह एलआईएसपी में डायनेमिक स्कूपिंग था, लेकिन यह बहुत दुर्लभ रूप से उपयोग किया जाता है। अब। इसका उपयोग करने का कारण यह है: कि गोले क्या उपयोग करते हैं। गोले गतिशील स्कोपिंग के बराबर का उपयोग करते हैं, यहां तक ​​कि बैश, और यूनिक्स गोले गतिशील स्कूपिंग के बराबर का उपयोग करते हैं, जहां कॉलर के संदर्भ से चर - उनके मामले में कॉलर के संदर्भ से चर को बाल संदर्भ में कॉपी किया जाता है। [..] एक संशोधन के साथ, सामान्य रूप से डायनेमिक स्कोपिंग में आप कॉल श्रृंखला को देखते हैं और चर को सेट करते हैं जहां यह मौजूद है, हम ऐसा नहीं करते हैं, हम चर सेट करते हैं वर्तमान दायरे में हर समय, और फिर से जो गोले के व्यवहार का अनुकरण करता है "।

यह कष्टप्रद हो सकता है, लेकिन क्या यह एक शेल के लिए "तकनीकी ऋण" है, और अगर इसे बदल दिया गया तो यह "जीरोइलेक्ट्रिकलडेब" होगा?

खैर, PowerShell .NET पर आधारित है जो कचरा एकत्र किया जाता है, इसलिए इसे मेमोरी "लीक" से पीड़ित नहीं होना चाहिए। इसका मतलब यह नहीं है कि आपके पास मेमोरी होर्ड नहीं हो सकता है। इसलिए आपको बड़े आउटपुट / संग्रह को संभालते समय थोड़ा सावधान रहना होगा जो किसी चर को सौंपा गया है या किसी प्रकार के हैशटेबल में रखा गया है।

मेरे पास एक सिस्टम प्रशासक था, जो एक इंजीनियर नहीं है, 8 टीबी फ़ाइल शेयर पर सभी फाइलों पर मेटाडेटा को सारणीबद्ध करने की कोशिश करने के लिए कुछ तर्क लिखें। यह अच्छी तरह से समाप्त नहीं हुआ: यह बहुत मेमोरी खा गया, और सिस्टम को 100% सीपीयू पर भी आंका गया ... हम स्क्रिप्ट शुरू होने के बाद भी बॉक्स में लॉग इन नहीं कर सके, और सर्वर को बचाने के लिए एकमात्र समाधान _in प्रोडक्शन_ इसे हार्ड रिबूट करना था।

मेरे अनुभव में, PowerShell इस तरह की बकवास लिखना आसान बनाता है। आप कर सकते हैं, और समालोचना, मेरी प्रतिक्रिया हालांकि आप चाहते हैं। यह इस तथ्य को नहीं बदलेगा कि PowerShell उन लिपियों को लिखना आसान बनाता है जो उत्पादन मशीनों को प्रभावी ढंग से क्रैश कर सकते हैं।

@jzabroski आप स्क्रिप्ट के किसी भी विवरण साझा कर सकते हैं?

पॉवरशेल लोगों को मेमोरी के उपयोग को कम करने के लिए जानबूझकर एक लोडिंग डेटासेट ( $files = get-childitem; $files | foreach-object ) के बजाय पाइपलाइन स्ट्रीमिंग ( get-childitem | foreach-object {} ) को प्रोत्साहित करने की कोशिश करते हैं। क्या यह है कि अप-फ्रंट लोडिंग?

क्या समान फ़ाइलों को इकट्ठा करने के लिए Group-Object का उपयोग किया गया था? हाल ही में ग्रुप-ऑब्जेक्ट के प्रदर्शन में सुधार हुआ है, जो कि सीपीयू के उपयोग को कम करेगा, यदि मेमोरी का उपयोग नहीं करता है।

PowerShell डिफ़ॉल्ट रूप से सिंगल-कोर है, क्या इसमें जॉब / रनस्पेस कोड था, क्या यह सिंगल कोर सर्वर था? PS 6.1 में स्टार्ट-थ्रेडजॉब है जो सीपीयू के उपयोग को नियंत्रित करने में मदद करने के लिए कम ओवरहेड और थ्रॉटलिंग के साथ कई नौकरियों की अनुमति देता है।

मेरे अनुभव में, PowerShell इस तरह की बकवास लिखना आसान बनाता है

सभी ट्यूटोरियल और किताबें जो आपको $files = @(); $files += $f लिखने के लिए कहती हैं, उनके लिए cpu साइकिल और मेमोरी में दुनिया का एक छोटा सा भाग्य अवश्य होना चाहिए। यह एक ऐसा पैटर्न है जो धीमा है, प्रोसेसर और मेमोरी का महंगा है, और चिंताजनक रूप से आम है। मुझे उत्सुकता है कि क्या स्क्रिप्ट में वह पैटर्न था? (और अगर कोई तरीका है जिससे हम इसे पीछे की संगतता को तोड़े बिना ब्लॉक कर सकते हैं, या भविष्य के ब्रेकिंग-परिवर्तन में सरणियों पर + = अमान्य बना सकते हैं?)।

लेकिन, यहां एक व्यापार है। Get-ChildItem -Recurse 22 अक्षर हैं और सिर्फ मेरे C: ड्राइव, C # पर 800 + MB की रैम खाता है, लाइन का उपयोग करता है और फ़ाइल मेटाडाटा बिल्कुल नहीं मिलता है, और होगा अधिक 80MB की तरह। यह PS लीक मेमोरी नहीं है, यह PS उपयोगकर्ता सुविधा प्राप्त करने के लिए इसका उपयोग कर रहा है।

क्या कोई ऐसी भाषा है जहाँ आपको इस बात की परवाह नहीं है कि यह कैसे काम करती है, उपयोगी कोड लिख सकती है, बुरा कोड नहीं लिख सकती है, और एक कुशल प्रोग्रामर होने की ज़रूरत नहीं है? (और जो एक खोल भी है?)

क्या आपके पहले प्रस्तावित बदलावों में से किसी ने भी स्क्रिप्ट में काम किया है?

आप फ़ाइलों को सूचीबद्ध करने के लिए एक बैश स्क्रिप्ट लिख सकते हैं, हर एक के लिए एक प्रक्रिया शुरू कर सकते हैं, जब तक कि आपका सर्वर खत्म न हो जाए और आप उसमें एसएसएच भी नहीं कर सकते। आप एक पायथन स्क्रिप्ट लिख सकते हैं, जो os.walk() फ़ाइल फ़ाइल ट्री है और प्रत्येक फ़ाइल के लिए os.stat() कॉल करती है और कम मेमोरी का उपयोग करती है और तेज़ी से खत्म होती है - लेकिन 1 के बजाय 10 लाइनें लेती है और आपको अभी भी ध्यान रखना है ओएस और कोड विवरण के बारे में देखभाल (और यह अभी भी एक शेल नहीं है, और पीएस प्रोवाइडर्स के साथ काम नहीं करेगा)।

मैं चाहूंगा कि PS को "अधिक सफलता के गड्ढे" और कम यात्रा के खतरे हों। फास्ट फ़ाइलनाम सूची उनमें से एक है जिसके लिए मैं बहुत अधिक उपयोग करता हूं। मूल रूप से इसे पूरी तरह से अलग भाषा के रूप में बदलना, और जिन क्षेत्रों में यह अच्छा होता है, वे ऐसा नहीं करेंगे।

आप पाइथन चाहते हैं, पाइथन मौजूद है, यह एक सुंदर भाषा है, यह दो अलग-अलग दुनिया में फिट होने और एक अलग ओएस (क्यों, माइक्रोसॉफ्ट), या Microsoft की प्रतिबद्धता से तीस साल पुराने खोल के प्रतिफल और फ़ंक्शन रिटर्न सिमेंटिक्स को रखने की कोशिश करके नहीं है। पश्चगामी संगतता (और .Net के साथ जुनून), इसलिए यह उन सभी सवालों को चकमा देता है, बजाय उनका सामना करने के।

मैं चाहूंगा कि PS को "अधिक सफलता के गड्ढे" और कम यात्रा के खतरे हों।

अगर मैं उस अकेले के लिए बीस अंगूठे जोड़ सकता हूं, तो मैं करूंगा। यह वास्तव में पैटर्न और दृष्टिकोण है PowerShell को लेने की आवश्यकता है।

For-EveryObject PowerShell संग्रह लेने और इसे अपठनीय स्टैक के निशान में बदलने के लिए एक PowerShell फ़ंक्शन है।

आज, मैंने EC2 विंडोज डिस्क को सूचीबद्ध करने के लिए अमेज़ॅन द्वारा लिखित एक स्क्रिप्ट ली: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-volumes.html#windows -list-disks

अंदाज़ा लगाओ? मेरे पास इस PC पर Initialize-AWSDefaults सेट-अप नहीं था, और चूंकि स्क्रिप्ट लेखक ने ForEach-Object का उपयोग किया था, मेरे स्टैक ट्रेस इस _garbage_ की तरह लग रहे थे:

PS C:\Windows\system32> D:\Installs\PowerShell\List-EC2Disks.ps1
Could not access the AWS API, therefore, VolumeId is not available. 
Verify that you provided your access keys.
ForEach-Object : You cannot call a method on a null-valued expression.
At D:\Installs\PowerShell\List-EC2Disks.ps1:39 char:12
+ Get-disk | ForEach-Object {
+            ~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [ForEach-Object], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull,Microsoft.PowerShell.Commands.ForEachObjectCommand

ऐसा तब होता है जब लोग अपने कोड_ में ForEach-Object भावों का उपयोग करते हैं। स्टैक के निशान _always भयानक_ हैं। यह फिर से लिखना दर्दनाक है। शुक्र है, यह सिर्फ एक स्क्रिप्ट है जिसे मैं एक यादृच्छिक फ़ाइल में कॉपी-पेस्ट करता हूं, सहेजता हूं, और चलाता हूं। यदि यह एक बड़े मॉड्यूल में एक समस्या है, तो मुझे मॉड्यूल के लिए स्रोत कोड प्राप्त करना होगा, स्क्रिप्ट को फिर से लिखना होगा, ईश्वर से यह उम्मीद करना होगा कि मैं इसे फॉरएच-ऑब्जेक्ट एक्सप्रेशन में परिवर्तित करके मॉड्यूल के पार कुछ भी नहीं तोड़ूंगा और आशा करता हूं मैं यह पता लगा सकता हूं कि वास्तव में त्रुटि कहां है, इसलिए मैं अपना काम_ कर सकता हूं। और अब मेरे पास कुछ कस्टम कोड हैं जो मैंने कुछ प्रमुख रिपॉजिटरी से लिए थे, बस यह पता लगाने के लिए कि मुझे कुछ त्रुटि क्यों हो रही है क्योंकि PowerShell के Write-Error IS throw new Exception("message", ex) # सरल मुहावरे की तुलना में AWFUL है।

for ($var in $list) का उपयोग करने के लिए इसे फिर से लिखना, चर $results में परिणाम जमा करना, मुझे निम्न त्रुटि मिलती है:

PS C:\Windows\system32> D:\Installs\PowerShell\List-EC2Disks.ps1
Could not access the AWS API, therefore, VolumeId is not available. 
Verify that you provided your access keys.
You cannot call a method on a null-valued expression.
At D:\Installs\PowerShell\List-EC2Disks.ps1:58 char:26
+ ... lDevice = If ($VirtualDeviceMap.ContainsKey($BlockDeviceName)) { $Vir ...
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

ओह, और वैसे भी, हर बार मुझे यह करना पड़ता है कि मैं सूची में आइटम जोड़ने के लिए पॉवरशेल के बेवकूफ नियमों को याद नहीं रख सकता, इसलिए मुझे Google https://www.google.com/search?q=powershell+append करना होगा + से + सूची और किसी गैर-सहज ज्ञान युक्त PowerShell के सूची संचालन कैसे हैं के बारे में एक ब्लॉग पोस्ट पढ़ें।

यदि आप C # या ऐसी भाषा नहीं जानते हैं जो यह अच्छी तरह से करती है, तो यह तर्क देना आसान है कि यह व्यवहार ठीक है। हालाँकि, C # इस समस्या को समझदारी से एक AggregateException में अपवाद को लपेटकर संभालता है, ताकि आपको आंतरिक और बाहरी दोनों अपवाद मिलें। शक्ति कोशिका? हा हा हा हा। हाँ, यह बहुत उपयोगी होगा।

@jzabroski आप स्क्रिप्ट के किसी भी विवरण साझा कर सकते हैं?

अफसोस की बात है (_ और खुशी से _), मुझे यह याद नहीं है। यह एक फ़ाइलशेयर था, इसलिए यह लगभग निश्चित रूप से एक या दो कोर सबसे अधिक था। यदि यह दो कोर थे, तो शेष सीपीयू की संभावना विंडोज डिफेंडर द्वारा ली गई थी।

संपादित करें: इसे टीम चैट में मिला।

$big32 = Get-ChildItem D:\Data\Website\Data -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum

एक अतिरिक्त बोनस के रूप में, मैंने सिर्फ उस व्यक्ति से बात की जो इस कमांड को चलाता था (और अविश्वसनीय रूप से बुरा महसूस करता था), और उसने कहा कि उपयोग का मामला "प्रारंभिक प्रतिकृति समूह के लिए सबसे बड़ी 32 फाइलें हथियाने के लिए डीएफएस की आवश्यकता है"।

कोई मिश्रण नहीं है क्योंकि PowerShell में आउटपुट स्ट्रीम और रिटर्न मान के बीच कोई अंतर नहीं है।

मुझे अभी तक लोगों को पहली कोशिश में इसे सही ढंग से उपयोग करना देखना है। फिर, यह वह नहीं है जो बैश करता है या कोई अन्य शेल है। हालांकि यह दो अवधारणाओं को एकजुट करने के लिए एक दिलचस्प प्रयोग था, यह एक पठनीयता के दृष्टिकोण से एक पूर्ण और पूरी तरह से आपदा थी। यह मदद नहीं करता है कि 16 महीने के लिए Write-Output PowerShell v6 में टूट गया था।

@jzabroski आपके For-EachObject आउटपुट से ऐसा लगता है कि आप Powershell Core (जो कि इस रिपॉजिटरी को समर्पित है) का उपयोग नहीं कर रहे हैं, क्या आप Powershell Core को आज़मा सकते हैं और देख सकते हैं कि क्या आप इसे पुन: उत्पन्न कर सकते हैं। नवीनतम संस्करण का उपयोग करना सुनिश्चित करें। ध्यान रखें, कि विंडोज़ विशिष्ट कार्यक्षमता (जैसे गेट-डिस्क) पॉवर्सशेल कोर का हिस्सा नहीं है, आपको अपने परीक्षण करते समय इसे ध्यान में रखना होगा।

मुझे अभी तक लोगों को पहली कोशिश में इसे सही ढंग से उपयोग करना देखना है। फिर, यह वह नहीं है जो बैश करता है या कोई अन्य शेल है।

$ test () { ls /tmp; ls /etc/pm; return 5; ls /v*; } ; x=$(test)
$ echo "$x"
tmux-1000
sleep.d
$ echo $?
0

यह दोनों बैश फ़ंक्शन में जमा होने वाली दो अलग-अलग कमांड का आउटपुट है, और बैश C # में रिटर्न फ़ंक्शंस के रूप में काम नहीं कर रहा है। क्या, विशेष रूप से, "बैश क्या नहीं है"?

आप बैश उदाहरण के लिए रिटर्न वैल्यू को सही तरीके से कैप्चर नहीं कर रहे हैं। $ की वजह से रिटर्न खो गया है? हमेशा अंतिम आदेश है। आपके मामले में 'गूंज'।

$ test () { ls /tmp; ls /etc/pm; return 5; ls /v*; } ; x=$(test)
$ echo $?
5
$ echo $x
tmux-1000
sleep.d

POWERSHELL यह अलग तरीके से करता है

> function test() { ls; return 5 ; ls } ; $x=test
> echo $?
True
> echo $x
    Directory: c:\foo\bar

Mode                LastWriteTime         Length Name
----                -------------         ------ ----

अधिक PowerShell विषमताएँ:

Chocolatey एक RefreshEnv.cmd जोड़ता है जो एक GODSEND है। क्यों यह सिर्फ PowerShell के साथ जहाज नहीं करता है? मुझे अपना शेल फिर से शुरू करने या अपना $ env रीसेट करने के लिए इंटरनेट से कुछ बेवकूफ स्क्रिप्ट डाउनलोड करने की आवश्यकता क्यों है?

@jzabroski यह https://github.com/PowerShell/PowerShell-RFC/pull/92 में लाया गया था, आप इसमें झंकार करना चाहते हैं।

PowerShell प्रदाताओं के लिए एक मानक ऑब्जेक्ट मॉडल बनाएँ: https://github.com/PowerShell/SHiPS/issues/66#issuecomment -368924485

SHiPS मुद्दे पर लिंक 66 में, मैं संभावित cmdlets की रूपरेखा तैयार करता हूं। यह मेरे लिए स्पष्ट नहीं है कि हम इन मुख्य cmdlets के लिए हास्केल टाइपकास्ट व्यवहार जैसा कुछ क्यों लागू नहीं कर सकते हैं।

यह API पहले से ही PowerShell में है।

@iSazonov क्या आप संपादित कर सकते हैं और बोली दे सकते हैं कि आप क्या उत्तर दे रहे हैं, और कुछ संदर्भ जोड़ सकते हैं, जैसे कि उक्त एपीआई के प्रलेखन के लिए हाइपरलिंक? TYVM

@jzabroski srcSystem.Management.Automationnamespaces फ़ोल्डर में फ़ाइलें देखें।

POWERSHELL यह अलग तरीके से करता है

यह bash जो इसे अलग तरीके से कर रहा है - return केवल (पूर्णांक) प्रक्रिया से बाहर निकलने का कोड निर्धारित कर सकता है (यह अन्य प्रोग्रामिंग भाषाओं में "वापसी" का अर्थ नहीं है, यह exit ) ।

PowerShell exit 5 साथ भी ऐसा कर सकता है

यह सिर्फ इतना है कि हम PowerShell में बहुत बार बाहर निकलने वाले कोड का उपयोग नहीं करते हैं (केवल बहुत सारे निर्धारित कार्यों के लिए और अन्य OSes के साथ इंटरोप करते हैं), क्योंकि यह प्रक्रिया-आधारित शेल नहीं है, और फ़ंक्शन को बाहर नहीं निकलना चाहिए।

दिन के अंत में, यही कारण है कि स्टडआउट हैंडल प्रकार का पता लगाना पावरस्ले में उपयोगी नहीं है (और क्यों आउट-नल के लिए "पुनर्निर्देशन" [void] लिए कास्टिंग या असाइन करने के समान नहीं है) $null )

मैं लोगों को नए मुद्दों को दर्ज करने की सलाह देता हूं यदि उनके पास वास्तव में फीडबैक है, जिस पर उन्होंने कार्रवाई की है - चूंकि टीम ने _clearly और unequivocally ने शासन किया है_ PowerShell का एक नहीं-पिछड़ा-संगत संस्करण, मुझे नहीं पता कि यह थ्रेड बस क्यों रखता है ...

चूँकि टीम ने _clearly और unequivocally ने out_ का एक पीछे-पीछे-संगत संस्करण नहीं दिया है

वह मुझे खबर है। यह कैसे स्पष्ट है? कृपया पोस्ट या अन्य प्रलेखन के लिंक प्रदान करें।

यह हम में से कुछ के लिए निराश सा है "हम कभी भी अनुकूलता नहीं तोड़ेंगे" जबकि हम हर दिन कुछ टूट-फूट के साथ कुश्ती करते हैं। इस धागे की बात यह है कि विचारों का मुक्त बाजार इन समस्याओं में से कुछ को हल कर सकता है जब अपस्ट्रीम नहीं होगा।

किसी को यह बहुत लाभकारी हो सकता है कि वह पॉवरशेल को कांटे और न्यूनतम तकनीकी ऋण के साथ एक संस्करण बना सके। वह समूह इस सूत्र में प्रस्तुत विचारों से लाभान्वित होगा। (यह है कि दुनिया अब कैसे काम करती है। सबसे अच्छी शक्तियां जीत सकती हैं।)

मैं दोहराता हूं कि टीम ने पहले से ही पावरशेल से pwsh तक कमांड का नाम बदलकर पावरशेल का एक 'न-बैकवर्ड कंपाउंडर' वर्जन तैयार किया है। शक्ति (शेल) एक खोल है। शेल का काम उन मनुष्यों के लिए गोंद होना है जो डिजिटल सिस्टम को एक साथ जोड़ते हैं। यह न्यूनतम बाहरी निर्भरता के साथ संकलित बाइनरी नहीं है। यहां तक ​​कि पारंपरिक प्रोग्रामिंग भाषाएं भी योजना बनाती हैं और ब्रेकिंग परिवर्तन करती हैं।

POWERSHELL यह अलग तरीके से करता है

यह bash जो इसे अलग तरीके से कर रहा है - return केवल (पूर्णांक) प्रक्रिया निकास कोड सेट कर सकता है (यह नहीं है

मैं अन्य गोले के बारे में उत्सुक हूं। वो क्या करते हैं? korn, csh, आदि।

यहाँ कई भाषाओं में रिटर्न स्टेटमेंट पर चर्चा करने वाला एक लेख है: https://en.wikipedia.org/wiki/Return_statement

यह कहता है कि ऑपरेटिंग सिस्टम [गोले] कई चीजों को वापस करने की अनुमति देता है: रिटर्न कोड और आउटपुट।

मेरी टीम के पास विभिन्न प्रकार की स्क्रिप्ट हैं जो केवल PowerShell 5 में चलती हैं भले ही हम PowerShell 6 का यथासंभव उपयोग करते हैं। मेरे अनुभव में, PowerShell पूरी तरह से पिछड़ा-संगत है कि आधार निश्चित रूप से गलत है। कम से कम कुछ चरम मामले हैं (उदाहरण: ErrorActionPreference सहज रूप से व्यवहार नहीं करना) जिसे निश्चित रूप से एक ब्रेकिंग परिवर्तन के रूप में संबोधित किया जाना चाहिए - ऐसे मामले जहां फिक्सिंग करना ऐसा नहीं करने की तुलना में कम "ब्रेकिंग" होगा।

@chriskuech ErrorActionPreference साथ अपने मुद्दे का विवरण देने वाला एक मुद्दा है?

@ SteveL-MSFT मेरा मानना है कि मोज़ेक @KirkMunro जुड़ा हुआ है कि सीधे @chriskuech टिप्पणी नीचे करने के लिए इस मुद्दे को आप के लिए देख रहे हैं। और हां, मैं मोज़ेक शब्द को एक तकनीकी वार्तालाप में निचोड़ता हूं।

उस ने कहा, @iSazonov ने 1 अक्टूबर, 2018 को @chriskuech मूल मुद्दे को बंद कर दिया: https://github.com/PowerShell/PowerShell/issues/7774 देखें

ऐसा लगता है कि यह सामान अलग-अलग रूपों में सामने आता रहता है, और समिति इसके मुद्दों को बंद करती रहती है।

@ ज़ज़ब्रोस्की ने मेरे मुख्य मुद्दे को मूल कारण को लक्षित किया।

मैंने पहले भी लक्षणों में से एक के आसपास एक मुद्दा दायर किया था: Invoke-WebRequest एक समाप्ति त्रुटि फेंक। मैंने व्यक्तिगत रूप से कई लोगों को देखा है कि पूरी तरह से try / catch boilerplate से निपटने के लिए पूरी तरह से विफल HTTP अनुरोधों को संभालने के लिए है, जो तब होता है क्योंकि आंतरिक .NET विधियाँ त्रुटियों को समाप्त करती हैं। तीन अलग-अलग मामलों में से प्रत्येक में, इंजीनियर ने एक बाहरी जवाब दिया जब मैंने अंतर्निहित व्यवहार को समझाया और इस मुद्दे को कथित तौर पर कभी भी तय नहीं किया जाएगा।

सारांशित करने के लिए , त्रुटियों को समाप्त करना स्क्रिप्ट को समाप्त कर देता है क्योंकि पॉवरशेल रचनाकारों का मानना ​​है कि स्क्रिप्ट तार्किक रूप से त्रुटि से आगे नहीं बढ़ सकती है, लेकिन मुझे नहीं लगता कि यह शाब्दिक रूप से कभी भी है, लेकिन मामला-दर-मामला आधार पर बनाने के लिए ट्रिफ्टर का निर्णय। केवल वे ही तय कर सकते हैं कि वे स्क्रिप्ट को Stop , SilentlyContinue , Continue , आदि के लिए चाहते हैं।

(ऊपर के मुद्दे के लिए स्पर्शरेखा)

यदि PowerShell एक ऑप्ट-इन "ZeroTechDebt" मोड को लागू करता है, तो मुझे निश्चित रूप से लगता है कि $ErrorActionPreference = "Stop" डिफ़ॉल्ट रूप से सेट किया जाना चाहिए। जाहिर है, इस सेटिंग का REPL में कोई मतलब नहीं है और इसलिए इसे सभी परिदृश्यों के लिए डिफ़ॉल्ट रूप से सेट नहीं किया जाना चाहिए, लेकिन सचमुच मेरी सभी लिपियाँ "रक्षात्मक प्रोग्रामिंग" को सक्षम करने के लिए $ErrorActionPreference = "Stop" साथ उपसर्ग करती हैं और "सामान्य" की तरह व्यवहार करती हैं " प्रोग्रामिंग भाषा।

@chriskuech यदि आप पहले से नहीं हैं, तो कृपया RFC के इस संग्रह को एक रूप दें: https://github.com/PowerShell/PowerShell-RFC/pull/187। वे सीधे बात करते हैं कि आप बिना पावरस्ले के एक नए शून्य तकनीक ऋण संस्करण की आवश्यकता के बारे में यहां क्या बात कर रहे हैं।

आप चार आरएफसी को उस रेपो में इश्यू पेज पर अलग-अलग मुद्दों में भी पा सकते हैं यदि इससे उन्हें पढ़ने / पचाने में आसानी होती है। बस मेरे द्वारा पोस्ट किए गए खुले मुद्दों को देखें और आप उन्हें ढूंढ लेंगे

@ स्टीवएल-एमएसएफटी यहां एक ऐसा ही मुद्दा है जो मेरी उत्पादकता को प्रभावित करता है। यह $ErrorActionPreference बल्कि $ConfirmPreference :

नीचे एक बदसूरत स्क्रिप्ट है जो मैंने SQL सर्वर डिस्क वॉल्यूम 64kb पर सेट करने के लिए लिखा था।

Import-Module Storage;

function Format-Drives
{
    # See https://stackoverflow.com/a/42621174/1040437 (Formatting a disk using PowerShell without prompting for confirmation)
    $currentconfirm = $ConfirmPreference
    $ConfirmPreference = 'none'

    Get-Disk | Where isOffline | Set-Disk -isOffline $false
    # The next line of this script is (almost) copy-pasted verbatim from: https://blogs.technet.microsoft.com/heyscriptingguy/2013/05/29/use-powershell-to-initialize-raw-disks-and-to-partition-and-format-volumes/
    Get-Disk | Where partitionstyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -Confirm:$false -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize -IsActive | Format-Volume -FileSystem NTFS -AllocationUnitSize 64kb -Confirm:$false

    # See https://stackoverflow.com/a/42621174/1040437 (Formatting a disk using PowerShell without prompting for confirmation)
    $ConfirmPreference = $currentconfirm
}

Format-Drives

साइड पॉइंट के जोड़े:

1. Format-Volume लिए प्रलेखन अधिक के लिए चाह रहा है। केवल दो उदाहरण? और आधिकारिक दस्तावेज वेबसाइट के साथ सिंक में नहीं है: https://github.com/MicrosoftDocs/windows-powershell-docs/issues/1170
2. स्क्रिप्टिंग भाषा के लिए GUI से बचने के तरीके जानने के लिए मुझे StackOverflow में जाने की आवश्यकता क्यों है?
3. तथ्य यह है कि इतनी त्रुटिपूर्ण / बेवकूफी से मुश्किल है कि "बिना सोचे समझे" सिर्फ https://github.com/PowerShell/PowerShell-RFC/issues/198 जैसे संबंधित मुद्दों को रेखांकित करता है - यह एक और उदाहरण है कि ब्रूस पैलेट का वादा " पॉवरशेल इन एक्शन "जो आपको सही लगता है उसे टाइप करें और यह काम करता है ... पूरी तरह से और पूरी तरह से झूठ है।
4. @ Mklement0 का मुद्दा भी देखें: https://github.com/PowerShell/PowerShell/issues/4568

आवश्यकता -Version में अधिकतम संस्करण निर्दिष्ट करने का कोई तरीका नहीं है

देखें: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-6

जब आप एडवांस्ड फंक्शन्स लिख रहे होते हैं तो यह कष्टप्रद होता है। .NET फ्रेमवर्क लाइब्रेरी को लोड किया जाता है, जहां एपीआई .NET फ्रेमवर्क और .NET कोर के बीच पूरी तरह से अलग होता है, जैसे कि AccessControl API कैसे काम करता है।

@ jzabroski आप संस्करण को निर्दिष्ट

#requires -PSEdition Desktop
# versus
#requires -PSEdition Core

बस एक त्वरित टिप्पणी है कि @rjmholt ने आधिकारिक तौर पर एक चर्चा शुरू कर दी है कि ब्रेकिंग परिवर्तनों को कैसे लागू करें और प्रबंधित करें: # 13129।

साथ ही, # 6817 और # 10967 अधिक व्यवहार हैं जिन्हें एक बार तोड़ने के बाद परिवर्तन की अनुमति दी जाती है।
(उनका एक ही मूल कारण है, https://github.com/PowerShell/PowerShell/issues/10967#issuecomment-561843650 में बताया गया है)।

तथ्य यह है कि , + से अधिक मजबूत है, क्योंकि PowerShell संख्याओं की तुलना में सूचियों के बारे में अधिक है। IMHO।

@rjmholt ने आधिकारिक तौर पर एक चर्चा शुरू कर दी है

मुझे कहना चाहिए कि यह किसी भी अन्य चर्चा से अधिक आधिकारिक नहीं है

मैं आयात और फ़ंक्शन हस्ताक्षरों के संपादन-समय पर कड़ी जाँच करना पसंद करूँगा।
क्या आप नए आयात करने वाले शब्दार्थों को शुरू करने पर विचार कर रहे हैं जैसे कि एक्मास्क्रिप्ट मॉड्यूल प्रदान करते हैं?
कोई और वैश्विक नामस्थान पॉल्यूशन नहीं। धीमी गति से आयात यांत्रिकी।