यह ठीक से 5.1 में काम करता है, लेकिन 6 में नहीं है, इसलिए मैंने इस मुद्दे को बग के रूप में पुनर्वर्गीकृत किया है।

कारण यह है कि वर्तमान कोड WriteInformation (नेत्रहीन?) कहता है।

TestConnectionCommand.cs की लाइन 751 देखें, लाइन 775 और लाइन 783 भी।

होस्ट को प्रदर्शित होने से जानकारी को रोकने के लिए अस्थायी वर्कअराउंड का उपयोग InformationAction सामान्य पैरामीटर के लिए किया जाता है। उदाहरण:

Test-Connection www.microsoft.com -Count 1 -Quiet -InformationAction Continue

पटकथा के नजरिए से, यह एक मुद्दा नहीं होगा , क्योंकि पाठकीय जानकारी कभी भी पाइपलाइन को नहीं है , जो कि पाइपलाइन को भेजी गई चीजों के रूप में परिभाषित किया गया है। इसके अलावा, Quiet स्विच को सरल परिणाम देने के लिए परिभाषित किया गया है ( int या bool , रिकॉर्ड वस्तुओं के बजाय)। मुझे स्वीकार करना होगा कि कोई InformationRecord Quiet साथ की उम्मीद नहीं कर सकता है। हालांकि, कारण जानने के बाद, मैं कहता हूं कि हम InformationAction और Quiet डिकॉउल्ड रखेंगे।

PowerShell 5.1 में, Test-Connection को WriteInformation बिलकुल भी नहीं लगता है। वैसे, के लिए डिफ़ॉल्ट मान $InformationPreference PowerShell 5.1 और PowerShell कोर 6.0.2 में है SilentlyContinue । समस्या के लेखक का एक अलग प्रभावी मूल्य हो सकता है जब उसने इस मुद्दे को पुन: पेश किया। (शायद PS 6.1 Core ने $InformationPreference लिए डिफ़ॉल्ट मान बदल दिया है? मुझे यकीन नहीं है।)

यदि PS 6.1 Core के पास $InformationPreference SilentlyContinue $InformationPreference डिफ़ॉल्ट रूप से होता है, तो पाठ्य सूचना तब तक नहीं होगी जब तक उपयोगकर्ता स्पष्ट रूप से इसके लिए नहीं पूछता।

मुझे और प्रतिक्रिया चाहिए।
समस्या यह है कि स्क्रिप्ट मोड में और इंटरैक्टिव मोड में इसे अलग-अलग तरीकों से काम करना चाहिए। इंटरैक्टिव मोड में उपयोगकर्ता संभवतः प्रगति (बार) को देखना पसंद करेंगे क्योंकि यह ping.exe कमांड के साथ होता है। यह अन्य मापदंडों पर भी लागू होता है।

@ mklement0 यदि आपके पास समय है तो आपकी मदद उपयोगी होगी।

@ जीलोव :

अच्छी खोज, लेकिन यह -InformationAction Ignore जो इस मामले में बग के आसपास काम करने के लिए आवश्यक है।

$InformationActionPreference अभी भी SilentlyContinue डिफॉल्ट करता है, और इसे बदलना नहीं चाहिए।

बग यह है कि WriteInformation() कॉल आपको लिंक करने के लिए गलती से PSHOST टैग का उपयोग करते हैं, जो प्रभावी रूप से _bypasses_ $InformationActionPreference मूल्य और -InformationAction SilentlyContinue (लेकिन, जैसा कि कहा गया है) , -InformationAction Ignore _is_ आउटपुट को दबाने में प्रभावी)।

क्या कहा WriteInformation() कॉल प्रभावी रूप से Write-Host _uncondally_ करने के लिए अपने उत्पादन (डिजाइन द्वारा) प्रदर्शित करता है।

@iSazonov : मैंने वास्तव में प्रगति पट्टियों के साथ अन्य cmdlets के व्यवहार को नहीं देखा है, लेकिन -Quiet मैं _not_ को प्रगति बार, जबकि अंतःक्रियात्मक रूप से कॉल करने की उम्मीद है।

@ mklement0 PSHostTag पर उत्तर और सुधार के लिए धन्यवाद। यह मुझे लगता है कि InformationPreference ( InformationAction ) Ignore स्वीकार नहीं करेगा? यह 5.1 और 6.0.2 में सच है। शायद 6.1 में यह बदल गया है। ( InformationActionPreference InformationPreference लिए एक नया उपनाम है?)

इसके अलावा, मेरी पहली टिप्पणी गलत थी, इसके लिए वह InformationAction से Continue । सही वर्कअराउंड स्ट्रीम 6 (सूचना स्ट्रीम) को $null पुनर्निर्देशित करके छोड़ देना है, अर्थात

Test-Connection www.microsoft.com -Count 1 -Quiet 6> $null

निम्नलिखित द्वारा शुद्धता की जाँच करें:

Write-Host 'Hello, world' 6> $null

इसे मेजबान को कुछ नहीं लिखना चाहिए।

@ जीलोव :

यह मुझे लगता है कि InformationPreference (InformationAction) इग्नोर को स्वीकार नहीं करेगा?

हां, _preference variable_ Ignore स्वीकार नहीं करता है, लेकिन _common पैरामीटर_ करता है।

यही है, आप सूचना स्ट्रीम (संख्या 6 ) को दबा सकते हैं _ दिए गए मंगलाचरण के लिए, लेकिन पूरे दायरे के लिए _categorically_ नहीं - डिज़ाइन द्वारा।

इसलिए, निम्नलिखित दो कथन समतुल्य हैं:

Test-Connection www.microsoft.com -Count 1 -Quiet 6> $null
Test-Connection www.microsoft.com -Count 1 -Quiet -InformationAction Ignore

दूसरे शब्दों में: दोनों 6> $null और -InformationAction Ignore प्रभावी वर्कअराउंड हैं।

क्या InformationActionPreference InformationPreference लिए एक नया उपनाम है?

जी नहीं, नाम हमेशा किया गया है $InformationPreference , के पैटर्न निम्नलिखित $VerbosePreference , $WarningPreference , और $DebugPreference ।

मैं जो बता सकता हूं वह केवल -ErrorAction / $ErrorActionPreference जोड़ी है, जहां वरीयता चर नाम Action भाग को बनाए रखता है।

निषेध के संबंध में Ignore कार्रवाई के मूल्य के रूप में

• इस प्रतिबंध के साथ एक मौलिक डिजाइन समस्या है, क्योंकि स्वचालित रूप से परिभाषित स्थानीय वरीयता चर उन्नत कार्यों के अंदर आम-पैरामीटर मानों का प्रचार करने के लिए उपयोग किए जाते हैं - # 1759 देखें

• प्रतिबंध को _assignment time_ पर लागू नहीं किया गया है, जिसका अर्थ है कि आप समस्या को तब तक नहीं देखेंगे जब तक कि वरीयता अगली बार लागू न हो जाए - # 4348 देखें

  • अधिक आम तौर पर, किसी भी दायरे में लेकिन वैश्विक एक, कोई भी सत्यापन नहीं किया जाता है; $ErrorActionPreference = 'bogus' से & { $ErrorActionPreference = 'bogus' } - देखें की तुलना करें
    

    3483।

@ mklement0 मैं उपनाम के बारे में पूछ रहा था क्योंकि आपने इसे InformationActionPreference रूप में उल्लेख किया था।

मेरे सर्वश्रेष्ठ ज्ञान के लिए, -XxxAction (और -Verbose और -Debug ) बस इनवॉइस किए गए cmdlet के अंदर संबंधित वरीयता चर सेट करता है। जैसा कि about_ सहायता विषयों में प्रलेखित है, विशेष रूप से हमारे पास निम्नलिखित हैं:

The value of the -InformationAction parameter, if used, overrides the current value of the $InformationPreference variable.

Within the command or script in which it is used, the InformationAction common parameter overrides the value of the $InformationPreference preference variable, which by default is set to SilentlyContinue.

मैं इसे स्थानीय वरीयता चर के रूप में व्याख्या करता हूं, जैसा कि निम्नलिखित प्रदर्शन द्वारा मान्य किया जा सकता है:

function test-func { [cmdletbinding()]param() process { $InformationPreference } }
test-func # gives SilentlyContinue
test-func -InformationAction Continue # gives Continue
test-func -InformationAction Ignore # gives Ignore

5.1 और 6.0.2 में, InformationAction Ignore स्वीकार नहीं करता है, जैसा कि निम्नलिखित स्निपेट द्वारा प्रदर्शित किया जा सकता है:

function test-func { [cmdletbinding()]param() process { write-information 'writing' } }
test-func -InformationAction Ignore

का उत्पादन

Write-Information : The value Ignore is not supported for an ActionPreference variable. The provided value should be used only as a value for a preference
parameter, and has been replaced by the default value. For more information, see the Help topic, "about_Preference_Variables."
At line:1 char:57
+ ...  { [cmdletbinding()]param() process { Write-Information 'writing' } }
+                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Information], NotSupportedException
    + FullyQualifiedErrorId : System.NotSupportedException,Microsoft.PowerShell.Commands.WriteInformationCommand

मुझे आश्चर्य है कि अगर 6.1 में बदल गया।

एक और दिलचस्प बात है: $VerbosePreference और $DebugPreference वास्तव में एक व्यापक श्रेणी को स्वीकार करते हैं जो कि समान सामान्य पैरामीटर द्वारा निर्धारित किया जा सकता है। उदाहरण के लिए, स्पष्ट असाइनमेंट द्वारा $VerbosePreference से Inquire करना संभव है, लेकिन -Verbose स्विच का उपयोग करके संभव नहीं है क्योंकि, आखिरकार, यह एक स्विच है और $True मैप करता है $False से Continue / SilentlyContinue ।

जहाँ तक मुझे पता है, उन दो स्विचों को छोड़कर, प्राथमिकता-संबंधित सामान्य पैरामीटर स्थानीय क्षेत्र में संबंधित वरीयता चर के बिल्कुल नक्शे पर हैं।

चारों ओर खेलने का एक और दौर निम्नलिखित कोड काम दिखाता है:

Write-Information 'writing' -InformationAction Ignore

लेकिन यह डेवलपर्स के लिए बोझिल होगा, क्योंकि हमें Write-Information का चेक $InformationAction -eq 'Ignore' रखना है, और इसे पहले स्थान पर कॉल करने से बचें, जैसे,

Function Test-Inf1
{
    [CmdletBinding()] Param ( )
    Process { Write-Information 'Hello, world!' }
}
Function Test-Inf2
{
    [CmdletBinding()] Param ( )
    Process { If ($InformationPreference -ne 'Ignore') { Write-Information 'Hello, world!' } }
}
Test-Inf1 -InformationAction Ignore # writes an error
Test-Inf2 -InformationAction Ignore # okay

ऐसा लगता है कि C # के साथ cmdlets लिखने वाले लेखकों पर भी यही बात लागू होती है।

@GeeLaw

मैं उपनाम के बारे में पूछ रहा था क्योंकि आपने इसे InformationActionPreference के रूप में उल्लेख किया था।

ऊप्स! क्षमा करें - अपने टाइपो पर ध्यान नहीं दिया था।

बस इनवॉइस किए गए cmdlet के अंदर संबंधित वरीयता चर सेट करता है।

हां, और बाकी जो आप प्रदर्शित करते हैं, वह पूर्वोक्त # 1759 का विषय है।

संक्षेप में: डिजाइन दोष यह है कि सामान्य-पैरामीटर मानों को प्रचारित करने के लिए स्थानीय वरीयता-चर उदाहरणों को स्वचालित रूप से सेट करने के साथ प्राथमिकता-परिवर्तनीय मान के टकराव के रूप में Ignore को रोकना।

अधिक विशेष रूप से:

5.1 और 6.0.2 में, InformationAction इग्नोर को स्वीकार नहीं करता है, जैसा कि निम्नलिखित स्निपेट द्वारा प्रदर्शित किया जा सकता है:

चूँकि यह समस्या को हल करने के संबंध में मायने रखता है, -InformationAction मुझे यह बताना चाहिए कि Ignore स्वीकार करते हैं, और यह केवल डिजाइन दोष है जो समस्या का कारण बनता है _if और जब वरीयता को संदर्भ में लागू किया जाता है। _advanced फ़ंक्शन_, जो आपके मामले में Write-Information कॉल _inside_ फ़ंक्शन है।
यह समस्या PowerShell Core v6.1.0-preview.2 के रूप में बनी रहती है।

_Compiled cmdlets_, इसके विपरीत, यह समस्या नहीं है, यही वजह है कि Write-Host foo -InformationAction Ignore काम करता है, उदाहरण के लिए, जैसा कि आपने खोजा है।

संक्षेप में, हम यहां दो असंबंधित समस्याओं पर चर्चा कर रहे हैं:

• एक्शन-प्रिफरेंस वैरिएबल वैल्यू के रूप में Ignore संबंध में डिजाइन दोष, जिसे पहले से ही # 1759 में ट्रैक किया जा रहा है।

• इस मुद्दे का मूल विषय, Test-Connection cmdlet का दुरुपयोग, जो गलती से PSHOST टैग का उपयोग अपनी कॉल में .WriteInformation ।

उत्तरार्द्ध का समाधान केवल _omit_ टैग को है, जैसा कि निम्न उदाहरण प्रदर्शित करता है:

# With $InformationAction at its default, 'SilentlyContinue', this invocation is silent.
# If you set it to 'Continue', 'foo' prints.
& { [CmdletBinding()]param() $PSCmdlet.WriteInformation('foo', [string[]] @()) } 

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

मैंने पिछले वर्ष (# 2537) में कोड में टेस्ट-कनेक्शन जोड़ने के लिए एक पीआर जमा किया था और उस समय इसे अस्वीकार कर दिया गया था क्योंकि "@ PowerShell / powershell-Committee इस पीआर को स्वीकार नहीं करेगी क्योंकि यह भविष्य में अनुकूलता की समस्याओं को पेश करेगा", इसलिए मैं अब इस cmdlet को शामिल करने के लिए आश्चर्यचकित था, लेकिन मूल पीआर के कोड के साथ नहीं, बल्कि बिल्कुल नया कोड जो सभी अपेक्षित कार्यक्षमता प्रदान नहीं करता है।

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

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

अगर हमारे पास 5.1 और 6.x में टेस्ट-कनेक्शन हैं, तो मैं उनसे एक ही आउटपुट की उम्मीद करूंगा। मुझे पता है कि कार्यान्वयन अलग है, लेकिन उपयोगकर्ताओं को इसकी परवाह नहीं करनी चाहिए। 6.1 में वर्तमान टेस्ट-कनेक्शन अलग-अलग व्यवहार करता है जो हमें 5.1 में अलग आउटपुट देता है। इसके अलावा, -Quiet पैरामीटर व्यावहारिक रूप से बेकार है।

ऐसा लगता है कि यह समस्या अभी भी खड़ी है, जैसे कि अभी (PSVersion = 6.2.0) cmdlet "पिंग" जानकारी को प्रदर्शित करना जारी रखता है, भले ही QUIET मौजूद हो ("-इन्फोर्मेशन इग्नोर को जोड़ते हुए" ट्रिक करता है लेकिन इसका उपयोग मॉड्यूल या स्क्रिप्ट का उपयोग करता है) टेस्ट-कनेक्शन cmdlet को अपडेट करना होगा, ठंडा नहीं)

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

cc @ स्टीवएल- MSFT @iSazonov

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

यह देखते हुए कि कोई भी अन्य cmdlet ऐसे पैरामीटर का उपयोग नहीं करता है, मुझे नहीं लगता कि इस तरह के द्वंद्व का कोई मतलब है। एक cmdlet को यह कार्य करना चाहिए और लगातार व्यवहार करना चाहिए; इंटरएक्टिव व्यवहार को अलग नहीं किया जाना चाहिए कि यह कैसे व्यवहार करता है।

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

मुझे लगता है कि यह अनावश्यक जटिलता है।

हम डिफ़ॉल्ट रूप से इंटरैक्टिव आउटपुट कर सकते हैं और स्क्रिप्ट में आउटपुट को दबाने के लिए Quiet पैरामीटर बढ़ा सकते हैं।

फिर से ... मुझे स्क्रिप्ट्स में इंटरेक्टिव बनाम एक अलग आउटपुट की आवश्यकता नहीं दिखती है।

यदि cmdlet केवल अन्य cmdlets की तरह व्यवहार करता है और पाठ डेटा स्ट्रीम को कैप्चर या पार्स करने के लिए अपने सभी डेटा को पूरी तरह से अद्वितीय और आउटपुट करने के बजाय अनुपयोगी डेटा को आउटपुट करता है (यह _PowerShell_ है, बैश नहीं), तो व्यवहार में बदलाव की बिल्कुल आवश्यकता नहीं है ।

-क्वाइट एक स्विच है जिसका उपयोग विंडोज पावरशेल में मूल cmdlet द्वारा किया जाता है ताकि आउटपुट ऑब्जेक्ट्स के बजाय शुद्ध ट्रू / गलत प्रतिक्रिया दी जा सके। मेरी राय में, सम्मेलन को तोड़ना एक बुरा विचार है।

इस cmdlet को मौजूदा cmdlets के अनुरूप व्यवहार करना चाहिए। यह वर्तमान व्यवहार का अकेले उपयोग करने का कोई कारण नहीं है। अपने वर्तमान पुनरावृत्ति में यह अधिक व्यवहार करता है क्योंकि एक यूनिक्स उपयोगिता को संचालित करने की अपेक्षा करेगा, अन्य पॉवरशेल cmdlets संचालित करने के लिए बहुत अलग।

फिर से ... मुझे स्क्रिप्ट्स में इंटरेक्टिव बनाम एक अलग आउटपुट की आवश्यकता नहीं दिखती है।

क्या आप सभी समर्थित परिदृश्यों में वांछित आउटपुट प्रदर्शित कर सकते हैं? ध्यान दें कि मेटाडेटा आउटपुट के लिए मेटा जानकारी बहुत महत्वपूर्ण है।

टेक्स्ट स्ट्रीम को कैप्चर या पार्स करने के लिए अपने सभी डेटा को आउटपुट करना मुश्किल है

Cmdlet मजबूत टाइप्ड ऑब्जेक्ट आउटपुट करता है। (समस्या यह है कि इन वस्तुओं को बनाना और एक साथ प्रदर्शित करना असंभव है क्योंकि "मेटा" जानकारी है।)

-क्वाइट एक स्विच है जिसका उपयोग विंडोज पावरशेल में मूल cmdlet द्वारा किया जाता है ताकि आउटपुट ऑब्जेक्ट्स के बजाय शुद्ध ट्रू / गलत प्रतिक्रिया दी जा सके। मेरी राय में, सम्मेलन को तोड़ना एक बुरा विचार है।

वह Windows PowerShell cmdlet केवल पिंग का समर्थन करता है जिसके लिए कनेक्शन की अवधारणा मौजूद नहीं है। यह शुरू में विवादास्पद डिजाइन था। उनके लिए सही नाम Test-Ping ot Test-ICMP ।
वर्तमान cmdlet आईपी "कनेक्शन" का समर्थन करता है। हालांकि मैं "टेस्ट-कनेक्टिविटी" जैसा कुछ पसंद करूंगा।

अपने वर्तमान पुनरावृत्ति में यह अधिक व्यवहार करता है क्योंकि एक यूनिक्स उपयोगिता को संचालित करने की अपेक्षा करेगा, अन्य पॉवरशेल cmdlets संचालित करने के लिए बहुत अलग।

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

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

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

@iSazonov मैं परीक्षण के बाद पहली बार पढ़ने के बाद आपसे सहमत नहीं था, मैं आपकी बात समझता हूं

$a=Test-Connection www.microsoft.com 
$b=Test-Connection www.microsoft.com -Quiet

$ A और $ b मान वे हैं जिनकी मुझे उम्मीद है कि BUT मुझे अतिरिक्त आउटपुट नहीं चाहिए।

चयन-स्ट्रिंग में एक शांत पैरामीटर भी है और इसका "इंटरैक्टिव" व्यवहार से कोई लेना-देना नहीं है

मैं सहमत हूं कि इस कमांड को व्यवहार को बदलने के लिए एक अतिरिक्त पैरामीटर की आवश्यकता है (शांत या नहीं)।

मैं डिफ़ॉल्ट रूप से पैरामीटर 'इंटरएक्टिव' को पसंद करता हूं, लेकिन हो सकता है कि इंटरएक्टिव उपयोग पर प्राथमिकता देने के लिए एक स्विच पैरामीटर "NoInteractive" बेहतर समायोजन हो।

ठीक है, यहाँ मैं एक और अधिक उपयोगी कार्यान्वयन होने पर विचार करूंगा।

सामान्य अंक

1. सभी वर्तमान होस्ट / सूचना आउटपुट को -Verbose स्ट्रीम में पुनः प्राप्त किया जाता है। वर्तमान में इसका उपयोग _at all_ नहीं किया गया है, और यह इसके लिए एक सही उपयोग का मामला है।
2. -ShowProgress स्विच के साथ निर्दिष्ट किए जाने तक कोई प्रगति पट्टी नहीं।
3. -Ping स्विच निकालें (यह डिफ़ॉल्ट व्यवहार है)।

प्राथमिक उत्पादन

Test-Connection www.google.com

• आउटपुट ऑब्जेक्ट के Replies प्रॉपर्टी से जानकारी को मुख्य आउटपुट ऑब्जेक्ट में शामिल किया जाना चाहिए, और प्राथमिक आउटपुट मोड _multiple_ ऑब्जेक्ट होना चाहिए, प्रत्येक एकल पिंग प्रयास / उत्तर ऑब्जेक्ट का प्रतिनिधित्व करता है।
• बफ़र _data_ आमतौर पर अप्रासंगिक है, क्योंकि इसे निर्दिष्ट नहीं किया जा सकता है, और केवल BufferSize संपत्ति का खुलासा होना चाहिए। Replies.Buffer संपत्ति private रहनी चाहिए।
• Replies.Options संपत्ति को डिफ़ॉल्ट स्वरूपण से छिपाया जाना चाहिए।
• परिणाम तालिका के रूप में आउटपुट, गंतव्य पते द्वारा वर्गीकृत (इस मामले में कि कई गंतव्य निर्दिष्ट हैं)।

आउटपुट विजुअल मॉकअप

उपयोग की गई कमांड:

$Result = Test-Connection www.google.com
$Data = foreach ($Reply in $Result.Replies) {
    [PSCustomObject]@{
        Source = $Result.Source
        Destination = $Result.Destination
        Address = $Reply.Address
        RoundtripTime = $Reply.RoundtripTime
        BufferSize = $Reply.Buffer.Length
        Options = $Reply.Options
    }
}
$Data | Format-Table -GroupBy Destination -Property Source, Address, RoundtripTime, BufferSize

परिणामी उत्पादन:

   Destination: www.google.com
Source  Address       RoundtripTime BufferSize
------  -------       ------------- ----------
WS-JOEL 172.217.2.132            36         32
WS-JOEL 172.217.2.132            21         32
WS-JOEL 172.217.2.132            25         32
WS-JOEL 172.217.2.132            25         32

Test-Connection www.google.com -TraceRoute

• प्रत्येक हॉप को एक अलग ऑब्जेक्ट के रूप में आउटपुट किया जाना चाहिए, प्रत्येक में PingReply ऑब्जेक्ट्स को एक संपत्ति के रूप में स्वरूपण से छिपाकर सुलभ होना चाहिए।
• मुख्य TraceRouteResult ऑब्जेक्ट में ईटीएस या वर्ग गुण शामिल होने चाहिए जो उनके चार पिंगरप्लेज़ से सारांश डेटा की गणना करते हैं।
• नोट: यह ऑब्जेक्ट प्रकार हम प्रयोग कर रहे वर्तमान में bugged है, और सभी PingReply वस्तुओं की रिपोर्ट TtlExpired उनकी स्थिति के रूप में। .NET कोर 3 के लिए फिक्स की प्रगति की जांच करने या समस्या को हल करने के लिए TraceRoute बैकिंग के लिए कस्टम समाधान डिज़ाइन करने की अनुशंसा करें।
• एक तालिका के रूप में आउटपुट, DestinationHost द्वारा समूहीकृत (यह संपत्ति मानक पिंग के लिए उपयोग की गई अन्य ऑब्जेक्ट प्रकार से भिन्न क्यों है?)

आउटपुट विजुअल मॉकअप

उपयोग की गई कमांड:

$Result = Test-Connection www.google.com -TraceRoute
$Data = foreach ($Reply in $a.Replies) {
    [PSCustomObject]@{
        Hop = $Reply.Hop
        Source = $a.Source
        Destination = $a.DestinationHost
        DestinationAddress = $a.DestinationAddress
        Replies = $Reply.PingReplies
        RoundtripTimes = $Reply.PingReplies.RoundtripTime
        HopAddress = $Reply.PingReplies[0].Address
        BufferSize = $Reply.PingReplies.ForEach{$_.Buffer.Length}
        Options = $Reply.PingReplies[0].Options
    }
}

$Data | Format-Table -GroupBy Destination -Property Hop, RoundtripTimes, DestinationAddress, HopAddress, BufferSize

परिणामी उत्पादन:

   Destination: www.google.com
Hop RoundtripTimes DestinationAddress HopAddress     BufferSize
--- -------------- ------------------ ----------     ----------
  1 {0, 0, 0}      172.217.2.132      192.168.22.254
  2 {0, 0, 0}      172.217.2.132      75.144.219.238
  3 {0, 0, 0}      172.217.2.132      96.120.37.17
  4 {0, 0, 0}      172.217.2.132      96.110.136.65
  5 {0, 0, 0}      172.217.2.132      69.139.180.170
  6 {0, 0, 0}      172.217.2.132      68.85.127.121
  7 {0, 0, 0}      172.217.2.132      68.86.165.161
  8 {0, 0, 0}      172.217.2.132      68.86.90.205
  9 {0, 0, 0}      172.217.2.132      68.86.82.154
 10 {0, 0, 0}      172.217.2.132      66.208.233.242
 11 {0, 0, 0}      172.217.2.132      0.0.0.0
 12 {0, 0, 0}      172.217.2.132      216.239.59.124
 13 {0, 0, 0}      172.217.2.132      216.239.59.61
 14 {32, 28, 20}   172.217.2.132      172.217.2.132

मुझे विश्वास है कि यदि हम उपयोगकर्ता के लिए डेटा प्रस्तुत कर रहे हैं, तो यह प्रोग्रामेटिक फैशन में आसानी से सुलभ हो

ओह, @ vexx32 मैं देख रहा हूं कि आपने कभी नेटवर्क का निदान नहीं किया है। आपका प्रस्ताव मेरे द्वारा पहले चरण में लागू किया गया था और फिर एक इंटरैक्टिव सत्र में उपयोग के लिए उपयुक्त नहीं होने के कारण खारिज कर दिया गया था। उदाहरण के लिए, हम Test-Connection www.google.com -TraceRoute कमांड चलाने के बाद बहुत लंबे समय तक एक रिक्त स्क्रीन पर देख सकते हैं। इसलिए हर प्रतिक्रिया के लिए एक आउटपुट (स्ट्रिंग या प्रगति पट्टी) दिखाने के लिए कार्यान्वयन को बदल दिया गया था।

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

ऊपर मेरी सुगमता इंटरएक्टिव और लिपि सुंदर को विभाजित करने के लिए Interactive स्विच शुरू करना था। आप Verbose स्विच के साथ भी ऐसा करने का सुझाव देते हैं जो और भी अधिक अप्राकृतिक अभ्यास है।

जब तक -SProProgress स्विच के साथ निर्दिष्ट नहीं किया जाता है, तब तक कोई प्रगति पट्टी नहीं।

स्ट्रिंग आउटपुट और प्रगति पट्टी वर्तमान कार्यान्वयन में दो विकल्पों के रूप में है। हमें केवल एक की जरूरत है। Windows PowerShell cmdlet में प्रगति पट्टी का उपयोग किया जाता है। मेरी प्राथमिकता इंटरएक्टिव सत्र में स्ट्रिंग आउटपुट है। यह बहुत अधिक सुविधाजनक है।
और हम एक स्विच के साथ प्रगति पट्टी को कभी नहीं दबाते हैं। स्क्रिप्ट परिदृश्यों के लिए हमारे पास $ ProgressPreference है। कुछ cmdlets टाइमर द्वारा केवल लंबे संचालन के लिए एक प्रगति बार दिखाते हैं।

-पिंग स्विच निकालें (यह डिफ़ॉल्ट व्यवहार है)।

सबसे अच्छा अभ्यास लिपियों में स्पष्ट मापदंडों का उपयोग करना है। यह कोड को अधिक पठनीय बनाता है। यह Windows PowerShell cmdlet में आवश्यक नहीं था जहाँ केवल पिंग लागू किया गया था। नया cmdlet अधिक कार्यक्षमताओं को लागू करता है और हमें प्रत्येक के लिए नए स्पष्ट पैरामीटर की आवश्यकता होती है।

आपका प्रस्ताव मेरे द्वारा पहले चरण में लागू किया गया था और फिर एक इंटरैक्टिव सत्र में उपयोग के लिए उपयुक्त नहीं होने के कारण खारिज कर दिया गया था। उदाहरण के लिए, हम कमांड टेस्ट-कनेक्शन www.google.com -TraceRoute चलाने के बाद बहुत लंबे समय तक एक खाली स्क्रीन पर देख सकते हैं। इसलिए हर प्रतिक्रिया के लिए एक आउटपुट (स्ट्रिंग या प्रगति पट्टी) दिखाने के लिए कार्यान्वयन को बदल दिया गया था।

प्रगति प्रदर्शन विभाजन वस्तु प्रारूप के साथ आवश्यक नहीं है, क्योंकि हम काफी आसानी से प्रगति देख सकते हैं क्योंकि प्रत्येक वस्तु आउटपुट के लिए प्रस्तुत की जाती है। यहाँ केवल इसकी आवश्यकता है क्योंकि हम पाइपलाइन में डेटा का उत्पादन नहीं करते हैं क्योंकि इसे पुनः प्राप्त किया जाता है जैसे कि हर दूसरे PowerShell cmdlet करता है। अगर हम हर PingReply या -TraceRoute हम _ha__ के लिए ट्रेस हॉप को आउटपुट डिस्प्ले में निर्मित करते हैं।

ऊपर मेरा सुझाव इंटरएक्टिव स्विच को इंटरएक्टिव और स्क्रिप्ट के बंटवारे से परिचित कराना था। आप सुझाव देते हैं कि वर्बोस स्विच के साथ भी ऐसा करें जो और भी अधिक अप्राकृतिक अभ्यास है।

-Verbose एक सामान्य पैरामीटर है और इस प्रकार पूरी तरह से नए स्विच की तुलना में cmdlet के लिए कहीं अधिक प्राकृतिक विकल्प है। हमें यहां पहिए को फिर से लगाने की जरूरत नहीं है।

सबसे अच्छा अभ्यास लिपियों में स्पष्ट मापदंडों का उपयोग करना है। यह कोड को अधिक पठनीय बनाता है। यह Windows PowerShell cmdlet में आवश्यक नहीं था जहाँ केवल पिंग लागू किया गया था। नया cmdlet अधिक कार्यक्षमताओं को लागू करता है और हमें प्रत्येक के लिए नए स्पष्ट पैरामीटर की आवश्यकता होती है।

मैं इस पर न तो यहां हूं और न ही, लेकिन आमतौर पर एक cmdlet के डिफ़ॉल्ट व्यवहार में स्विच नहीं है। उदाहरण के लिए, हम एक नहीं है -Loud के पीछे के रूप में स्विच -Quiet ।

प्रगति प्रदर्शन विभाजन वस्तु प्रारूप के साथ आवश्यक नहीं है, क्योंकि हम काफी आसानी से प्रगति देख सकते हैं क्योंकि प्रत्येक वस्तु आउटपुट के लिए प्रस्तुत की जाती है।

आपके प्रस्ताव के ऊपर हम "मेटा" ऑब्जेक्ट में "पिंग" ऑब्जेक्ट एकत्र करते हैं और वास्तविक समय में "पिंग" ऑब्जेक्ट को आउटपुट करना असंभव है - हम पाइपलाइन में केवल "मेटा" ऑब्जेक्ट को आउटपुट कर सकते हैं - उपयोगकर्ता को सभी समय में रिक्त प्रदर्शन दिखाई देगा।

-Verbose एक सामान्य पैरामीटर है और इस तरह पूरी तरह से नए स्विच की तुलना में cmdlet के लिए कहीं अधिक प्राकृतिक विकल्प है।

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

आमतौर पर एक cmdlet के डिफ़ॉल्ट व्यवहार में स्विच नहीं होता है।

यह एकल पैरामीटर सेट के लिए सही है। अब हमारे पास कई पैरामीटर सेट हैं और हमें प्रत्येक को स्पष्ट रूप से नामित करने की आवश्यकता है।

आपके प्रस्ताव के ऊपर हम "मेटा" ऑब्जेक्ट में "पिंग" ऑब्जेक्ट एकत्र करते हैं और वास्तविक समय में "पिंग" ऑब्जेक्ट को आउटपुट करना असंभव है - हम पाइपलाइन में केवल "मेटा" ऑब्जेक्ट को आउटपुट कर सकते हैं - उपयोगकर्ता को सभी समय में रिक्त प्रदर्शन दिखाई देगा।

मेटा ऑब्जेक्ट अनावश्यक है। जैसा कि उपरोक्त प्रस्ताव में उल्लेख किया गया है, वस्तुओं का निर्माण और आउटपुट _each_ PingReply या ट्रेस हॉप के लिए किया जाएगा। नकली अप अंतिम कोड, केवल एक प्रारूप नकल करने विचार वर्णन करने के लिए आसान नहीं है। तालिका में प्रत्येक प्रविष्टि एक-एक करके आउटपुट होगी। कृपया पूरा प्रस्ताव पढ़ें।

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

मुझे _any_ cmdlet के बारे में भी जानकारी नहीं है जो नियमित रूप से सूचना / होस्ट के लिए "महत्वपूर्ण" जानकारी का उत्पादन कर रहा है और आउटपुट को छोड़कर किसी अन्य वस्तु में गहरे स्तर को छोड़ कर उत्पादन नहीं कर रहा है।

यह एकल पैरामीटर सेट के लिए सही है। अब हमारे पास कई पैरामीटर सेट हैं और हमें प्रत्येक को स्पष्ट रूप से नामित करने की आवश्यकता है।

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

मेटा ऑब्जेक्ट अनावश्यक है।

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

मुझे लगता है कि यह समय की बर्बादी है

स्थितीय मापदंडों का उपयोग करने से आपको :-)

PowerShell समिति के लिए संक्षिप्त सारांश।

वर्तमान cmdlet डिजाइन किया गया था

• सभी समर्थित प्लेटफार्मों के लिए पोर्टेबल cmdlet प्राप्त करने के लिए। वास्तव में हमारे पास अभी भी कुछ मुद्दे हैं। नेट कोर तो सभी सुविधाएँ यूनिक्स प्लानफॉर्म पर काम नहीं करती हैं
• लोकप्रिय उपकरण जैसे पिंग, ट्रेसरूट, पाथिंग, पोर्टक्री। exe और आदि की सुविधाएँ प्राप्त करना
• सरल और गहन नेटवर्क अभिगम्यता विश्लेषण दोनों के लिए उपयुक्त __scripts__ में उपयोगी आउटपुट ऑब्जेक्ट प्राप्त करने के लिए
• _header_ और _footer_ के साथ उपयोगी कंसोल आउटपुट प्राप्त करने के लिए। ध्यान दें कि cmdlet कुछ परिदृश्यों में और भी उपयोगी जानकारी प्रदर्शित करता है जो कि मूल प्रोटो यूटीलिटी की तुलना में अधिक उपयोगी है।
• दूरस्थ परीक्षण "टेस्ट-कनेक्शन-स्रोत ... -Destination ..." जैसे भविष्य की अनुमति देने के लिए

मुख्य समस्या यह है कि इंटरैक्टिव कंसोल आउटपुट (इंटरेक्टिव परिदृश्य) और पाइपलाइन में ऑब्जेक्ट्स के आउटपुट (स्क्रिप्ट परिदृश्य) को कैसे संयोजित किया जाए। मेरा वर्तमान सुझाव एक पैरामीटर (-Interactive) के साथ या नए cmdlet (इंटरएक्टिव परिदृश्य के लिए शो-कनेक्टिविटी और स्क्रिप्ट परिदृश्य के लिए परीक्षण-कनेक्टिविटी) के साथ एक विभाजन करना है।
इसके अलावा, मैं cmdlet का नाम बदलकर Test -__ Connectivity__ करने का सुझाव दूंगा, जो अधिक सटीक है। यह पुराने विंडोज cmdlet को बिना नाम के संघर्ष के साथ समीपता (WCM) के माध्यम से उपयोग करने की अनुमति देगा।

@iSazonov आप ऐसे निदान का एक उदाहरण प्रदान कर सकते हैं जिसके लिए एक मेटा ऑब्जेक्ट होना आवश्यक है जो सभी डेटा को छुपाता है? मेरा प्रस्ताव यह है कि मेटा ऑब्जेक्ट से प्रत्येक पिंगरपेली ऑब्जेक्ट में जानकारी को स्थानांतरित किया जाए; मैं यह नहीं देखता कि कैसे cmdlet की उपयोगिता कम होगी।

यदि आप निर्माण के तुरंत बाद वस्तु का उत्पादन करते हैं, तो आप पाद लेख से पहली "पिंग" ऑब्जेक्ट पर आंकड़े कैसे डालते हैं?

क्या पाद जानकारी? एक पिंग से एकमात्र पाद लेख जानकारी Ping complete.

वर्तमान मेटा ऑब्जेक्ट्स में कोई आंकड़े नहीं हैं जो मैं कहीं भी देख सकता हूं; वे सिर्फ एक ही जानकारी के साथ सभी वस्तुओं को सम्‍मिलित करते हैं, जो सूचना प्रवाह पर स्ट्रिंग डेटा के रूप में प्रदान की जा रही हैं, बस कम प्रयोग करने योग्य प्रारूप में।

यहाँ बिंदु cmdlets रखना है (इस मामले में टेस्ट-कनेक्शन) दोनों संस्करणों (WinPS और Pwsh) पर उसी तरह cmdlet में एक स्विच जोड़ रहा है, इस मामले में 'निष्क्रिय' करने के लिए कि आउटपुट गलत होगा जैसे मैंने कहा था इससे पहले कि इसका मतलब होगा इस cmdlet का उपयोग करने वाले प्रत्येक स्क्रिप्ट / मॉड्यूल को अपडेट करना होगा, समाधान दोनों संस्करणों पर उसी तरह बना रहा है

@ NJ-Dude विंडोज cmdlet WMI पर आधारित है और इसे पिछड़ी संगतता के साथ पोर्ट करना असंभव है। इसके अलावा 5.1 जमे हुए था - भविष्य में कोई अतिरिक्त नहीं होगा।

@ NJ-Dude विंडोज cmdlet WMI पर आधारित है और इसे पिछड़ी संगतता के साथ पोर्ट करना असंभव है। इसके अलावा 5.1 जमे हुए था - भविष्य में कोई अतिरिक्त नहीं होगा।

मैं समझता हूं और जानता हूं कि, मैं सिर्फ इतना कह रहा हूं कि SYNTAX और कार्यक्षमता समान होनी चाहिए, मतलब, यदि QUIET का उपयोग किसी भी आउटपुट को प्रदर्शित नहीं करता है, तो यह PS के स्वाद की परवाह किए बिना किसी भी आउटपुट को प्रदर्शित नहीं करना चाहिए।

मैं सिर्फ इतना कह रहा हूं कि SYNTAX और कार्यक्षमता समान होनी चाहिए

यह असंभव है। Windows संगतता मॉड्यूल पुरानी कार्यक्षमता प्राप्त करने का एकल तरीका है।

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

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

और जैसा कि उल्लेख किया गया है, आपके द्वारा उल्लेख किए गए पाद लेख में कोई डेटा नहीं है जो विशेष रूप से पाद लेख में होना चाहिए; यह शुरुआत से ही उपलब्ध है या प्रत्येक प्रतिक्रिया पर कार्रवाई की जाती है।

एक समिति चर्चा के लिए इसे तैयार करना

Soooo मैंने थ्रेड का ट्रैक थोड़ा खो दिया है, जिससे खरपतवारों में परेशानी हो रही है, लेकिन कार्यान्वयन के संबंध में मेरा मूल लेना यह है:

• डेटा आउटपुट लाइन-बाय-लाइन होना चाहिए। मुझे लगता है कि Test-Connection s और ping.exe et al दोनों के साथ यही वर्तमान मामला है
• डेटा को एक संरचित वस्तु के रूप में लौटाया जाना चाहिए। स्वरूपण इस तथ्य का अज्ञेय होना चाहिए। (जैसा कि यह भयानक है, मैंने एक फॉर्मैटर देखा है जो इस तथ्य के बावजूद कि यह हुड के तहत एक PSObject है कंसोल के लिए एक JSON स्ट्रिंग का उत्सर्जन करता है। मेरी बात बस यह है कि यह किया जा सकता है।) स्वरूपण भी एक जगह है जहाँ हम बिना बदलावों के हम जो चाहें बदलना चाहते हैं। (साथ ही @ vexx32 से दृढ़ता से सहमत हैं कि हमें कॉलम हेडर के बारे में सावधान रहना चाहिए जो संपत्ति के नामों से मेल नहीं खाते। यह कभी-कभी पठनीयता के लिए आवश्यक है, लेकिन यह मुझे पागल भी करता है।)
• -Quiet को केवल Windows PowerShell की तरह, बूलियन के रूप में True / False के अलावा कुछ भी नहीं छोड़ना चाहिए।
• यदि अधिक जानकारी है तो हमें डिफ़ॉल्ट मामले की तुलना में (जो न्यूनतम बूलियन -Quiet केस से अधिक होना चाहिए), -Verbose उचित लगता है, लेकिन मैंने इसके बारे में पर्याप्त नहीं सोचा है। (यह वह जगह भी है जहां मैं धागा खो देता हूं, यह बताना मुश्किल है कि ऊपर और अधिक लोग क्या चाहते हैं)।
• Windows PowerShell के समान सभी गुणों के साथ सटीक समान ऑब्जेक्ट ( cimv2\Win32_PingStatus ) का अनुकरण करना असंभव है (क्योंकि .NET कोर, WMI, आदि), लेकिन हमें इसे यथासंभव बंद करने का प्रयास करना चाहिए।
• मैं प्रगति के बारे में नहीं जानता। मेरा उच्च-स्तर का कदम यह है कि प्रगति अभी भी हर किसी को पागल करती है क्योंकि यह धीमा है (हमारी आशाओं के बावजूद), लेकिन यह भी कि यह गैर-संवादात्मक में इतना अधिक मायने नहीं रखता है क्योंकि हर कोई $ProgressPreference वैसे भी सेट कर रहा है।

मुझे अच्छा लगता है!

प्रगति मुख्य रूप से मुझे बाहर निकाल देती है क्योंकि इसे कमांड कॉल में नियंत्रित नहीं किया जा सकता है; आपको $ ProgressPreference सेट करना होगा। मैं वास्तव में चाहता हूं कि एक सामान्य पैरामीटर था .... लेकिन मेरे पास इस बारे में एक और मुद्दा है, इसलिए हम यहां नहीं जाना चाहिए! :मुस्कुराओ:

@ पावरशेल / पावरशेल-समिति ने इसकी समीक्षा की। हम इस बात पर सहमत हुए कि Test-Connection को व्यवहार में अनुकरण करना चाहिए जैसा कि विंडोज पॉवरशेल 5.1 में निकटता से संभव था ( -Quiet )। इसका मतलब यह है कि प्रत्येक उत्तर के लिए डिफ़ॉल्ट प्रारूप में गुण और कोई भी अतिरिक्त उपलब्ध होने वाले प्रत्येक उत्तर के लिए PingStatus आउटपुट ऑब्जेक्ट ( win32_ ) को उत्सर्जित किया जाना चाहिए। प्रगति का उपयोग नहीं किया जाना चाहिए।

क्या कोई लघु RFC लेखक करने के लिए तैयार होगा जो समीक्षा के लिए प्रस्तावित आउटपुट प्रारूप के साथ cmdlet सिंटैक्स दिखाता है?

@ stevel-msft मुझे खुशी होगी। :)

मुझे उस की आवाज़ बहुत पसंद है।
धन्यवाद

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

इसे संक्षिप्त रूप से देखें तो ऐसा लगता है कि यह अनिवार्य रूप से विंडोज-कमांड का अनुकरण करने की कोशिश करने के लिए यूनिक्स प्लेटफार्मों पर एक अलग से लागू कमांड के साथ टेस्ट-कनेक्शन को बदल दिया गया है? क्या मैं यह सही पढ़ रहा हूं?

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

मैं RFC के मसौदे का एक लिंक छोड़ दूंगा जब मैंने इसे लिखा और टिप्पणी करने, समायोजन करने आदि के लिए स्वतंत्र महसूस किया ... मुझे इस पर कुछ और दृष्टिकोण सुनने में अच्छा लगेगा। 🙂

EDIT: https://github.com/PowerShell/PowerShell-RFC/pull/172

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

हम इसे कब देखेंगे? 6.2.2 में? कब होगी संभावना जमीन?
(अप्रैल 2018 से लेकर अब तक _-शांत_ शोर मचा हुआ इस धागे को देखने के लिए मज़ेदार था। ऐसा लगता है कि इस तरह के एक नो-ब्रेनर ब्रेकिंग परिवर्तन)।

मुझे लगता है कि मुझे लगता है कि मैं आसानी से RFC पर इंतजार कर रहा हूं, इस कोड को बहुत आसानी से लिखा जा सकता है। जैसे ही ऐसा होता है मैं इसे पूरा कर लूंगा और इसके लिए एक पीआर सबमिट करूंगा। :मुस्कुराओ:

ओह मुझे लगा कि स्थिति यह है कि इसे मंजूरी दी गई (यह नहीं जानते कि वास्तव में क्या राज्य हैं या पूरी प्रक्रिया क्या है)। लेकिन अपडेट के लिए धन्यवाद। अभी भी एक दया है कि इसे शांत करने के लिए 12 महीने से अधिक समय लगा है :)

इसे शांत करने के लिए 12 महीने से अधिक

मुझे और प्रतिक्रिया की उम्मीद थी

@ vexx32 आप इसे कोड करना शुरू कर सकते हैं और प्रायोगिक झंडे के पीछे रख सकते हैं यदि कोई प्रतिक्रिया आती है जो वर्तमान प्रस्ताव को बदल देती है

@ स्टीवएल-एमएसएफटी मैं पहले से ही ज्यादातर काम कर रहा है। मैं जल्द ही एक पीआर w / कुछ प्रायोगिक झंडे प्रस्तुत करना चाहूंगा ताकि हम कोड के बारे में और अधिक संक्षेप में बात कर सकें। 💖

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

क्या आप थोड़ा और विस्तृत कर सकते हैं कि आप यह कैसे सोचते हैं कि @isazonov काम कर सकता है?

@ vexx32 क्या आप कार्यान्वयन या UX डिजाइन के बारे में पूछते हैं?

मुख्य रूप से आपको लगता है कि यूएक्स उसके लिए कैसा होगा, मुझे लगता है। :)

इंटरैक्टिव सत्र में सबसे अच्छा यूएक्स है
1. न्यूनतम टाइपिंग
इसका मतलब:
- पिंग डिफ़ॉल्ट है
- एक पैरामीटर के साथ दूसरे मोड (ट्रेसरूट और आदि) पर स्विच करना
2. उपयोगकर्ता के अनुकूल उत्पादन
इसका मतलब:
- अनुकरण ping.exe (tracert.exe और अन्य) आउटपुट _on कंसोल होस्ट_ जैसे मैंने डेमो कोड में कोशिश की - हेडर, फुटर और सूचनात्मक लाइनों के साथ अच्छी तरह से स्वरूपित। आउटपुट प्रकारों के बारे में सोचने की आवश्यकता नहीं है - उनका उपयोग नहीं किया जाता है, केवल प्रदर्शित किया जाता है।
- स्क्रिप्ट मोड पर स्विच करने के लिए पैरामीटर जोड़ें - जो कंसोल होस्ट पर उपयोगकर्ता के अनुकूल पाठ के आउटपुट को दबाने और मजबूत टाइप की गई वस्तुओं को बाहर निकालने के लिए है। इस आउटपुट को प्रारूपित करने की आवश्यकता नहीं है। हमने क्विट पर चर्चा की, जो सच / गलत रिटर्न देता है, लेकिन हमें अन्य कच्चे मजबूत टाइप की गई वस्तुओं (जैसे -ROOutput) का उत्सर्जन करने के लिए एक पैरामीटर (एस) की आवश्यकता होती है। यूएक्स को स्क्रिप्ट में अतिरिक्त मापदंडों का उपयोग करना स्वीकार्य है।

धन्यवाद, मुझे लगता है कि मुझे समझ में आ गया है कि अब आपको थोड़ा बेहतर क्या मिल रहा है।

मैं वास्तव में इस तरह एक दोहरी मोड की जरूरत नहीं दिख रहा है, हालांकि? PowerShell के किसी भी अन्य cmdlets में यह इंटरैक्टिव और "स्क्रिप्ट मोड" मापदंडों के बीच विभाजित नहीं है।

यदि आप पिंग / ट्रैसर्ट का सटीक आउटपुट चाहते हैं, तो आप सीधे उन उपयोगिताओं का उपयोग क्यों नहीं करेंगे?

पावरशेल ने किसी मौजूदा कमांड की पूरी तरह से नकल करने का महत्वपूर्ण प्रयास नहीं किया है; मुझे लगता है कि Get-ChildItem शायद निकटतम है, लेकिन ऐसा करने वाला लगभग एकमात्र है।

यदि हम आपके कहे अनुसार पिंग / ट्रैसर्ट डिस्प्ले का पूरी तरह से अनुकरण करना चाहते हैं, तो मैं आपको सुझाव दूंगा कि हमारे पास एक अलग cmdlet या फ़ंक्शन के रूप में, उदाहरण के लिए, Show-Connection , अतिरिक्त मापदंडों के साथ अव्यवहार शो-कमांड के बजाय जो कोई मौजूदा नहीं है PowerShell के भीतर मिसाल या आवश्यकता।

मैं वास्तव में इस तरह एक दोहरी मोड की जरूरत नहीं दिख रहा है, हालांकि? PowerShell के किसी भी अन्य cmdlets में यह इंटरैक्टिव और "स्क्रिप्ट मोड" मापदंडों के बीच विभाजित नहीं है।

हमारे पास प्रारूपण प्रणाली में अंतराल हैं। उदाहरण के लिए, हमारे पास हेडर / फूटर डायर रखने के अनुरोध के साथ एक समस्या है। ऐसे अन्य परिदृश्य हैं जहां यह सुविधाजनक होगा।

यदि आप पिंग / ट्रैसर्ट का सटीक आउटपुट चाहते हैं, तो आप सीधे उन उपयोगिताओं का उपयोग क्यों नहीं करेंगे?

मैं करता हूँ :-)। ये मूल उपयोगिताओं बहुत शक्तिशाली हैं क्योंकि वे निम्न स्तर के हैं लेकिन वे जमे हुए हैं। हम _smarter_ की तुलना में चीजें कर सकते हैं - यह इस cmdlet की उपस्थिति का सार है (और सिर्फ एक पिंग बनाने के लिए नहीं) - यदि आप इस बात पर गहराई से ध्यान देते हैं कि cmdlet में पते और नाम अब कैसे बने हैं और वे कैसे आउटपुट हैं, आप देखेंगे कि देशी पिंग की तुलना में बहुत अधिक उपयोगी हैं। यह ट्रिक्स जैसा दिखता है लेकिन यह वास्तव में बहुत उपयोगी है।

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

हाँ, आपने इसके साथ कुछ बेहतरीन काम किया है! मैं बहुत सराहना करता हूं। आउटपुट का वर्तमान मोड कुछ भी _but_ इंटरैक्टिव उपयोग के लिए उपयोगी नहीं है। हम बस आउटपुट स्टेप को हटा सकते हैं और इसे Show-Connection कॉल कर सकते हैं और फिर RFC में Test-Connection लिए अधिक PowerShell-केंद्रित समाधान में जो आपने लिखा है उसका उपयोग कर सकते हैं।

@ vexx32 मैंने अभी-अभी आपके PR की कोशिश की है और यह इसे काफी हद तक सुधारता है, लेकिन मैंने देखा कि Windows PowerShell में, यह पाइपलाइन में अलग-अलग PingReply का उत्सर्जन करता है, इसलिए आपको ऐसा कुछ मिलता है जो दिखता है:

PS C:\Users\slee> Test-Connection localhost

Source        Destination     IPV4Address      IPV6Address                              Bytes    Time(ms)
------        -----------     -----------      -----------                              -----    --------
SLEE-DESKTOP  localhost       127.0.0.1        ::1                                      32       0
SLEE-DESKTOP  localhost       127.0.0.1        ::1                                      32       0
SLEE-DESKTOP  localhost       127.0.0.1        ::1                                      32       0
SLEE-DESKTOP  localhost       127.0.0.1        ::1                                      32       0

हालाँकि, आपके परिवर्तन के साथ, सभी पिंग उत्तर एक ही वस्तु के सदस्य हैं:

PS> Test-Connection localhost

Source       Destination Replies
------       ----------- -------
slee-desktop localhost   {System.Net.NetworkInformation.PingReply, System.Net.NetworkInformation.PingReply, System.Net.NetworkInformation.PingReply, System.Net.N…

क्या हम Windows PowerShell व्यवहार को वापस नहीं ले पा रहे हैं?

@ स्टीवएल-एमएसएफटी वह वस्तु उत्पादन पीएस कोर में प्रारंभिक कार्यान्वयन से नहीं बदला गया है; सफलता के आउटपुट में हमेशा एक ही वस्तु होती है। 🙂

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

@ स्टीवएल-एमएसएफटी इस साहसिक कार्य में अगले अध्याय के लिए # 10697 देखें! 😊

: टाडा: इस मुद्दे को # 10478 में संबोधित किया गया था, जिसे अब v7.0.0-preview.5 रूप में सफलतापूर्वक जारी किया गया है।

काम लिंक:

• रिलीज नोट्स

रिलीज में 7.0.0 टेस्ट-कनेक्शन -अभी भी देता है
परीक्षण-कनेक्शन: कंप्यूटर 'स्क्रब' के लिए परीक्षण कनेक्शन विफल रहा: लक्ष्य नाम को हल नहीं कर सकता।
के बजाय
असत्य

@chvol क्या आप इसके लिए एक नया मुद्दा खोल सकते हैं जितना संभव हो उतना विस्तार से?

धन्यवाद! 🙂