कृपया जानकारी जोड़ें कि आप संस्करण जोड़ने के लिए पावरशेल भाषा को कैसे बढ़ाना चाहते हैं। cmdletbinding विशेषता में?

मेरा विचार न्यू-स्क्रिप्टफाइलइन्फो जैसा कुछ करना था जो इस तरह एक टिप्पणी शीर्षलेख उत्पन्न करता है:

<#PSScriptInfo

.VERSION 1.0

.GUID 66c837b7-6478-4571-9dec-0621e13df4c3

.AUTHOR Jeff

.COMPANYNAME

.COPYRIGHT 2020

.TAGS

.LICENSEURI

.PROJECTURI

.ICONURI

.EXTERNALMODULEDEPENDENCIES 

.REQUIREDSCRIPTS

.EXTERNALSCRIPTDEPENDENCIES

.RELEASENOTES


.PRIVATEDATA

#>

<# 

.DESCRIPTION 
 This is a cool function 

#> 
Param()

इसे PSFunctionInfo बनाएं और इसे Get-Command पार्स करें। या उसी तरह जैसे कि PowerShell #requires को पार्स कर सकता है, क्या यह #version को पार्स कर सकता है। जहां यह मुश्किल हो जाता है, जब आपके पास एक ही ps1 फ़ाइल में एकाधिक फ़ंक्शन होते हैं, तो फ़ंक्शन लेखक के रूप में मैं जो कुछ भी करता हूं, उसे फ़ंक्शन में संलग्न करने की आवश्यकता होगी। यह एक पार्स की गई टिप्पणी ब्लॉक, नया cmdletbinding() विकल्प, या शायद एक पूरी नई विशेषता हो सकती है।

Function Get-Awesomeness {

 [cmdletbinding()]
 [alias("awe")]
 [outputtype("psobject")]
 [version("1.1.0")]

 Param ()

 ...
}

मुझे सुविधा से कोई मूल्य नहीं दिख रहा है। हम PowerShellGet पर प्रकाशित कर सकते हैं और PowerShell स्क्रिप्ट को केवल मॉड्यूल के रूप में वितरित कर सकते हैं, हम फ़ाइलों के लिए ऐसा नहीं कर सकते। क्या आप किसी व्यावसायिक मामले/कार्यप्रवाह का वर्णन कर सकते हैं?

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

निश्चित रूप से, प्रत्येक फ़ंक्शन को इसकी आवश्यकता नहीं होती है, यहां तक ​​​​कि मॉड्यूल में भी। यदि कोई कमांड-विशिष्ट संस्करण नहीं पाया जाता है, तो मॉड्यूल संस्करण का उपयोग कर मॉड्यूल में किसी फ़ंक्शन के साथ मुझे कोई समस्या नहीं है।

@jdhitsolutions धन्यवाद!

मुझे आपके परिदृश्य में दो घटक दिखाई दे रहे हैं - (1) एक संस्करण ट्रैकिंग प्रणाली, (2) एक वितरण प्रणाली।
पहला जीआईटी (अन्य?) हो सकता है।
यह स्पष्ट नहीं है कि आप स्क्रिप्ट फ़ाइलों को कैसे वितरित करते हैं।

(मैं यह समझने की कोशिश कर रहा हूं कि अनुरोधित विशेषता के लिए सही जगह कहां है।)

मैं नियमित रूप से ग्राहकों पर कार्य छोड़ता हूं, जो पिछली बार के रूप में वर्तमान हैं जब मैंने उन्हें उस विशेष ग्राहक पर उपयोग किया था। एक जिसे मैंने आज एक क्लाइंट के लिए इस्तेमाल किया, वह ध्यान में आता है - getWUlog। यह जानता है कि WinRM और psexec दोनों का उपयोग करके रिमोट सिस्टम से कैसे कनेक्ट किया जाए (यह देखने के लिए जांचता है कि क्या 139 या 5985 खुले हैं) और उस कंप्यूटर से WindowsUpdate लॉग पुनर्प्राप्त करें, इसे स्थानीय कंप्यूटर पर पुनर्प्राप्त करें, और नोटपैड खोलें।

दूसरा getFrameworkVersion है। बस यही करता है - सीआईएम या रिमोट रजिस्ट्री सेवा (फिर से - यह पता लगाने के लिए बंदरगाहों की जांच करता है कि क्या करना है) का उपयोग करके किसी दिए गए कंप्यूटर पर स्थापित .NET फ्रेमवर्क संस्करण को ढूंढना चाहता है, उनको रिपोर्ट करता है, और रिपोर्ट करता है कि कौन से संस्करण अवरुद्ध हैं, यदि कोई।

ये स्टैंडअलोन फ़ंक्शन हैं। मॉड्यूल का हिस्सा नहीं है। लेकिन वे पिछले कुछ वर्षों में नियमित अपडेट से गुजरे हैं।

उनमें से प्रत्येक के लिए एक संस्करण संलग्न करना बहुत अच्छा होगा। अभी, मेरे पास स्रोत के शीर्ष पर "अंतिम संशोधित तिथि" है। उतना उपयोगी नहीं...

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

और पूरी तरह से स्पष्ट होने के लिए, मैं किसी उपयोगकर्ता को, या स्वयं को भी, स्रोत को ट्रैक करने और टिप्पणियों या नोट्स की तलाश करने के लिए मजबूर नहीं करना चाहता।

मैं निश्चित रूप से कुछ स्टैंडअलोन फ़ंक्शंस लिखता/उपयोग करता हूं, लेकिन अधिकांश मॉड्यूल में हैं। और उनमें से अधिकतर यादृच्छिक फ्लोटसम उपकरण हैं जिनका उपयोग स्टैंडअलोन कार्यों के रूप में किया जा सकता है। मैं हमेशा टिप्पणी ब्लॉक के भीतर .NOTES में अर्थपूर्ण संस्करण और चेंजलॉग डालता हूं, और शुरुआत ब्लॉक में [version]$Version , क्योंकि मैं ट्रैक रखना चाहता हूं कि मैंने किसी विशेष फ़ंक्शन में क्या परिवर्तन किए हैं, न कि केवल मॉड्यूल के लिए (जब मैं आंतरिक कार्यों में परिवर्तन करता हूं तो मैं बढ़ता हूं)। [version()] या [cmdletbinding(Version='01.00.0000')] जैसा कुछ होना शानदार होगा; मैं इसे .VERSION से बेहतर पसंद करता हूं क्योंकि मुझे पता है कि बहुत से लोग एक psm1 फ़ाइल में कई फ़ंक्शन डालते हैं (हालाँकि मैं नहीं करता)।
मैं गिट, भी, बीटीडब्ल्यू का उपयोग करता हूं, लेकिन जब भी मैं किसी व्यक्तिगत फ़ंक्शन में बदलाव करता हूं तो मैं हर बार प्रतिबद्ध नहीं होता; मैं उन्हें बंडल करता हूं और जब मैं मॉड्यूल बदलता हूं, आमतौर पर मॉड्यूल संस्करण को प्रतिबद्ध संदेश के रूप में करता हूं। हाँ, हाँ, मुझे पता है, मैं अजीब हूँ।

यदि स्क्रिप्ट $env:PATH में मिलती है, तो यह गेट-कमांड के लिए दिखाई देती है। इसलिए मौजूदा स्क्रिप्टफाइलइन्फो मेटाडेटा को बाहरी स्क्रिप्टइन्फो सदस्यों में मैप करना उचित लगता है जिसमें संस्करण शामिल है।

उस धारणा से सावधान रहें स्टीव। मेरे पास एकाधिक कार्यों के साथ एक एकल ps1 फ़ाइल हो सकती है। मैं विश्वास नहीं करना चाहता कि Get-Command स्क्रिप्ट फ़ाइल ढूंढ सकता है। बिल्ली, मैं एक PowerShell प्रोफ़ाइल स्क्रिप्ट में एक संस्करणित फ़ंक्शन को परिभाषित करना चाह सकता हूं।

मेरी प्रोफ़ाइल स्क्रिप्ट में निश्चित रूप से संस्करणित कार्य हैं।

हमारे पास पहले से ही System.Management.Automation.FunctionInfo प्रकार है जिसमें एक संस्करण संपत्ति है। हमें एक तरीका चाहिए ताकि जब फ़ंक्शन लोड हो जाए, तो संस्करण गुण फ़ंक्शन में मेटाडेटा से पॉप्युलेट हो जाए।

बढ़िया प्रतिक्रिया के लिए सभी का धन्यवाद! मेरे पास अभी भी कुछ प्रश्न हैं। यदि PowerShell को समान नाम वाले कुछ फ़ंक्शन मिलते हैं, तो आप किस व्यवहार की अपेक्षा करते हैं? उच्च संस्करण के साथ फ़ंक्शन चलाएँ? क्या हमें स्कोप को ध्यान में रखना चाहिए (आप वर्तमान स्कोप पुराने फ़ंक्शन में लोड करते हैं - क्या हमें ग्लोबल स्कोप से अधिक नए फ़ंक्शन को कॉल करना चाहिए)? या हम केवल सूचनात्मक विशेषता रखना चाहते हैं?

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

बढ़िया प्रतिक्रिया के लिए सभी का धन्यवाद! मेरे पास अभी भी कुछ प्रश्न हैं। यदि PowerShell को समान नाम वाले कुछ फ़ंक्शन मिलते हैं, तो आप किस व्यवहार की अपेक्षा करते हैं? उच्च संस्करण के साथ फ़ंक्शन चलाएँ? क्या हमें स्कोप को ध्यान में रखना चाहिए (आप वर्तमान स्कोप पुराने फ़ंक्शन में लोड करते हैं - क्या हमें ग्लोबल स्कोप से अधिक नए फ़ंक्शन को कॉल करना चाहिए)? या हम केवल सूचनात्मक विशेषता रखना चाहते हैं?

मुझे नहीं लगता कि किसी ने पीएस के कार्यों को निष्पादित करने के तरीके में कोई बदलाव का सुझाव दिया है। हम सिर्फ उन पर एक संस्करण रखना चाहते हैं। सूचनात्मक और उसी से पूछताछ करने का एक तरीका।

धन्यवाद! अगला प्रश्न मेरे पास है। कुछ फ़ंक्शंस वाली फ़ाइल में फ़ाइल के सभी फ़ंक्शंस के लिए एक संस्करण विशेषता सामान्य हो सकती है। क्या हमें इस पर विचार करना चाहिए?

मेरे पास कुछ विचार हैं जिन्हें मैं पावरशेल स्क्रिप्टिंग के माध्यम से प्रोटोटाइप करने का प्रयास कर सकता हूं।

आप संक्षेप में विचारों को साझा कर सकते हैं।

यही मेरी योजना है।

क्या यह क्लासिक संस्करण या SymVer 2.0 होना चाहिए?

मैं तेजी से आश्वस्त हो रहा हूं कि फंक्शन वर्जनिंग एक अच्छी बात है।

@iSazonov के नवीनतम प्रश्न का उत्तर देने के लिए - यदि हमें इसे प्राप्त करना है, तो SymVer का उपयोग क्यों न करें?

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

##11686 . में प्रोटोटाइप खींचा गया है

आप पीआर से एक आर्टिफैक्ट डाउनलोड कर सकते हैं और नई विशेषता के साथ खेल सकते हैं।

मिठाई।

इसके बारे में सोचते हुए - स्क्रिप्ट के संस्करण को शामिल करने के लिए PSVersionAttribute का विस्तार क्यों न करें। यदि हम संस्करण मॉड्यूल और (उम्मीद है कि अब!) कार्य करते हैं, तो स्क्रिप्ट क्यों नहीं?

PSVersionAttribute स्क्रिप्ट में परिभाषित कार्यों के लिए एक डिफ़ॉल्ट मान के रूप में भी काम कर सकता है।

और इससे पहले कि कोई और पूछे... क्या कार्य निष्पादन को संस्करणबद्ध किया जा सकता है?

हम किसी फ़ंक्शन के कई संस्करण लोड कर सकते हैं, डिफ़ॉल्ट रूप से नवीनतम निष्पादित कर सकते हैं, लेकिन एक -PSFunctionVersion सामान्य पैरामीटर है जो कहता है कि कौन सा विशिष्ट संस्करण चलाना है।
इसमें कोई संदेह नहीं है कि और विकल्प हैं - लेकिन क्या हमें संस्करणबद्ध फ़ंक्शन निष्पादन प्रदान करना चाहिए?

यदि यह एक विशेषता है तो आप इसे हमेशा पुन: उपयोग कर सकते हैं, जैसे कि [CmdletBinding()] को फ़ंक्शन और स्क्रिप्ट दोनों पर कैसे लागू किया जा सकता है, आप हमेशा फ़ंक्शन और स्क्रिप्ट दोनों के लिए [PSVersion()] उपयोग कर सकते हैं। यह एक दिलचस्प दृष्टिकोण की तरह लग रहा है। मैं

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

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

अगर हमें फंक्शन वर्जनिंग को जोड़ना है, तो इसे पूरी तरह से डॉक्यूमेंटेशन तक ही सीमित क्यों रखें? यदि मैं फ़ंक्शन संस्करणों को निर्दिष्ट और क्वेरी कर सकता हूं, तो क्या संस्करण संख्या के आधार पर निष्पादन की अनुमति देना समझदारी नहीं होगी?

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

तो यहाँ अवधारणा का एक प्रमाण है जिसे मैंने ScriptFileInfo कमांड के आधार पर तैयार किया है:
https://gist.github.com/jdhitsolutions/65070cd51b5cfb572bc6375f67bcbc3d

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

और फाइलों का मिश्रण प्राप्त करना।

यदि कोई फ़ंक्शन किसी मॉड्यूल से संबंधित है, तो मैं कमांड वर्जनिंग से परेशान नहीं होने जा रहा हूं। इसे मॉड्यूल द्वारा नियंत्रित किया जाना चाहिए।

सार

PowerShell मेटा डेटा जानकारी जोड़ने और प्राप्त करने के लिए अवधारणा का प्रमाण

पावरशेल मेटा डेटा जानकारी जोड़ने और प्राप्त करने के लिए अवधारणा का प्रमाण - PSFunctionInfo.format.ps1xml

अच्छा जेफ!

तो हम एक ही फ़ंक्शन के कई संस्करणों को कैसे संभालते हैं?
कोई विशिष्ट फ़ंक्शन संस्करण को स्पष्ट रूप से कैसे लोड करता है?
कोई फ़ंक्शन के विशिष्ट संस्करण को स्पष्ट रूप से कैसे निष्पादित करता है?

@doctordns आप यह पता लगाने के लिए ज़िम्मेदार हैं कि क्या चलाना है और कई संस्करणों से निपटना है। मेरा प्रोटोटाइप कोड केवल FunctIon: Psdrive में आइटम सूचीबद्ध कर रहा है और मेटाडेटा जानकारी प्रदर्शित कर रहा है। जहां तक ​​​​मुझे पता है कि आपके पास psdrive में डुप्लिकेट फ़ंक्शन नहीं हो सकते हैं। मेरा लक्ष्य रहा है, अगर मेरे पास स्टैंड अलोन फ़ंक्शन लोड है, तो मैं संस्करण और संभवतः अन्य मेटा डेटा जानकारी पुनर्प्राप्त करने में सक्षम होना चाहता हूं।

जबकि मुझे लगता है कि यह बहुत अच्छा होगा यदि PowerShell ने _embedded_ PSScriptInfo मेटाडेटा को _scripts_ के लिए समर्थन दिया ... कृपया इसे _function_ स्तर पर न करें।

संस्करण तभी उपयोगी होते हैं जब आप उनके बारे में कुछ कर सकते हैं

पावरशेल वर्तमान में कमांड पर संस्करण _reports_ है, लेकिन वास्तविक संस्करण _module_ से आता है। प्रत्येक फ़ंक्शन के लिए अलग-अलग संस्करण होना मददगार नहीं होगा, यह केवल भ्रमित करने वाला होगा। भले ही आप अपना कोड कैसे वितरित करें, आप उप-फ़ाइल "हंक्स" वितरित नहीं कर रहे हैं और उपयोगकर्ता एक व्यक्तिगत फ़ंक्शन (या पूर्ण फ़ाइल को छोड़कर कुछ भी) लोड नहीं कर सकता है - इसलिए उन्हें संस्करणित करने का प्रयास करने का कोई मतलब नहीं है।

मुझे लगता है कि हमें मॉड्यूल और स्क्रिप्ट के लिए संस्करणों की आवश्यकता है। फ़ंक्शंस को उनके संस्करण को _module_ से इनहेरिट करना चाहिए जिसमें वे शामिल हैं। लिपियों को अपने स्वयं के संस्करण की आवश्यकता होती है।

रिकार्ड के लिए:

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

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

@ जयकुल मुझे लगता है कि हम में से कई पहले ही कह चुके हैं कि यह वास्तव में हमारे लिए उपयोगी होगा और हम वास्तव में एकल कार्यों को वितरित कर रहे हैं।

आईएमओ, सब कुछ मॉड्यूल की जरूरत नहीं है।

प्रस्तावित सुविधा आपके लिए उपयोगी नहीं हो सकती है। और यह ठीक है। लेकिन यह हम में से दूसरों के लिए है।

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

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

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

मैं 7.1 से सहमत हूं।

साथ ही, मैं उपयोगकर्ताओं को जानता हूं, और मैं एक बोतल या तीन शर्त लगाऊंगा कि एक दस्तावेज़ समाधान केवल संस्करण आधारित रनटाइम सुविधाओं के लिए अनुरोध उत्पन्न करेगा। मैं चाहता हूं कि हम एक पूर्ण और सुरुचिपूर्ण और साथ ही इंजीनियर समाधान पर विचार करें। .

हमारे पास पहले से ही स्टैंडअलोन फ़ंक्शंस के लिए एक समाधान है - पिछली एक भरी हुई जीत। :-)

विभिन्न संस्करणों आदि की लोडिंग को नियंत्रित करने की क्षमता के बिना यह एक ऐसी सुविधा है जिसे हम अभी के बिना करने में सक्षम हो सकते हैं।

यह हमें हर बार कॉल किए जाने पर फ़ंक्शन के संस्करण की जांच करने के लिए मजबूर करेगा। यह प्रदर्शन कारणों से पूरी तरह से अस्वीकार्य है। मॉड्यूल सबसे अच्छा समझौता है - मॉड्यूल लोड होने पर संस्करण की जांच एक बार की जाती है।

@ स्टीवएल-एमएसएफटी मेरा मानना ​​​​है कि यह पावरशेल कमेटी के निष्कर्ष के लिए तैयार है। प्रोटोटाइप #11686।

ऐसा लगता है कि सभी सहमत हैं कि स्क्रिप्ट के लिए संस्करण इंजन में उपयोगी है।
कार्यों के लिए संस्करण सवालों के घेरे में है क्योंकि मॉड्यूल अवधारणा मौजूद है।

सामान्य सीमा यह है कि हम केवल लोड की गई स्क्रिप्ट और फ़ंक्शंस के लिए संस्करण देख सकते हैं और ऐसा नहीं कर सकते हैं जो आयात-मॉड्यूल करता है - आवश्यक संस्करण लोड करता है लेकिन गेट-मॉड्यूल में भी स्पष्ट संस्करण पैरामीटर नहीं होते हैं।

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

मैं उम्मीद कर रहा था कि गेट-कमांड इस जानकारी को इकट्ठा करने का उपकरण होगा, लेकिन शायद इसे स्टैंड-अलोन फंक्शन मैनेजमेंट के लिए पूरी तरह से अलग करने की जरूरत है।

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

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

जैसा कि हम सभी अब जानते हैं, सभी कार्यों को वास्तविक रूप से एक मॉड्यूल के भीतर रखा जाना चाहिए, यहां तक ​​​​कि वे भी जिन्हें आप अपनी प्रोफ़ाइल के हिस्से के रूप में लोड कर रहे हैं (जो आपको इन कार्यों वाले मॉड्यूल को लोड करना चाहिए) या आसान रखरखाव के लिए एक बड़ी स्क्रिप्ट के हिस्से के रूप में उपयोग करना, या यहां तक ​​​​कि वे विलक्षण कार्य जिन्हें आपको xyz स्क्रिप्ट में उपयोग करने की आवश्यकता है।

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

हां इसका मतलब है कि आपके पास एक psd1 और एक psm1 होना चाहिए, लेकिन उचित खोज और रखरखाव के लिए 2 फाइलें वास्तव में प्रबंधित करने के लिए बहुत बड़ी मांग नहीं हैं

जैसा कि आप बता सकते हैं, मैं व्यक्तिगत रूप से इस बदलाव से

हां इसका मतलब है कि आपके पास एक psd1 और एक psm1 होना चाहिए, लेकिन उचित खोज और रखरखाव के लिए 2 फाइलें वास्तव में प्रबंधित करने के लिए बहुत बड़ी मांग नहीं हैं

हाँ, यह एक बहुत बड़ा सवाल है। डेवलपर्स में व्यवस्थापक स्क्रिप्टर बनाने की कोशिश करने से प्रवेश में काफी बाधा उत्पन्न होती है।

यह कहना कि "ओह, आपको इसे यहां कॉपी करना है और वहां कॉपी करना है और फिर इसे आयात करना है" यह कहने की तुलना में कहीं अधिक जटिल और त्रुटि की संभावना है "इसे run.ps1 नाम की फ़ाइल में कॉपी-पेस्ट करें और फिर टाइप करें ,\run .ps1"।

यह एक मामूली बदलाव है और यह आकस्मिक/व्यवस्थापक स्क्रिप्टर्स को टर्नरी ऑपरेटरों या नल-कोलेसिंग (जो मुझे अभी भी समझ में नहीं आता है) या कई अन्य हालिया परिवर्तनों से लाभान्वित करने के लिए खड़ा है जो आप में से उन लोगों के लिए किए गए हैं जो देव हैं। जैसा कि उनके बारे में कहा गया था, मैं फ़ंक्शन संस्करणों के बारे में कह सकता हूं: यदि आपको यह पसंद नहीं है, तो इसका उपयोग न करें।

@ स्टीवएल-एमएसएफटी मुझे विश्वास है कि पावरशेल समिति स्क्रिप्ट और स्टैंडअलोन फ़ंक्शंस के संस्करणों का समर्थन करने के अनुरोध को देख सकती है। प्रोटोटाइप #11686 में है।

यहां ईमानदार सच्चाई यह है कि डॉट सोर्सिंग फ़ंक्शन जाने का सही तरीका नहीं है,

लेकिन लोग इसे करते हैं, और वैसे भी इस अनुरोध के लिए यह एकमात्र उपयोग मामला नहीं है।

और उन सभी वर्षों पहले अनुशंसित नहीं किया जाना चाहिए था जब मॉड्यूल सिस्टम v2 में आया था। उपयोग के लिए दूरस्थ रूप से समझदार होने का एकमात्र समय v1.

जैसा कि हम सभी अब जानते हैं, सभी कार्यों को वास्तविक रूप से एक मॉड्यूल के भीतर रखा जाना चाहिए, यहां तक ​​​​कि वे भी जिन्हें आप अपनी प्रोफ़ाइल के हिस्से के रूप में लोड कर रहे हैं (जो आपको इन कार्यों वाले मॉड्यूल को लोड करना चाहिए) या आसान रखरखाव के लिए एक बड़ी स्क्रिप्ट के हिस्से के रूप में उपयोग करना, या यहां तक ​​​​कि वे विलक्षण कार्य जिन्हें आपको xyz स्क्रिप्ट में उपयोग करने की आवश्यकता है।

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

हां इसका मतलब है कि आपके पास एक psd1 और एक psm1 होना चाहिए, लेकिन उचित खोज और रखरखाव के लिए 2 फाइलें वास्तव में प्रबंधित करने के लिए बहुत बड़ी मांग नहीं हैं

हां, लेकिन यह प्रासंगिक नहीं है। कोई भी यह तर्क नहीं दे रहा है कि हमें मॉड्यूल का संस्करण नहीं बनाना चाहिए। ;-)

जैसा कि आप बता सकते हैं, मैं व्यक्तिगत रूप से इस बदलाव से असहमत हूं और सोचता हूं कि इसके बजाय ध्यान केंद्रित करने के लिए बेहतर चीजें हैं

आपको इसका उपयोग करने की आवश्यकता नहीं होगी। आपको वास्तव में [CmdletBinding ()] या पैरामीटर सेट का उपयोग करने के लिए मजबूर नहीं किया जाता है।
कमांड और cmdlets के संस्करण हैं।
यदि किसी फ़ंक्शन का एक संस्करण है, _चाहे फ़ंक्शन मॉड्यूल_ के भीतर रहता है या नहीं, यह केवल एक मामूली, लेकिन उपयोगी, दस्तावेज़ीकरण बिंदु है। मैंने उनमें विविध और असंबंधित उपकरणों के साथ कई मॉड्यूल बनाए हैं जो अपने स्वयं के व्यक्तिगत मॉड्यूल को सही नहीं ठहराते हैं। यदि मेरा मॉड्यूल MiscStuff 1.1.0002 , तो यह वितरण भाग के लिए बहुत अच्छा है; मैं इसका इस्तेमाल करता हूं। अगर इसके अंदर तीस कार्य हैं और मैं जल्दी से नोट करना चाहता हूं कि क्या मैं Do-Thing 7.9.0 का उपयोग कर रहा हूं और इसे अपने चेंजलॉग में किसी आइटम से सहसंबंधित करने में सक्षम हूं (जो मैं करता हूं!), मुझे इसके लिए कुछ औपचारिक विधि चाहिए ऐसा करना, जो किसी भी तरह से उन लोगों के लिए आवश्यक नहीं होगा जो नहीं चाहते हैं।

@ PowerShell/powershell-committee ने इसकी समीक्षा की, हमारा मानना ​​है कि स्क्रिप्ट फ़ंक्शंस के लिए वर्जनिंग का उचित समाधान उन्हें एक मॉड्यूल में लपेटना है। यह भी स्पष्ट नहीं है कि यदि स्क्रिप्ट फ़ंक्शन मॉड्यूल के भीतर है, तो अपेक्षित व्यवहार क्या होगा, लेकिन इसकी अपनी संस्करण विशेषता है। फिर PowerShell, PowerShellGet, और PSGallery के अन्य भागों के बारे में चिंता है जिन्हें इस नई विशेषता का सम्मान करने के लिए अद्यतन करने की आवश्यकता होगी। यदि इच्छा एक एकल स्क्रिप्ट फ़ाइल बनाम एक फ़ोल्डर (मॉड्यूल) को पारित करने में सक्षम होना है, तो एक ज़िप / nupkg मॉड्यूल को सीधे आयात करने की क्षमता में निवेश करना बेहतर होगा और एक .ps1 को एक मॉड्यूल में बदलना आसान होगा।

एक व्यवस्थापक स्क्रिप्टर के रूप में और एक डेवलपर के रूप में, मुझे नहीं लगता कि #7259 और इस अनुरोध (#11667) का एक-दूसरे से कोई लेना-देना है।

एक व्यवस्थापक स्क्रिप्टर के रूप में मैं मॉड्यूल का उपयोग करना नहीं

व्यवस्थापक स्क्रिप्टर्स के लिए और डेवलपर्स के लिए नहीं - समिति कैसे सुझाव देती है कि फ़ंक्शन/फ़िल्टर के लिए संस्करण तैयार किया जाए?

विरोधाभासी नहीं होना चाहिए, लेकिन... वर्जनिंग अपने आप में एक डेवलपर अवधारणा है, कुल मिलाकर। मुझे यकीन नहीं है कि आप सभी संभावित स्थानों पर इस रेखा को यहां खींचने की कोशिश क्यों कर रहे हैं। मैं

क्योंकि मैंने दर्जनों स्टैंडअलोन फ़ंक्शन और स्क्रिप्ट जारी की हैं। मॉड्यूल के बिना। मुझे पूरा यकीन है कि यह मेरी और कई अन्य लोकप्रिय ब्लॉगर्स/प्रकाशकों की पूर्व टिप्पणियों में शामिल है।

मुझे नहीं लगता कि #7259 और इस अनुरोध (#11667) का एक-दूसरे से कोई लेना-देना है।

हाँ, मुझे वास्तव में ईमानदार होने के लिए कनेक्शन नहीं मिला है।

मैं मॉड्यूल का उपयोग करना नहीं सीखूंगा।

एफडब्ल्यूआईडब्ल्यू आप बस एक्सटेंशन को psm1 बदलें और (वैकल्पिक रूप से) New-ModuleManifest चलाएं। इसमें बहुत कुछ नहीं है।

यह मेरे लिए प्रासंगिक नहीं है। यह मुझे कोई मूल्य नहीं प्रदान करता है।

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

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

समिति कैसे सुझाव देती है कि कार्यों/फ़िल्टरों के लिए संस्करण तैयार किया जाए?

यदि अलग-अलग कार्यों के लिए वर्जनिंग लागू की गई थी, तो क्या आप उनके संस्करण को क्वेरी करने योग्य होने की उम्मीद करेंगे?

यदि हां, तो क्या आप इस बारे में थोड़ा विस्तार से बता सकते हैं कि आप किस परिदृश्य से उपयोगकर्ता से पूछताछ करने की अपेक्षा करेंगे? क्या आप इसे #requires टैग जैसे किसी अन्य सिस्टम में चलाने की उम्मीद करेंगे?

यदि यह केवल स्रोत में दिखाई देने वाला मेटाडेटा होगा तो आप इसे टिप्पणी आधारित सहायता के NOTES अनुभाग में डाल सकते हैं।

पावरशेल समिति के निष्कर्ष के आधार पर मैं इस मुद्दे को बंद करता हूं (ट्रैकिंग बंद करें) लेकिन आप चर्चा जारी रखने के लिए स्वतंत्र हैं।

हां, मैं आज नोट्स अनुभाग और $pVersion/$pName का उपयोग करता हूं। मुझे संदेह है कि हममें से अधिकांश को जरूरत है, ऐसा करें।

जब मैं लिख रहा था "मैं नहीं करूंगा" मैं सामान्य व्यक्ति की बात कर रहा था, विशेष रूप से मेरे बारे में नहीं (हालांकि मैं उस श्रेणी में आता हूं)।

और एक $pVersion/$pName

आप इनके साथ क्या करते हैं? क्या आपके पास प्रकाशित किए गए ढीले फ़ंक्शन का उदाहरण है? यह उपयोग के मामले को समझने में मदद कर सकता है।

जब मैं लिख रहा था "मैं नहीं करूंगा" मैं सामान्य व्यक्ति की बात कर रहा था, विशेष रूप से मेरे बारे में नहीं (हालांकि मैं उस श्रेणी में आता हूं)।

हाँ, निश्चित रूप से ऐसे लोग हैं जो मॉड्यूल के बारे में जानने से इनकार करते हैं। मैं इस तरह के बहुत से लोगों को जानता हूं और वर्तमान में जानता हूं (और कुछ साल पहले लोक कहा गया है), कोई तर्क नहीं है कि वे मौजूद हैं। उस ने कहा, उन लोगों के बीच ओवरलैप, और जो 1. संस्करण की परवाह करते हैं और 2. अपने काम को प्रकाशित करने की कोई इच्छा है - मेरे अनुभव में लगभग शून्य है। वास्तविक रूप से अधिकांश लोग जो बॉक्स 1 और 2 को चेक करते हैं, उन्हें प्रकाशित करने से पहले Google को ~ 10 मिनट का समय लगेगा कि कैसे एक मॉड्यूल में वास्तविक रूप से रैप किया जाए। या अधिक बार, वे वर्जनिंग की परवाह नहीं करते हैं और वे इसे केवल एक सार या ब्लॉग पोस्ट में स्लैम करेंगे।

और एक $pVersion/$pName

आप इनके साथ क्या करते हैं? क्या आपके पास प्रकाशित किए गए ढीले फ़ंक्शन का उदाहरण है? यह उपयोग के मामले को समझने में मदद कर सकता है।

जब मैं लिख रहा था "मैं नहीं करूंगा" मैं सामान्य व्यक्ति की बात कर रहा था, विशेष रूप से मेरे बारे में नहीं (हालांकि मैं उस श्रेणी में आता हूं)।

हाँ, निश्चित रूप से ऐसे लोग हैं जो मॉड्यूल के बारे में जानने से इनकार करते हैं। मैं इस तरह के बहुत से लोगों को जानता हूं और वर्तमान में जानता हूं (और कुछ साल पहले लोक कहा गया है), कोई तर्क नहीं है कि वे मौजूद हैं। उस ने कहा, उन लोगों के बीच ओवरलैप, और जो 1. वर्जनिंग की परवाह करते हैं और 2. अपने काम को प्रकाशित करने की कोई इच्छा है - मेरे अनुभव में _लगभग_ शून्य है। वास्तविक रूप से अधिकांश लोग जो बॉक्स 1 और 2 को चेक करते हैं, उन्हें प्रकाशित करने से पहले Google को ~ 10 मिनट का समय लगेगा कि कैसे एक मॉड्यूल में वास्तविक रूप से रैप किया जाए। या अधिक बार, वे वर्जनिंग की परवाह नहीं करते हैं और वे इसे केवल एक सार या ब्लॉग पोस्ट में स्लैम करेंगे।

मैं मॉड्यूल का उपयोग करना जानता हूं। मैं उन्हें हर समय लिखता हूं। हेक, ये फ़ंक्शन बहुत समय मॉड्यूल के अंदर होते हैं, और मैं आंतरिक वर्जनिंग का उपयोग करता हूं ताकि मैं किसी बाहरी (फ़ंक्शन में) चेंजलॉग को खींचने के बिना किसी फ़ंक्शन में अंतिम परिवर्तन का ट्रैक रख सकूं। मुझे नहीं लगता कि फ़ंक्शन में .VERSION मॉड्यूल संस्करण में हस्तक्षेप क्यों करेगा। मैं बस नहीं।

मैं मॉड्यूल का उपयोग करना जानता हूं। मैं उन्हें हर समय लिखता हूं। हेक, ये फ़ंक्शन _inside_ _modules_ बहुत समय हैं, और मैं आंतरिक संस्करण का उपयोग करता हूं ताकि मैं किसी बाहरी (फ़ंक्शन में) चेंजलॉग को खींचने के बिना किसी फ़ंक्शन में अंतिम परिवर्तन का ट्रैक रख सकूं। मुझे नहीं लगता कि फ़ंक्शन में .VERSION मॉड्यूल संस्करण में हस्तक्षेप क्यों करेगा। मैं बस नहीं।

ठीक है, लेकिन मुख्य बात यह है: आप उस मेटाडेटा के साथ क्या करने जा रहे हैं? क्या यह कुछ ऐसा है जिसे आप फ़ंक्शन के स्रोत में देखते हैं? यदि हां, तो क्या आप विस्तार से बता सकते हैं कि कैसे .NOTES अनुभाग उसके लिए उपयुक्त नहीं है?

इसके अलावा यह मुद्दा एक स्टैंडअलोन फ़ंक्शन को Get-Command आउटपुट में इसकी संस्करण संख्या घोषित करने की अनुमति देने के लिए था। एक पूर्ण परिवर्तन लॉग शामिल करने का अनुरोध एक बहुत अलग कार्यान्वयन होगा और शायद अपने स्वयं के मुद्दे में बेहतर होगा।

इसका उत्तर देना आसान है। इसका मतलब है कि मुझे इसे एक संपादक में खोलना होगा या किसी कंप्यूटर पर दिए गए कंप्यूटर/दिए गए स्थान पर स्थापित संस्करण का पता लगाने के लिए किसी प्रकार की अजीब स्ट्रिंग खोज करनी होगी। यह उत्तर हमेशा आसान नहीं होता है। :-)

ज़रूरी नहीं?

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

function test {
    <#
    .NOTES
    Version: 1.5.0
    #>
    [CmdletBinding()]
    param()
}

Get-Help test -Full

# or
Get-Help test | % alertSet

परिणाम:

PS> Get-Help test -Full
SYNTAX
    test [<CommonParameters>]


DESCRIPTION


PARAMETERS
    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer, PipelineVariable, and OutVariable. For more information, see
        about_CommonParameters (https://go.microsoft.com/fwlink/?LinkID=113216).

INPUTS

OUTPUTS

NOTES


        Version: 1.5.1


RELATED LINKS

PS> get-help test | % alertset



    Version: 1.5.1

इसलिए? मैं प्रभावित नहीं हूं। टर्नरी ऑपरेटरों को भी करने के अन्य, अधिक वर्बोज़ तरीके थे। और फिर भी... एक अधिक कॉम्पैक्ट तरीका लागू किया गया। क्योंकि (एक हिस्सा) समुदाय इसे चाहता था। मैं अभी भी नहीं जानता कि हेक नल-कोलेसिंग ऑपरेटर क्या हैं।

वास्तव में सुनिश्चित नहीं है कि आप क्या कर रहे हैं। यह काफी स्पष्ट रूप से आपको वह करने देता है जो आप अपेक्षाकृत आसानी से कर रहे हैं। मुझे नहीं लगता कि वहां अतिरिक्त फ़ील्ड जोड़ने के लिए यह समय के लायक है।

यदि आप ऐसा करते हैं, तो बेझिझक एक पीआर खोलें और हम इसके बारे में आगे बात करेंगे। मैं

पीआर किस लिए? मैं सी # कोडर नहीं हूं। मैं 30 से अधिक वर्षों से पेशेवर डेवलपर नहीं रहा हूं।

मुझे लगता है कि हम में से कई वास्तव में स्पष्ट थे कि हम क्या चाहते हैं, और हमारे उपयोग के मामले, और उन चिंताओं को कम से कम देखा, जैसा आपने अभी-अभी किया था।

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

लेकिन यह व्यर्थ है और मैं बेहतर जानता था। पावरशेल समिति के निष्कर्ष पर पहले ही पहुंच गया था। क्षमा करें मैंने टिप्पणी की।

पावरशेल समिति के निष्कर्ष पर पहले ही पहुंच गया था।

फीडबैक के आधार पर किसी भी उप-डिजाइन निष्कर्ष पर पुनर्विचार किया जा सकता है।

मुझे लगता है कि हम में से कई वास्तव में स्पष्ट थे कि हम क्या चाहते हैं, और हमारे उपयोग के मामले, और उन चिंताओं को कम से कम देखा, जैसा आपने अभी-अभी किया था।

मैं वास्तविक लक्ष्य और उपयोग के मामलों की तह तक जाने के लिए वास्तव में कठिन प्रयास कर रहा हूं और मेरे सवालों को ज्यादातर नजरअंदाज कर दिया गया है। मैं वास्तव में समझना चाहूंगा।

आप में से जो एडमिन स्क्रिप्टिंग से परे हैं

यार, मैं एक सिसडमिन हूँ। मेरा अधिकांश करियर हैशटेबल सिंटैक्स "स्प्लैटिंग सिंटैक्स" सोचने में बिताया गया था। मेरे अधिकांश सहकर्मी केवल पावरशेल (यदि बिल्कुल भी) की पूर्ण मूल बातें जानते हैं, तो अधिकांश लोगों के साथ मैं कलह/रेडिट में मदद करता हूं।

मुझे लगता है कि आपके पास पीएस देव टीम के साथ कुछ गोमांस है, लेकिन कृपया ऐसा दिखावा न करें जैसे मैं संभवतः आपके दृष्टिकोण को नहीं समझ सकता क्योंकि मुझे अब सी # पता है। मैं इस रेपो पर उस परिप्रेक्ष्य के लिए लगातार लड़ रहा हूं।

सोचें "बस इसे एक मॉड्यूल बनाएं"। अधिकांश व्यवस्थापक स्क्रिप्टर्स को यह नहीं पता होगा कि वे कैसे और कैसे कहेंगे (और मैं सहमत हूं) कि आवश्यकताओं को देखने के बाद यह बहुत अधिक परेशानी है।

जो कोई भी बाद में इस धागे में आता है और मॉड्यूल बनाने से निराश हो जाता है, यहां आवश्यकताएं हैं:

1. अपनी .ps1 फ़ाइल का नाम बदलकर .psm1
2. Import-Module ./file.psm1 बजाय . ./file.ps1

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

1. अपनी .ps1 फ़ाइल का नाम बदलकर .psm1
2. New-ModuleManifest -RootModule ./file.psm1 -Path ./file.psd1 -ModuleVersion 1.0.0 चलाएँ
3. Import-Module ./file.psd1 बजाय . ./file.ps1

यदि आप एक ps1 में एक ढीला फ़ंक्शन भेज रहे हैं जिसे उपभोक्ता (या स्वयं) को स्रोत को डॉट करने की आवश्यकता होगी, तो बस इसे एक मॉड्यूल में फेंक दें वास्तविक रूप से यह आपके जीवन को आसान बना देगा।

यदि आप सीधे इनवोकेबल स्क्रिप्ट की शिपिंग कर रहे हैं, तो आप New-ScriptFileInfo उपयोग कर सकते हैं जो इस तरह की टिप्पणी के साथ एक स्क्रिप्ट फ़ाइल उत्पन्न करेगा:

<#PSScriptInfo

.VERSION 1.0.0

.GUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

.AUTHOR username

.COMPANYNAME

.COPYRIGHT

.TAGS

.LICENSEURI

.PROJECTURI

.ICONURI

.EXTERNALMODULEDEPENDENCIES 

.REQUIREDSCRIPTS

.EXTERNALSCRIPTDEPENDENCIES

.RELEASENOTES


.PRIVATEDATA

#>

<# 
.DESCRIPTION 
     Quick script description here.
#> 
param()

और आप क्वेरी कर सकते हैं कि Test-ScriptFileInfo ।