يعمل هذا بشكل صحيح في الإصدار 5.1 ولكن ليس في الإصدار 6 ، لذا أعدت تصنيف المشكلة على أنها خطأ.

السبب هو أن الكود الحالي يستدعي WriteInformation (عمياء؟).

انظر السطر 751 من TestConnectionCommand.cs ، وكذلك السطر 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 Core 6.0.2 هي SilentlyContinue . قد يكون لمؤلف المشكلة قيمة فعالة مختلفة عندما أعاد إنتاج المشكلة. (ربما غيّر PS 6.1 Core القيمة الافتراضية لـ $InformationPreference ؟ لست متأكدًا.)

إذا كان PS 6.1 Core يحتوي على $InformationPreference افتراضيًا إلى SilentlyContinue ، فلن تكون المعلومات النصية موجودة إلا إذا طلب المستخدم ذلك صراحة.

أنا بحاجة إلى مزيد من الملاحظات.
المشكلة هي أنه في وضع البرنامج النصي وفي الوضع التفاعلي يجب أن يعمل بطرق مختلفة. في الوضع التفاعلي ، من المحتمل أن يفضل المستخدم رؤية التقدم (الشريط) كما يحدث مع الأمر ping.exe. هذا ينطبق على المعلمات الأخرى أيضا.

@ mklement0 إذا كان لديك وقت ، فستكون مساعدتك مفيدة.

GeeLaw :

اكتشاف جيد ، ولكن المطلوب في هذه الحالة هو -InformationAction Ignore للتغلب على الخطأ.

لا يزال $InformationActionPreference افتراضيًا هو SilentlyContinue ، ولا ينبغي أن يتغير ذلك.

الخطأ هو أن مكالمات WriteInformation() التي تتصل بها تستخدم عن طريق الخطأ علامة PSHOST ، والتي تتخطى فعليًا قيمة $InformationActionPreference وأيضًا -InformationAction SilentlyContinue (ولكن ، كما هو مذكور) ، -InformationAction Ignore _ فعال في كبت الناتج).

ما قيل عن مكالمات WriteInformation() تفعله فعليًا هو ما تفعله Write-Host لعرض مخرجاتها (حسب التصميم).

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

يجب أن يكتب أي شيء للمضيف.

GeeLaw :

يبدو لي أن InformationPreference (InformationAction) لن يقبل التجاهل؟

نعم ، لا يقبل المتغير _preference_ 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_ ، مما يعني أنك لن ترى المشكلة حتى يتم تطبيق التفضيل (ربما ضمنيًا) في المرة القادمة - راجع # 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

يبدو أن الأمر نفسه ينطبق على المؤلفين الذين يكتبون أوامر cmdlets باستخدام C #.

تضمين التغريدة

كنت أسأل عن الاسم المستعار لأنك ذكرته على أنه InformationActionPreference.

وجه الفتاة! آسف - لم ألاحظ الخطأ المطبعي الخاص بي.

يقوم ببساطة بتعيين متغير التفضيل المقابل داخل الأمر cmdlet الذي تم استدعاؤه.

نعم ، وبقية ما توضحه هو موضوع رقم 1759 سالف الذكر.

باختصار: عيب التصميم هو أن عدم السماح Ignore باعتباره قيمة متغيرة التفضيل يتعارض مع استخدام مثيلات متغير التفضيل المحلية المحددة تلقائيًا من أجل نشر قيم المعلمات المشتركة.

اكثر تحديدا:

في الإصدارين 5.1 و 6.0.2 ، لا تقبل InformationAction "التجاهل" ، كما يتضح من المقتطف التالي:

نظرًا لأنه مهم فيما يتعلق بحل المشكلة ، اسمحوا لي أن أشير إلى أن -InformationAction _ يفعل_ يقبل Ignore ، ويقال فقط إن عيب التصميم هو الذي يسبب المشكلة _إذا وعندما تم تطبيق التفضيل_ في السياق من وظائف _advanced_ ، وهي في حالتك Write-Information استدعاء _ داخل_ الوظيفة.
استمرت هذه المشكلة اعتبارًا من معاينة PowerShell Core v6.1.0.

على النقيض من ذلك ، لا توجد هذه المشكلة في _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[]] @()) } 

لذلك صادفت هذا لأنني أواجه نفس المشكلة حيث لا يتم احترام الهدوء. نظرت إلى الكود وكان من الصعب متابعته ومعقدًا جدًا لما يفعله ، لكنني لم أر أي مكان يبحث عن هذا في الواقع على أنه مسألة قمع الإخراج ، ولا أرى من أين يتحول إخراج سلسلة إلى منطقية ، وهو ما يجب إخراجه عند تمرير المعلمة -Quiet.

لقد قدمت PR في العام الماضي (# 2537) لإضافة Test-Connection إلى الكود وتم رفض ذلك في ذلك الوقت لأن "@ PowerShell /owershell-Committee لن تقبل هذه العلاقات العامة لأنها ستدخل مشاكل التوافق في المستقبل" ، لذلك فوجئت برؤية تضمين أمر cmdlet هذا الآن ولكن ليس مع رمز PR الأصلي ولكن بدلاً من ذلك رمز العلامة التجارية الجديدة التي لا توفر جميع الوظائف المتوقعة.

أكبر مشكلة واجهتها هي في البرامج النصية الخاصة بي ، أقوم بإجراء عمليات تحقق مثل هذه ، "إذا (Test-Connection 8.8.8.8 -Quiet)" للتفرع إلى المنطق الخاص بي ، ولكن مع عدم احترام المعلمة -Quiet ، يقوم الفرع دائمًا بإرجاع True لأنه لا يوجد خطأ أو لاغ. لذا فإن هذا يجعل الأمر لا يزال غير قابل للاستخدام تمامًا بالنسبة لي ، وأيضًا نظرًا لأنه تم تضمينه في الإصدارات الجديدة من PowerShell ، فإن هذا يجعل الترقية أمرًا شديد الحساسية بالنسبة لي. من فضلك ، أصلح هذا لأنه يبدو أنه قد مرت عدة أشهر منذ الإبلاغ عن المشكلة لأول مرة. لا يهم ذلك ، أو إعادة تعيين العلاقات العامة الأصلية ، طالما تم إرجاع الوظيفة.

لقد قمت بتقديم PR في العام الماضي لإضافة Test-Connection إلى الكود وتم رفض ذلك في ذلك الوقت لأنهم لم يرغبوا في إضافة أوامر cmdlets القديمة ، لذلك فوجئت برؤية تضمين أمر cmdlet هذا الآن ولكن ليس مع الكود من العلاقات العامة الأصلية التي كانت كاملة وعملت تمامًا كما فعلت النسخة "القديمة".

إذا كان لدينا اختبار اتصال في 5.1 و 6.x ، أتوقع أن يكون لهما نفس الإخراج. أعلم أن التنفيذ مختلف ، لكن لا يجب على المستخدمين الاهتمام بذلك. يتصرف اختبار الاتصال الحالي في 6.1 بشكل مختلف مما يمنحنا مخرجات مختلفة عن 5.1. بالإضافة إلى ذلك ، المعلمة -Quiet غير مجدية عمليا.

يبدو أن هذه المشكلة لا تزال قائمة ، اعتبارًا من الآن (PSVersion = 6.2.0) يستمر الأمر cmdlet في عرض معلومات "ping" حتى إذا كان QUIET موجودًا (تؤدي إضافة "-InformationAction Ignore" إلى الحيلة ولكنها تعني الوحدات / البرامج النصية التي تستخدم يجب تحديث أمر cmdlet الخاص باختبار الاتصال ، وليس رائعًا)

سيكون من الرائع حقًا إذا تمكنا من إصلاح هذا الإصدار 7.0. أنا أكثر من سعيد للمساهمة في الكود ، لكننا نحتاج إلى مواصفات تنفيذ لاتباعها حيث لم يكن هناك اتفاق يذكر على المحاولات السابقة لتحسين ذلك.

cc @ SteveL- MSFTiSazonov

أعود إلى هذا من وقت لآخر. الآن أعتقد أنه يمكننا حل هذا باستخدام سيناريوهات فصل تفاعلية وغير تفاعلية صريحة مع مفتاح -Intercative . باستخدام المعلمة يمكننا تنفيذ مخرجات وحدة تحكم غنية وسهلة الاستخدام. يبدو أنه ليس من غير الملائم أن يكتب المستخدم هذه المعلمة (مثل "-i"). بدون المفتاح ، سنقوم بعمل إخراج مكتوب قوي بدون إخراج وحدة التحكم اللفظية وهو أمر جيد لسيناريوهات البرنامج النصي.

بالنظر إلى أنه لا يوجد أمر cmdlet آخر يستخدم مثل هذه المعلمة ، لا أعتقد أنه من المنطقي وجود مثل هذه الازدواجية. يجب أن يقوم cmdlet بمهمته ويتصرف باستمرار ؛ لا ينبغي فصل السلوك التفاعلي عن سلوكه بطريقة أخرى.

على سبيل المثال ، انظر إلى Get-ChildItem. بشكل تفاعلي ، إنه مفيد جدًا بفضل عرض المنسق الافتراضي. ليست هناك حاجة إلى أي تغييرات لجعلها مفيدة أيضًا لأغراض الأتمتة ؛ الأمر نفسه الذي يعمل بشكل تفاعلي يعمل أيضًا في البرنامج النصي.

أشعر أن هذا تعقيد غير ضروري.

يمكننا القيام بالإخراج التفاعلي افتراضيًا وتحسين المعامل Quiet لمنع الإخراج في البرامج النصية.

مرة أخرى ... لا أرى ضرورة لوجود مخرجات مختلفة بشكل تفاعلي مقابل البرامج النصية.

إذا كان الأمر cmdlet يتصرف ببساطة مثل أوامر cmdlets الأخرى ويخرج بيانات غير قابلة للاستخدام بدلاً من أن يكون فريدًا تمامًا ويخرج جميع بياناته في دفق نصي يصعب التقاطه أو تحليله (هذا _PowerShell_ ، وليس Bash) ، فلا داعي مطلقًا لتغيير السلوك .

-Quiet هو مفتاح يستخدمه الأمر cmdlet الأصلي في Windows PowerShell لإعطاء استجابة True / False خالصة ، بدلاً من إخراج الكائنات. خرق هذا التقليد هو فكرة سيئة ، في رأيي.

يجب أن يتصرف هذا الأمر cmdlet بطريقة متوافقة مع أوامر cmdlets الموجودة. لا يوجد سبب لجعله وحده يستخدم السلوك الحالي. في التكرار الحالي ، يتصرف أكثر كما يتوقع المرء أن تعمل أداة Unix المساعدة ، وهي مختلفة تمامًا عن كيفية عمل أوامر أوامر PowerShell cmdlets الأخرى.

مرة أخرى ... لا أرى ضرورة لوجود مخرجات مختلفة بشكل تفاعلي مقابل البرامج النصية.

هل يمكنك عرض المخرجات المطلوبة في جميع السيناريوهات المدعومة؟ لاحظ أن المعلومات الوصفية أن مخرجات cmdlet مهمة جدًا.

إخراج جميع بياناته في مسار نصي يصعب التقاطه أو تحليله

يقوم الأمر cmdlet بإخراج كائن مكتوب قوي. (تكمن المشكلة في أنه من المستحيل إنشاء هذه الكائنات وعرضها في وقت واحد بسبب وجود معلومات "تعريفية".)

-Quiet هو مفتاح يستخدمه الأمر cmdlet الأصلي في Windows PowerShell لإعطاء استجابة True / False خالصة ، بدلاً من إخراج الكائنات. خرق هذا التقليد هو فكرة سيئة ، في رأيي.

لا يدعم الأمر cmdlet لـ Windows PowerShell سوى الأمر ping الذي لا يوجد له مفهوم الاتصال. كان هذا التصميم مثيرًا للجدل في البداية. الاسم الصحيح لهم سيكون Test-Ping ot Test-ICMP .
يدعم cmdlet الحالي "اتصالات" IP. على الرغم من أنني أفضل شيئًا مثل "اختبار الاتصال".

في التكرار الحالي ، يتصرف أكثر كما يتوقع المرء أن تعمل أداة Unix المساعدة ، وهي مختلفة تمامًا عن كيفية عمل أوامر أوامر PowerShell cmdlets الأخرى.

لا ، يقوم الأمر cmdlet بإخراج كائن مكتوب قوي. وتم صنع إخراج وحدة التحكم ليبدو مثل الأدوات المساعدة. لكن في الوقت نفسه ، قد ترى أنه في الواقع أكثر ثراءً وفائدة.
تكمن المشكلة في أنه لا يمكن الحصول على هذا الإخراج باستخدام إمكانيات نظام التنسيق الفرعي وأنه من الضروري إجراء إخراج مباشر إلى وحدة التحكم. (لاحظ أن هذا لا يختلط مع كائنات الإخراج في دفق الإخراج)

يمكن الحصول على المخرجات باستخدام نظام التنسيق ، إذا قمنا ببناء كائنات البيانات بطريقة أكثر قوة. لقد قدمت PR مع نموذج أولي بالفعل. يعد الأمر cmdlet الذي يعرض البيانات في نموذج لا يعكس بيانات الكائن الأساسية بشكل صحيح (على سبيل المثال ، عن طريق عرض البيانات من الخصائص الفرعية بدلاً من هيكلة فئة الكائن بشكل صحيح) مضللاً بشكل عام وفي ذهني يجب تجنبه حيثما أمكن ذلك.

سأدرس هذا الأمر بمزيد من التفصيل وأضع مثالاً أكثر اكتمالاً لما أرى أنه الناتج المرغوب. قد يكون اختبار الاتصال في Windows PowerShell تصميمًا مثيرًا للجدل ، لكنني أعتقد أنه كان خطوة في الاتجاه الصحيح ، إذا كان غير مكتمل للغاية.

@ iSazonov لم أتفق معك بعد القراءة الأولى ولكن بعد الاختبار ، أفهم وجهة نظرك

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

قيمتي $ a و $ b هي ما أتوقعه ولكني لا أريد الناتج الإضافي.

يحتوي Select-String أيضًا على Quiet Parameter ولا علاقة له بالسلوك "التفاعلي"

أوافق على أن هذا الأمر يحتاج إلى معلمة إضافية لتغيير السلوك (هادئ أم لا).

أفضل المعلمة "Interactive" ليس افتراضيًا ولكن ربما تكون معلمة التبديل "NoInteractive" تعديلًا أفضل للسماح بالأولوية في الاستخدام التفاعلي.

حسنًا ، إليك ما أعتبره تطبيقًا أكثر فائدة إلى حد ما.

نقاط عامة

1. يتم تحويل كافة مخرجات المضيف / المعلومات الحالية إلى تيار -Verbose . حاليًا لم يتم استخدام هذا _على الإطلاق_ ، وهذه حالة استخدام مثالية لها.
2. لا يوجد شريط تقدم ما لم يتم تحديده بمحول -ShowProgress .
3. قم بإزالة مفتاح التبديل -Ping (هو السلوك الافتراضي).

الإخراج الأساسي

Test-Connection www.google.com

• يجب تضمين المعلومات من الخاصية Replies لكائن المخرجات في كائن الإخراج الرئيسي ، ويجب أن يكون وضع الإخراج الأساسي _multiple_ الكائنات ، يمثل كل منها كائن ping محاولة / رد.
• المخزن المؤقت _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 إما على ETS أو خصائص الفئة التي تحسب بيانات التلخيص من PingReplies الأربعة الخاصة بهم.
• ملاحظة: هذا نوع الكائن نستخدمه يتم التنصت في الوقت الراهن، وجميع PingReply الأجسام تقريرا TtlExpired كما وضعهم. يوصي بالتحقيق في تقدم الإصلاح الخاص بـ .NET Core 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 وهو ممارسة غير طبيعية أكثر.

لا يوجد شريط تقدم ما لم يتم تحديده باستخدام مفتاح -ShowProgress.

سلسلة الإخراج وشريط التقدم قيد التنفيذ الحالي كبدائلين. نحتاج فقط واحد. يُستخدم شريط التقدم في Windows PowerShell cmdlet. المفضل لدي هو إخراج سلسلة في جلسة تفاعلية. إنه أكثر ملاءمة.
ولا نقوم أبدًا بإيقاف شريط التقدم بمفتاح. لدينا $ ProgressPreference لسيناريوهات البرنامج النصي. تعرض بعض أوامر cmdlets شريط تقدم فقط للعمليات الطويلة بواسطة المؤقت.

قم بإزالة مفتاح -Ping (هو السلوك الافتراضي).

أفضل ممارسة هي استخدام معلمات صريحة في البرامج النصية. يجعل الكود أكثر قابلية للقراءة. لم يكن ذلك ضروريًا في Windows PowerShell cmdlet حيث تم تنفيذ الأمر ping فقط. تنفذ أوامر cmdlet الجديدة المزيد من الوظائف ونحتاج إلى معلمة صريحة جديدة لكل منها.

تم تنفيذ اقتراحك بواسطتي في الخطوة الأولى ثم تم رفضه باعتباره غير مناسب للاستخدام في جلسة تفاعلية. على سبيل المثال ، يمكننا النظر إلى شاشة فارغة لفترة طويلة جدًا بعد تشغيل الأمر Test-Connection www.google.com -TraceRoute. لذلك تم تغيير التنفيذ لإظهار ناتج (سلسلة أو شريط تقدم) لكل استجابة.

عرض التقدم ليس ضروريًا مع تنسيق الكائن المنفصل ، حيث يمكننا بسهولة رؤية التقدم حيث يتم إرسال كل كائن إلى الإخراج. السبب الوحيد المطلوب هنا هو أننا لا نخرج البيانات إلى خط الأنابيب كما يتم استردادها مثل أي أوامر cmdlet أخرى في PowerShell. إذا قمنا بالإخراج على كل PingReply أو قفزة التتبع لـ -TraceRoute فإننا _لدينا_ عرض تقدم مدمج في عرض الإخراج.

كان اقتراحي أعلاه هو تقديم التبديل التفاعلي لتقسيم السيناريو التفاعلي والسيناريو. تقترح أن تفعل الشيء نفسه مع مفتاح Verbose الذي يعد ممارسة غير طبيعية أكثر.

-Verbose هو معلمة شائعة وبالتالي فهو خيار طبيعي أكثر بكثير لأمر cmdlet من مفتاح جديد تمامًا. لا نحتاج إلى إعادة اختراع العجلة هنا.

أفضل ممارسة هي استخدام معلمات صريحة في البرامج النصية. يجعل الكود أكثر قابلية للقراءة. لم يكن ذلك ضروريًا في Windows PowerShell cmdlet حيث تم تنفيذ الأمر ping فقط. تنفذ أوامر cmdlet الجديدة المزيد من الوظائف ونحتاج إلى معلمة صريحة جديدة لكل منها.

أنا لست هنا ولا هناك بخصوص هذا الأمر ، ولكن عادةً لا يحتوي السلوك الافتراضي لأمر cmdlet على مفتاح تبديل. على سبيل المثال ، ليس لدينا مفتاح تبديل -Loud كعكس -Quiet .

عرض التقدم ليس ضروريًا مع تنسيق الكائن المنفصل ، حيث يمكننا بسهولة رؤية التقدم حيث يتم إرسال كل كائن إلى الإخراج.

مع اقتراحك أعلاه ، نجمع كائنات "ping" في كائن "meta" ومن المستحيل إخراج كائنات "ping" في الوقت الفعلي - يمكننا إخراج كائن "meta" فقط في خط الأنابيب - سيرى المستخدم عرضًا فارغًا في كل الأوقات.

-Verbose هي معلمة شائعة وبالتالي فهي خيار طبيعي أكثر بكثير لـ cmdlet من مفتاح جديد تمامًا.

لست على علم بأي أمر cmdlet كان يخرج معلومات مهمة إلى الدفق المطول. نستخدم هذا الدفق دائمًا لعرض معلومات تشخيصية إضافية حتى نفهم عملية تشغيل أمر cmdlet.

عادةً لا يحتوي سلوك cmdlet الافتراضي على مفتاح تبديل.

إنه مناسب لمجموعة معلمة واحدة. الآن لدينا العديد من مجموعة المعلمات ونحتاج إلى تعيين كل منها بشكل صريح.

مع اقتراحك أعلاه ، نجمع كائنات "ping" في كائن "meta" ومن المستحيل إخراج كائنات "ping" في الوقت الفعلي - يمكننا إخراج كائن "meta" فقط في خط الأنابيب - سيرى المستخدم عرضًا فارغًا في كل الأوقات.

كائن التعريف غير ضروري. كما هو مذكور في الاقتراح أعلاه ، سيتم إنشاء الكائنات وإخراجها لـ _each_ PingReply أو trace hop. النموذج ليس هو الكود النهائي ، إنه مجرد وسيلة سهلة لتكرار التنسيق لتوضيح الفكرة. سيتم إخراج كل إدخال في الجدول واحدًا تلو الآخر. يرجى قراءة الاقتراح الكامل.

لست على علم بأي أمر cmdlet كان يخرج معلومات مهمة إلى الدفق المطول. نستخدم هذا الدفق دائمًا لعرض معلومات تشخيصية إضافية حتى نفهم عملية تشغيل أمر cmdlet.

لست على علم أيضًا بأي _ أي _ أوامر cmdlet التي تقوم بشكل روتيني بإخراج معلومات "مهمة" للمعلومات / المضيف وليس لإخراجها باستثناء عدة مستويات مدفونة في عمق كائن آخر.

إنه مناسب لمجموعة معلمة واحدة. الآن لدينا العديد من مجموعة المعلمات ونحتاج إلى تعيين كل منها بشكل صريح.

لا أعتقد أن هناك فائدة كبيرة من القيام بذلك ، لكنه لا يسبب قدرًا كبيرًا من الضرر الذي أفترضه. أنا ببساطة أعتقد أنها مضيعة للوقت ؛ لست متأكدًا من أن الكثير من الأشخاص سيرون فائدة كبيرة في تحديد مفتاح للسلوك الافتراضي.

كائن التعريف غير ضروري.

_إنه ضروري ._
هذا النهج يجعل الأمر cmdlet شيئًا عديم الفائدة. إذا كانت لديك شبكة بها مشكلات ، فحاول تشغيل تشخيص باستخدام أمر cmdlet هذا. لا يمكنك القيام بذلك. سوف ترميها وتتخذ أدوات ping و traceroute. ولكن يمكنك الآن إجراء نفس التشخيصات باستخدام الأمر cmdlet الجديد في كل من وحدة التحكم ، وعلى سبيل المثال ، في نظام المراقبة باستخدام برنامج نصي. أتفهم أنه من الصعب فهم ما إذا لم تقم بإجراء تشخيصات شبكة منتظمة. تعرف على عدد المعلمات التي تمتلكها هذه الأدوات المساعدة الأصلية ، خاصة في إصدارات Unix. كل منهم مهم للتشخيص. يتمثل فن التشخيص في استخدام تركيباتها ومعانيها السحرية. حاولت إضافة كل هذا إلى الأمر cmdlet الجديد.

أنا ببساطة أعتقد أنها مضيعة للوقت

استخدام المعلمات الموضعية يساعدك :-)

الملخص القصير للجنة PowerShell.

تم تصميم cmdlet الحالية

• للحصول على cmdlet المحمولة لجميع الأنظمة الأساسية المدعومة. حقًا لا يزال لدينا بعض المشكلات في .Net Core لذا لا تعمل جميع الميزات على مخططات Unix
• للحصول على ميزات الأدوات الشائعة مثل ping و traceroute و pathping و Portqry.exe وغيرها
• للحصول على كائنات مخرجات مفيدة في __النصوص__ مناسبة لتحليل إمكانية الوصول إلى الشبكة البسيط والمتعمق
• للحصول على مخرجات مفيدة لوحدة التحكم مع _header_ و _footer_. لاحظ أن الأمر cmdlet يعرض معلومات مفيدة أكثر في بعض السيناريوهات من الأداة المساعدة الأصلية.
• للسماح بالتعزيزات المستقبلية مثل الاختبار عن بُعد "اختبار الاتصال - المصدر ... - الوجهة ..."

المشكلة الرئيسية هي كيفية الجمع بين إخراج وحدة التحكم التفاعلية (السيناريو التفاعلي) وإخراج الكائنات في خط الأنابيب (سيناريو البرنامج النصي). اقتراحي الحالي هو إجراء تقسيم إما باستخدام معلمة (-Interactive) أو باستخدام أمر cmdlet جديد (عرض الاتصال للسيناريو التفاعلي وسيناريو اختبار الاتصال للبرنامج النصي).
كما أقترح تغيير اسم الأمر cmdlet إلى Test -__ Connectivity__ وهو أكثر دقة. سيسمح أيضًا بالاستخدام المجاني لـ Windows cmdlet القديم من خلال البروكسي (WCM) بدون تعارض في الاسم.

iSazonov ، هل يمكنك تقديم مثال لمثل هذا التشخيص الذي يتطلب وجود كائن ميتا يخفي جميع البيانات؟ اقتراحي هو نقل المعلومات من كائن التعريف إلى كل كائن PingReply ؛ لا أرى كيف سيقلل ذلك من فائدة الأمر cmdlet.

كيف تضع الإحصائيات من التذييل إلى أول كائن "ping" إذا أخرجت الكائن مباشرة بعد الإنشاء؟

ما المعلومات التذييل؟ معلومات التذييل الوحيدة من ping هي Ping complete.

لا توجد إحصاءات في كائنات التعريف الحالية التي يمكنني رؤيتها في أي مكان ؛ إنها تحتوي فقط على جميع الكائنات بنفس المعلومات التي يتم تقديمها كبيانات سلسلة في تدفق المعلومات ، فقط بتنسيق أقل قابلية للاستخدام.

النقطة هنا هي الحفاظ على أوامر cmdlets (في هذه الحالة Test-Connection) بنفس الطريقة في كلا الإصدارين (WinPS و Pwsh) مع إضافة مفتاح إلى cmdlet في هذه الحالة لـ `` تعطيل '' هذا الإخراج سيكون خاطئًا كما ذكرت قبل أن يعني ذلك أنه سيتعين تحديث كل برنامج نصي / وحدة تستخدم الأمر cmdlet هذا ، فالحل يجعله بنفس الطريقة في كلا الإصدارين

@ NJ-Dude Windows cmdlet مبني على WMI ومن المستحيل نقله بالتوافق مع الإصدارات السابقة. تم أيضًا تجميد 5.1 - لن تكون هناك إضافات في المستقبل.

@ NJ-Dude Windows cmdlet مبني على WMI ومن المستحيل نقله بالتوافق مع الإصدارات السابقة. تم أيضًا تجميد 5.1 - لن تكون هناك إضافات في المستقبل.

أفهم وأعلم ذلك ، أنا فقط أقول أن SYNTAX والوظيفة يجب أن تكون هي نفسها ، بمعنى ، إذا كان استخدام QUIET لا يعرض أي إخراج ، فلا ينبغي أن يعرض أي إخراج بغض النظر عن نكهة PS المستخدمة.

أنا أقول فقط أن SYNTAX والوظيفة يجب أن تكون هي نفسها

إنه مستحيل. تعد وحدة توافق Windows طريقة واحدة للحصول على الوظائف القديمة.

يجب أن يتم تخزين إخراج cmdlet واستخدامه دون الحاجة إلى منع العرض غير المرغوب فيه يدويًا إلى وحدة التحكم المنفصلة إلى حد ما عن الإخراج الرئيسي.

لا توجد أوامر cmdlets أخرى تتصرف بهذه الطريقة ، حيث تكون البيانات الأكثر فائدة في شكل سلسلة في دفق المعلومات. لا يوجد سبب يجعلها تتصرف بهذه الطريقة. يجب أن تكون جميع البيانات على تدفق الإخراج ، فترة . توجد بيانات إضافية في التدفقات المطولة أو التصحيح حسب الحاجة. يعد استخدام دفق المعلومات بهذه الطريقة غير مسبوق حرفيًا لأمر cmdlet الذي يتم شحنه مع PowerShell نفسه.

وكما ذكرنا ، لا توجد بيانات في التذييل تذكرها يجب أن تكون على وجه التحديد في التذييل ؛ كل ذلك متاح من البداية أو عند معالجة كل رد.

وضع هذا في قائمة انتظار لمناقشة اللجنة

Soooo لقد فقدت مسار الخيط هنا قليلاً ، وأواجه مشكلة في الأعشاب الضارة ، لكن ما أقوم به من أساسيات دون اعتبار للتنفيذ هو:

• يجب إخراج البيانات سطرًا بسطر. أعتقد أن هذه هي الحالة الحالية لكل من Test-Connection s و ping.exe وآخرون
• يجب إرجاع البيانات ككائن منظم. يجب أن يكون التنسيق محايدًا لهذه الحقيقة. (على الرغم من فظاعة هذا الأمر ، فقد رأيت منسقًا يرسل سلسلة JSON إلى وحدة التحكم على الرغم من حقيقة أنه عنصر PSObject تحت الغطاء. وجهة نظري هي ببساطة أنه يمكن القيام بذلك.) التنسيق هو أيضًا مكان حيث مسموح لهم بتغيير ما نريد دون تغيير التغييرات. (أوافق بشدة أيضًا مع @ vexx32 على أننا يجب أن نكون حذرين بشأن رؤوس الأعمدة التي لا تتطابق مع أسماء الخصائص. إنه ضروري أحيانًا لسهولة القراءة ، ولكنه أيضًا يصيبني بالجنون.)
• يجب أن يصدر -Quiet أي شيء باستثناء True / False باعتباره منطقيًا ، تمامًا مثل Windows PowerShell.
• إذا كان هناك المزيد من المعلومات التي نحتاج إلى إرسالها أكثر من الحالة الافتراضية (والتي يجب أن تكون أكثر من الحد الأدنى المنطقي -Quiet case) ، فإن -Verbose يبدو معقولًا ، لكنني لم أفكر في ذلك بما فيه الكفاية. (هذا أيضًا حيث أفقد الخيط ، من الصعب معرفة ما يريده المزيد من الأشخاص أعلاه).
• من المستحيل تقليد نفس الكائن ( cimv2\Win32_PingStatus ) مع نفس خصائص Windows PowerShell (لأن NET Core و WMI وما إلى ذلك) ، ولكن يجب أن نحاول الاقتراب منه قدر الإمكان.
• لا أعلم عن التقدم. رأيي الرفيع المستوى هو أن التقدم لا يزال يدفع الجميع إلى الجنون لأنه بطيء (على الرغم من التحسينات التي أجريناها) ، ولكن أيضًا لا يهم كثيرًا في عدم التفاعل لأن الجميع يضعون $ProgressPreference أي حال.

يبدو أمرا جيدا لي!

التقدم يزعجني بشكل أساسي لأنه لا يمكن التعامل معه في استدعاء الأمر ؛ عليك أن تحدد ProgressPreference $. أتمنى حقًا أن تكون هذه معلمة مشتركة .... لكن لدي مشكلة أخرى تتعلق بهذا الأمر ، لذلك دعونا لا ندخل في ذلك هنا! :ابتسامة:

استعرضت لجنة @ PowerShell / بوويرشيل هذا. اتفقنا على أن Test-Connection يجب أن يحاكي السلوك كما كان في Windows PowerShell 5.1 بأكبر قدر ممكن (بما في ذلك -Quiet ). هذا يعني أنه يجب إرسال كائن مخرجات PingStatus (بإسقاط win32_ ) لكل رد به الخصائص في التنسيق الافتراضي وأي عناصر إضافية متوفرة. لا ينبغي استخدام التقدم.

هل سيكون شخص ما على استعداد لتأليف RFC قصير يعرض بناء جملة cmdlet جنبًا إلى جنب مع تنسيق الإخراج المقترح للمراجعة؟

@ stevel-msft سأكون سعيدًا بذلك. :)

أنا أحب صوت ذلك.
شكر

من المثير للاهتمام أن PR 3125 غطى كل هذا ولكن تم رفض استخدام Test-Connection ، لكننا الآن أكملنا دائرة. ماذا عن العودة إلى 3125؟

بالنظر إليها باختصار ، يبدو أنها استبدلت بشكل أساسي Test-Connection بأمر تم تنفيذه بشكل مختلف على منصات Unix لمحاولة محاكاة أمر Windows؟ هل أقرأ هذا صحيح؟

لا أعتقد أن هذا هو أفضل خيار متاح لنا ؛ يعتبر الاتساق عبر كلا النظامين الأساسيين في تنفيذ الأمر ككل أكثر قيمة. قد يحتوي على بعض الأفكار المثيرة للاهتمام التي يمكننا الاستفادة منها ، أنا متأكد!

سأقوم بإسقاط رابط إلى مسودة RFC عندما أنتهي من كتابتها ولا تتردد في التعليق ، والتعديل ، وما إلى ذلك ... أود سماع المزيد من وجهات النظر حول هذا الموضوع. 🙂

تحرير: https://github.com/PowerShell/PowerShell-RFC/pull/172

استندت حالة الاستخدام الخاصة بي للحث على ذلك على الرغبة في استخدام PowerShell Core على Linux ، ولكن تم اختبار التطبيق بالكامل عبر كل من Windows و Linux. كان من المفترض أن يحل محل الأمر المفقود بالكامل.

متى سنرى هذا؟ في 6.2.2؟ متى من المحتمل أن تهبط؟
(كان من المضحك رؤية هذا الموضوع محتدماً من أبريل 2018 إلى الآن أكثر من _ -هدوء_ كونه صاخبًا. يبدو أن هذا التغيير لا يفكر فيه)

يمكنني كتابة هذا الرمز بسهولة تامة على ما أعتقد ، أنا فقط أنتظر RFC ليتم قبوله. بمجرد حدوث ذلك ، سأقوم بإنجازه وأرسل PR لهذا الغرض. :ابتسامة:

أوه اعتقدت أن الحالة كانت أنه تمت الموافقة عليه (لا أعرف بالضبط ما هي الدول أو ما هي العملية الكاملة). لكن شكرا على التحديث. لا يزال من المؤسف أن الأمر استغرق أكثر من 12 شهرًا لجعله هادئًا :)

أكثر من 12 شهرًا لجعلها هادئة

كنت أتوقع المزيد من ردود الفعل

@ vexx32 ، يمكنك البدء في ترميز هذا ووضعه خلف علامة تجريبية في حالة

@ SteveL-MSFT لقد حصلت بالفعل على تطبيق يعمل في الغالب. سوف أتطلع إلى إرسال PR مع بعض العلامات التجريبية قريبًا حتى نتمكن من التحدث عن الكود بشكل أكثر تحديدًا. 💖

بعد التفكير في الأيام الأخيرة في السلوك المطلوب ، أفضل أن يكون لدي سلوك تفاعلي بحد أدنى من المعلمات افتراضيًا (الكتابة السريعة والعرض السهل للمستخدم) ، والتي ستكون مناسبة في جلسة تفاعلية. والتحويل إلى نمط البرنامج النصي مع معلمات إضافية (وهذا يعني وجود أنواع مختلفة في الإخراج).

هل يمكنك أن تشرح بالتفصيل كيف تعتقد أن هذا يمكن أن يعملisazonov؟

@ vexx32 هل تسأل عن التنفيذ أو تصميم

بشكل أساسي ، ما تعتقده سيكون عليه UX لذلك ، على ما أعتقد. :)

في جلسة تفاعلية ، أفضل تجربة مستخدم هي
1. الحد الأدنى من الكتابة
هذا يعني:
- ping هو الافتراضي
- التبديل إلى وضع آخر (traceroute وما إلى ذلك) بمعامل واحد
2. إخراج سهل الاستعمال
هذا يعني:
- محاكاة ping.exe (tracert.exe وغيرها) الإخراج _ على مضيف وحدة التحكم _ كما حاولت في الكود التجريبي - مع الرؤوس والتذييلات والأسطر الإعلامية المنسقة جيدًا. لا داعي للتفكير في أنواع المخرجات - لا يتم استخدامها ، بل يتم عرضها فقط.
- إضافة معلمات للتبديل إلى وضع البرنامج النصي - أي لمنع إخراج النص سهل الاستخدام على مضيف وحدة التحكم وإصدار كائنات مكتوبة قوية. لا حاجة لتنسيق هذا الإخراج. ناقشنا Quiet الذي يُرجع True / False ولكننا نحتاج إلى معلمة (معلمات) لإصدار كائنات خام قوية مكتوبة أخرى (مثل -RawOutput). من المقبول تجربة المستخدم لاستخدام معلمات إضافية في البرامج النصية.

شكرًا ، أعتقد أنني أفهم ما تحصل عليه بشكل أفضل قليلاً الآن.

لا أرى حقًا الحاجة إلى وضع مزدوج مثل هذا ، رغم ذلك؟ لا توجد أوامر cmdlets أخرى في PowerShell بها هذا التقسيم بين المعلمات التفاعلية و "وضع البرنامج النصي".

إذا كنت تريد الإخراج الدقيق لـ ping / tracert ، فلماذا لا تستخدم هذه الأدوات المساعدة مباشرةً؟

لم يبذل PowerShell أبدًا جهدًا كبيرًا لتقليد أمر موجود تمامًا ؛ أعتقد أن Get-ChildItem هو الأقرب على الأرجح ، لكنه تقريبًا الوحيد الذي يفعل ذلك.

إذا أردنا محاكاة عرض ping / tracert تمامًا كما تقول ، فإنني أقترح بدلاً من ذلك أن يكون لدينا أمر cmdlet أو وظيفة منفصلة ، على سبيل المثال ، Show-Connection ، بدلاً من الفوضى Show-Command مع معلمات إضافية لا توجد بها سابقة أو حاجة داخل PowerShell.

لا أرى حقًا الحاجة إلى وضع مزدوج مثل هذا ، رغم ذلك؟ لا توجد أوامر cmdlets أخرى في PowerShell بها هذا التقسيم بين المعلمات التفاعلية و "وضع البرنامج النصي".

لدينا فجوات في نظام التنسيق. على سبيل المثال ، لدينا مشكلة في طلب الحصول على dir header / footer. هناك سيناريوهات أخرى حيث سيكون ذلك مناسبًا.

إذا كنت تريد الإخراج الدقيق لـ ping / tracert ، فلماذا لا تستخدم هذه الأدوات المساعدة مباشرةً؟

أنا افعل :-). هذه المرافق الأصلية قوية جدًا لأنها منخفضة المستوى ولكنها مجمدة. يمكننا القيام بأشياء _أذكى_ مما تفعله - هذا هو جوهر ظهور أمر cmdlet هذا (وليس فقط لإجراء اختبار ping) - إذا ألقيت نظرة عميقة على كيفية تشكيل العناوين والأسماء في الأمر cmdlet وكيف يتم تشكيلها الآن هي الإخراج ، سترى أن هناك فائدة أكبر بكثير مما كانت عليه في الأمر ping الأصلي. إنها تبدو كأنها حيل لكنها مفيدة جدًا حقًا.

بالطبع لدينا ثغرات في نظام التنسيق. لكنني لا أعتقد أن الإجابة تكمن في تنفيذ حل مخصص _ كل مرة_. هذا فقط يخلق المزيد من المشاكل ويجعل من الصعب تحسين أو إعادة كتابة نظام التنسيق ليكون أكثر فعالية في جميع المجالات.

نعم ، لقد قمت ببعض العمل الرائع معها! أنا أقدر ذلك كثيرا. الوضع الحالي للإخراج ليس مفيدًا لأي شيء _ لكن_ للاستخدام التفاعلي. يمكننا ببساطة إزالة خطوة الإخراج وتسميتها Show-Connection ثم استخدام ما كتبته في حل أكثر تركيزًا على PowerShell مقابل Test-Connection نفسه كما أوضحته في RFC.

@ vexx32 لقد جربت للتو العلاقات العامة الخاصة بك وقد

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؟

@ SteveL-MSFT لم يتغير إخراج الكائن هذا من التنفيذ الأولي في PS Core ؛ كان ناتج النجاح دائمًا كائنًا واحدًا. 🙂

كما هو مذكور في التعليقات الختامية للعلاقات العامة ، هذا مجرد تنفيذ جزئي لـ RFC للمساعدة في تبسيط المراجعات. سوف أقوم بتقديم عرض عام للمتابعة قريبًا. ما عليك سوى إعادة تحديد هذا الفرع لإزالة الالتزامات المكررة الآن وإرسال الباقي للاقتراب أكثر من التكافؤ الحقيقي مع تطبيق Windows PowerShell. ستظل مختلفة إلى حد ما (كما يتضح من RFC التي استعرضناها قبل بضعة أسابيع) ولكن نأمل أن تكون أكثر تنوعًا. 😊

@ SteveL-MSFT انظر # 10697 للفصل التالي في هذه المغامرة! 😊

: tada: تمت معالجة v7.0.0-preview.5 .: tada:

روابط مفيدة:

• ملاحظات الإصدار

في الإصدار 7.0.0 اختبار اتصال-هادئ ما زال يعطي
اختبار الاتصال: فشل اختبار الاتصال بالكمبيوتر "تم حذفه": لا يمكن حل اسم الهدف.
بدلا من
خاطئة

chvol ، هل يمكنك من فضلك فتح عدد جديد لذلك بأكبر قدر ممكن من التفاصيل؟

شكر! 🙂