Powershell: هل يمكننا استخدام | في السطر التالي كحرف استمراري؟

في نص برمجي - نعم ، ولكن هذا من شأنه أن يكسر القدرة على استخدام المدرسة القديمة ، انقر بزر الماوس الأيمن أو Alt + e ، والصق p في وحدة التحكم لأنه بعد الإدخال ، سيكون لديك سطر أوامر كامل.

مناقشة ذات صلة # 2819

أرى تجربة مستخدم سيئة للجلسة التفاعلية: بعد أول NewLine سينتظر المحلل اللغوي التالي NewLine أو يتخطى المسافات حتى | أو NewLine - سيؤدي ذلك إلى إرباك المستخدم .

بالنسبة للبرنامج النصي ، هذا طلب لحذف حرف استمرار `` (backtick) في الوقت المناسب حيث يمكننا دائمًا كتابة:

$result = Get-Process |
     Where WS -gt 500mb |
     Format-Table VM, WS, CPU, ID, ProcessName

يقوم المحلل اللغوي بالفعل بهذا في أماكن أخرى.

if( 1 -eq (get-random 2)) {
    "True"
}
else {
    "False"
}

من الواضح أن قادرًا على فهم ذلك لا يعني أن الأشخاص _يجب_ أن يكتبوا سطورًا متعددة بهذه الطريقة - فقد تبنى العديد من الأشخاص أسلوب stroustrup كما هو مذكور أعلاه ، أو حتى "دعامة على خطهم الخاص" وأشياء نمط أخرى تكسر اللصق (خاصة وأن PSReadLine عبث بالنقر بزر الماوس الأيمن وجعل Ctrl + V يعمل). لا ينبغي أن يحدث أي فرق.

iSazonov بشكل تفاعلي ، إذا قمت else أعلاه. يمكنك الضغط على shift + enter لكتابته في وحدة التحكم (عندما يكون لديك PSReadLine).

لا يعبث PSReadline بالنقر بزر الماوس الأيمن ، على الرغم من وجود حالة زاوية حيث يتم توسيع حرف TAB إلى شيء لا يحتوي عليه بدون PSReadline - ولكن هذا له علاقة أكثر بكيفية عدم عمل الإدخال متعدد الأسطر مثل متوقع إذا كنت لا تستخدم PSReadline.

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

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

يمكن أن يستخدم لصق النقر بزر الماوس الأيمن بعض التحديث ، ولصق المخزن المؤقت للحافظة بالكامل في وحدة التحكم كما لو كنت قد أدخلت shift + في كل سطر ثم قم بتشغيله بهذه الطريقة. حتى بدون التفكير في هذه المشكلة ، أعتقد أنه سيكون مفيدًا في حد ذاته - كم مرة قمت بالنقر بزر الماوس الأيمن فوق شيء لم يكن صحيحًا تمامًا (تحليل الأخطاء) ورأيت مجموعة من رسائل الخطأ ، ربما تتخللها بعض الأوامر الذي أعدم؟ قد يكون هذا ضارًا جدًا ، اعتمادًا على ما كنت تلصقه (عفوًا ، لم يتم تحليل الأمر cd بشكل صحيح ، لذلك بقيت في دليلي الحالي C: \ عند تنفيذ الأمر del *.* -r -fo . ..). سيكون من الأفضل أن يقوم النقر بزر الماوس الأيمن بلصق الكتلة بالكامل بالفعل ، ويقوم PowerShell بمعالجة ذلك جيدًا على جانب التنفيذ بالفعل.

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

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

الكل ليقوله: +1 لوجود خطوط أنابيب دعم PowerShell في بداية السطر بدون أحرف استمرار السطر ، وطلب لإصلاح لصق النقر بزر الماوس الأيمن بحيث يكون هناك تناسق أفضل بين الاستخدام التفاعلي وتجربة البرمجة النصية.

النقر بزر الماوس الأيمن ليس ميزة PowerShell ، إنها ميزة مضيفة. لا يمكن أن يفترض Conhost دائمًا أن محاكاة الكتابة تعادل اللصق دون بعض التنسيق مع عملية وحدة التحكم الحالية.

نعم فعلا. قد يجعل النقر بزر الماوس الأيمن أمرًا محرجًا. بنفس الطريقة التي يعمل بها else .

هذا من شأنه أن يجعل الأوامر (سواء في وحدة التحكم أو في الملفات) ذات أنابيب متعددة أكثر قابلية للقراءة ، وكما أشير من قبل ، فإن لها نفس المشكلة تمامًا التي يحدثها إذا / آخر عند تنفيذها في الموجه.

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

مرسل من جهازي الآي باد

في 8 مارس 2017 ، الساعة 17:04 ، كتب مايكل تي لومباردي < [email protected] [email protected] >:

هذا من شأنه أن يجعل الأوامر (سواء في وحدة التحكم أو في الملفات) ذات أنابيب متعددة أكثر قابلية للقراءة ، وكما أشير من قبل ، فإن لها نفس المشكلة تمامًا التي يحدثها إذا / آخر عند تنفيذها في الموجه.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/PowerShell/PowerShell/issues/3020#issuecomment-285101638 ، أو تجاهل الموضوع https://github.com/notifications/unsubscribe-auth/AHgYUW- mDh_8nDUr671LdathDzLZPhS7ks5rjt9-gaJpZM4LohkD .

هل سيتطلب هذا التغيير بالضرورة ألا يظل | حرفًا تكميليًا في EOL _ وكذلك في بداية السطر الجديد؟ لا أتوقع ذلك.

RichardSiddaway يتعلق الأمر

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

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

ضد.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

jaykul في المثال الخاص بك فوق المسافة البادئة مفيد بنفس القدر من منظور حدة البصر. يبدو أن رمز الأنبوب مجرد مؤشر إضافي (وغير ضروري للمنظمة البحرية الدولية).
بالنظر إلى مثالك ، هل هذا يروق لك كثيرًا؟

Get-Process | Where CPU | Where Path
|Get-Item | Where FullName -match "AppData"
|Sort FullName -Unique

من وجهة نظري ، يبدو هذا مفهومًا تمامًا:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" |
    Sort FullName -Unique

إنها المسافة البادئة التي تساعد (وهي الطريقة التي أكتب بها عادةً)

FWIW ، لم أفهم أبدًا استخدام backtick في خطوط الأنابيب الطويلة وحاولت سحقها كلما رأيتها في مراجعات الكود ، لأنها لم تكن ضرورية.

أفضّل صراحةً الأنبوب باعتباره الحرف الأول ، كما في المثال الأول ، JamesWTruher (وإن كان مع مسافة واحدة بين الأنبوب والحرف الأول للأمر) - فهو يعطي مؤشرًا مرئيًا واضحًا وصريحًا لخط أنابيب مستمر . تعطي المسافة البادئة استنتاجًا مشابهًا ، ولكن أقل وضوحًا ، عند التمرير فوق الكود.

Jaykul سيؤدي هذا إلى

PS> dir
>

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

PS> dir
>
>

حسنًا - أضف | sort Length واضغط على رجوع.

PS> dir
>
>
> | sort Length
>

ولا يزال لا شيء يحدث لأنه قد يكون هناك _لا يزال _ رمز استمرار لذا لا يزال يتعين الاستماع إلى سطر جديد. الآن تقول "لقد انتهيت من هذا - إنه لا يعمل ، دعنا فقط نحصل على التاريخ". اكتب Get-Date واضغط على رجوع. رائع - تحصل على الإخراج. لكنها ليست من Get-Date . كلا - لقد أكملت أخيرًا الأمر dir | sort Length لذلك هذا هو الناتج الذي تراه. في هذه الأثناء ، ينتظر قارئ الأوامر الآن إكمال الأمر الذي بدأته بـ Get-Date . أو قد يكون الأمر برمته مجرد خطأ.

ستكون هذه تجربة تفاعلية مروعة لأي مستخدم.

هل يمكننا جعله يعمل فقط في الملفات؟ نعم - ربما ولكن كما ذكر lzybkr ، كان أحد مبادئ التصميم الأساسية لدينا هو أنه يمكن ببساطة لصق ما

لذا بينما أنا في الواقع أحب كيف "|" ينظر إلى بداية السطر في أشياء مثل مطابقة نمط هاسكل:
fib n | n == 0 = 1 | n == 1 = 1 | n >= 2 = fib (n-1) + fib (n-2)
لن يعمل مع PowerShell.

مع التحذير من أنني طفل حديث الولادة عندما يتعلق الأمر بالأجزاء الداخلية ، فإليك بعض الملاحظات:

# This works everywhere
Get-Process |
Select-Object -First 1

# This errors at the prompt unless using soft returns, note the two blank lines;
# hitting enter after the first one causes it to error out.
# Note that with soft returns you can go just about forever before adding the next line.
Get-Process |


Select-Object -First 1

# This will run fine in either
If ($false) {
  ' False Output'
} Else {
  'True Output'
}
# This will error in the prompt (unless using soft returns) but pass in a file
If ($false) { 'False Output' }
Else { 'True Output' }

جانبا ، أتوقع / سأكون على ما يرام مع الفشل التالي في الموجه دون عوائد بسيطة ، مثل غير المحبوب إذا كان / آخر يفعل:

Get-Process
| Select-Object -First 1

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

لمخاطبة JamesWTruher - أتوقع أن الناس لن

Get-Process | Where CPU | Where Path
| Get-Item | Where FullName -match "AppData"
| Sort-Object FullName -Unique # I'm so proud of this highlighting "bug" by the way

تضمين التغريدة لن تدعمها التجربة التفاعلية بشكل صريح.

إذا كنتم تعتقدون حقًا أنه لا توجد اختلافات بين البرامج التفاعلية والنصوص البرمجية ، فأنت بحاجة إلى محاولة استخدام PowerShell بدون PSReadLine من حين لآخر.

حاول استخدام وحدة التحكم في ISE أو VS Code

ما لم يكن لديك PSReadline للتعامل مع استثناءات نوع "كتلة العبارة المفقودة" أو "عنصر أنبوب فارغ" ، لا يمكنك وضع سطر جديد بعد أنبوب ، ولا يمكنك كتابة أقواس على غرار Allman. لا يمكنك بالتأكيد كتابة أي مما يلي:

Get-Process |
Where CPU

if($True)
{



md5-9d813a39f05f47b572d1068b0164b382



Or whether I will write the (necessary) generic `catch { "You threw $_" }` handler after



md5-6b461006504b741b884d4fb3f126b489



And it won't let me put a comment where it thinks there should be code, so neither of these is possible:



md5-adc435ab733361316365acfc69de09df



```posh
Get-Process |
# I only want actual apps, with windows
Where MainWindowHandle

لذا ، نعم ، سيكون هذا "مكانًا آخر" حيث يمكنك الحصول على فاصل أسطر في البرنامج النصي ولكن ليس في وحدة التحكم. لكن لدينا بالفعل الكثير من هؤلاء (_ خاصةً_ إذا كنت لا تستخدم PSReadLine).

للإشارة إلى الكود الذي يمتلكهJaykul 1 و JamesWTruher 2 ، أستخدم هذا:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

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

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

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

إن وجود الأنبوب في السطر التالي بدلاً من نهاية السطر هو فكرة تشبه F # ، حيث يمكنك القيام بأشياء مثل هذا:

F# let f1 str server = str |> parseUserName |> getUserByName server |> validateLogin <| DateTime.Now

وأنا جميعًا مع أي شيء يجعل PS أكثر فاعلية (يقصد التورية) ؛)

ليس فقط F # ولكن أيضًا Elm و Haskell و Elixir وحتى دليل أسلوب قشرة Google (ولاحظ هنا أنه يتعين عليهم الهروب من الأسطر الجديدة للقيام بذلك ...).

michaeltlombardi كما هو الحال مع قذائف Unix ، يمكنك الهروب من الأسطر الجديدة في PowerShell إذا كنت تريد ذلك

Get-Process | Where CPU | Where Path `
| Get-Item | Where FullName -match "AppData" `
| Sort-Object FullName -Unique

F # حساس للمسافات البيضاء (قاعدة التسلل) بطرق لا يتعامل معها PowerShell. Elm و Haskell و Elixir ، بالطبع ، ليسوا قذائف.

_ شكاوى حول المضيفين السيئين _...

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

إذا كنتم تعتقدون حقًا أنه لا توجد اختلافات بين البرامج التفاعلية والبرامج النصية ، فأنت بحاجة إلى تجربة استخدام PowerShell بدون PSReadLine من حين لآخر.

لقد استخدمت PowerShell لأكثر من عقد بدون PSReadLine. هل هذا كاف؟

هذه الأخطاء في الموجه ما لم تستخدم عوائد بسيطة ، لاحظ السطرين الفارغين ؛

كيف يتم التعامل مع ذلك يعود إلى تنفيذ المضيف. افتح مشكلة على المضيفين المخالفين إذا كنت تريد تغيير ذلك.

بالضبط نفس المشكلة التي إذا كان / آخر يفعل عند تنفيذه في الموجه.

نعم. إنه غامض. آسف. لم أستطع التفكير في طريقة لجعلها تعمل بشكل موثوق. إذا ذهبنا مع OTBS بدلاً من مطابقة أسلوب قوس C # ، فلن يكون هذا مهمًا. في الواقع ، كان من الممكن أن يكون هناك الكثير من المزايا لاستخدام OTBS (مثل DSLs). لاحظ أيضًا: في مضيف وحدة التحكم الأصلية ، "نجح" لأنه بعد تلقي أول استثناء IncompleteParse ، استمر المضيف في قراءة الأسطر حتى وصل إلى سطر فارغ ، ثم نفذ النتيجة. لكن هذا يعني أنه كان عليك دائمًا الوصول إلى سطر جديد إضافي.

Jaykul إذن هل تريد عكس توجيه F # # light؟ شيء مثل # ثقيل حيث تكون المسافات غير ذات صلة والفاصلة المنقوطة إلزامية؟

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

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

كنت سأستخدم هذا النموذج إذا لم يكن تتبع أخطاء backtick مثل العثور على إبرة في كومة قش. لا ، أعتقد أنه سيكون من الأفضل فقط السماح بتنسيق الأنبوب في البداية كنمط في حد ذاته ، دون تفويض الهروب من الخط. : /

@ vexx32 بينما أوافق على أنه من الصعب رؤية "" ، "|" ليس.

Jaykul إذن هل تريد عكس توجيه F # # light؟ شيء مثل # ثقيل حيث تكون المسافات غير ذات صلة والفاصلة المنقوطة إلزامية؟

لا BrucePay ، أريد فقط خدعة بناء جملة أخرى مثل هذه:

try { throw 5 }
catch [ArgumentException] {  <# ... #> }
catch { Write-Warning Whatever }

التي تسمح لي بكتابة الأشياء _ بدقة_ في البرامج النصية ، دون القلق بشأن ما إذا كانت تعمل عندما تكتب في وحدة التحكم أم لا.

BrucePay صحيح ، ولدي بعض الأكواد باستخدام تلك backticks ، لكن ما نسعى إليه هنا هو القدرة على كتابة الكود بدونهم لجميع الأسباب @ vexx32 المدرجة.

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

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

نسعى هنا إلى القدرة على كتابة الكود بدونها

وجهة نظري هي أنك إذا وضعت | في نهاية السطر ، فإن المتابعة ضمنية ولا يلزم وجود حرف استمرار كما تطلب. ومن السهل رؤية الرمز | . واستخدم المسافة البادئة لجعل بنية الشفرة مرئية بوضوح. على عكس F # أو Python ، نحن لا نفرض المسافة البادئة لأن PowerShell عبارة عن غلاف وفي بعض الأحيان تحتاج إلى كتابة تعليمات برمجية كثيفة للغاية.

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

دون القلق بشأن ما إذا كان يعمل عند الكتابة في وحدة التحكم أم لا.

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

أفهم تمامًا أن تجربة وحدة التحكم أساسية. نقطتي هي ببساطة أن هذا لا ينبغي أن يكسر وحدة التحكم ، كما اقترحت في تعليقك _first_.

يجب أن يتصرف في وحدة التحكم _ بنفس الطريقة _ التي يقوم بها catch أعلاه: يمكنك فقط كتابته في وحدة التحكم حيث يكون لديك خط قراءة متعدد الأسطر مثل PSReadLine ويمكنك Shift+Enter لحقن سطر إضافي (أو يمكنك لصقه) - لا يحتاج إلى تغيير السلوك الحالي على الإطلاق.

بعد كل شيء ، هذه ميزة تهدف إلى تحسين تنسيق التعليمات البرمجية ، وليس تقليل الكتابة. يجب أن تعمل في تجربة البرمجة النصية ، وليس وحدة التحكم التفاعلية.

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

حق. لكن شيء النسخ واللصق لا يكون صحيحًا حاليًا إلا إذا كنت تلصق في PSReadLine Ctrl + V وليس عن طريق النقر بزر الماوس الأيمن - وسيعمل هذا التغيير هناك أيضًا. وهذا يعني أنه سيتطلب ReadLine قادرًا على لصق متعدد الأسطر ، ولكنه سيعمل افتراضيًا في PowerShell 5+

كما ذكرت أعلاه ، هناك عدد غير قليل من الحالات (إذا / غير ذلك ، حاول / أمسك ، وتعليقات ، وأقواس Allman ، وما إلى ذلك) حيث لا يكون هذا هو الحال إذا لم يكن لديك PSReadLine.

رأيي هو أن هناك حالة إضافية واحدة لقائمة المشكلات مع مضيفي غير PSReadLine ليس سببًا كبيرًا بما يكفي لاستبعاد ميزة - بعد كل شيء ، لن يعمل بناء الجملة هذا في PowerShell 4 أو 5 على أي حال ، لذلك ' لن تعمل أبدًا في ISE أو في مضيفي غير PSReadline. إن ما يدفعني إلى الجنون بعض الشيء هو أننا نبذل هذا الجهد الكبير في مناقشة مشكلة _ more_ واحدة تتعلق باللصق في {{not-our-problem}} ولكننا لا نرضى بحقيقة أنه سيكون بناء جملة لا يعمل في الأقدم إصدارات PowerShell ...

ملاحظة: لقد استخدمت حجة اللصق كأحد المبررات لاختيار BestPractices لاختيار OTBS بدلاً من Stroustrup أو Allman ، لكنني بالتأكيد سأشير إلى هذا الموضوع في الكتاب الآن 😁

I _really_ أتمنى أننا قد ذهبت مع OTBS. كانت DSLs أبسط بكثير.

OTBS هي ، بالطبع ، الطريقة الوحيدة الحقيقية ....

BrucePay - أنا متأكد من أنه لا يزال هناك بعض الأشخاص الذين Ctrl + v ، لكنني لا أخمن الكثير من الأشخاص ، ويجب عليهم التكيف ، واللصق دون النقر بزر الماوس الأيمن أو Alt + مفتاح المسافة ، e ، p متفوق من نواحٍ متعددة.

أعتقد أنه من المعقول جدًا التفكير في هذا التغيير.

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

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

ربما لن ينجح هذا ، ولكن يجب أن تبدأ:

diff --git a/src/System.Management.Automation/engine/parser/Parser.cs b/src/System.Management.Automation/engine/parser/Parser.cs
index a31f64fa0..37b897f7c 100644
--- a/src/System.Management.Automation/engine/parser/Parser.cs
+++ b/src/System.Management.Automation/engine/parser/Parser.cs
@@ -5653,6 +5653,11 @@ namespace System.Management.Automation.Language
                 }

                 pipeToken = PeekToken();
+                if (pipeToken.Kind == TokenKind.Newline)
+                {
+                    SkipNewlines();
+                    pipeToken = PeekToken();
+                }

                 switch (pipeToken.Kind)
                 {

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

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

الجزء الرئيسي مما قاله Jaykul أعلاه هو أننا نميل إلى أن نجد أنه من الأسهل فهم وقراءة استمرار الأمر في بداية السطر بدلاً من نهاية السطر.

RichardSiddaway يتعلق الأمر

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

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

ضد.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

لذا نعم ، أود أن أكون قادرًا على القيام بذلك في المستقبل

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

أحتاج إلى إجراء محاولة أخرى في وقت ما قريبًا. إنه لغز مثير للاهتمام ، لكنني لا أعرف حقًا كيفية حله حتى الآن. 😕

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

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

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

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

الآن لنختتمها في بعض اختبارات Pester ...

لا أعتقد أنه يحتاج حقًا إلى علم تجريبي ، بشرط أن يكون السلوك متوقعًا ومتسقًا وقابلًا للاختبار. إنه لا يكسر أي سلوك موجود مسبقًا بقدر ما أستطيع أن أقول.

لا يبدو حقًا أن هناك أي خلاف حول التصميم أيضًا.

كملاحظة جانبية أيضًا ، من السيء جدًا أن يسمح PowerShell بأسماء الأوامر أن تبدأ بـ "-". بخلاف ذلك ، يمكننا على الأرجح التفاف المعلمات على أسطر جديدة بدون علامات خلفية أيضًا. من المؤكد أن لدينا خاصية Splatting ، ولكن هذا يمكن أن يعمل _ مع Intellisense و Syntax Highlighting_ إذا لم تتمكن أسماء الأوامر من مطابقة أسماء المعلمات:

Get-AzureRmAppServicePlanMetrics
    -ResourceGroupName Default-Web-WestUS
    -Name ContosoWebApp
    -StartTime 2016-11-30T22:00:00Z
    -EndTime 2016-11-30T22:30:00Z
    -Granularity PT1M
    -Metrics Requests

أنا في انتظار التتمة التي تشبه الضجة ، لكنني أعتقد بالتأكيد أن خيار الحصول عليها كشخصية أولى أمر رائع. من المؤكد أنه يختلف بين النص التفاعلي والنص ، لكن هذا يتوافق مع طريقة PowerShell بالفعل.

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

لا أعرف سبب كون فريق MSFT سلبيًا جدًا في المرة الأخيرة ، ولكن إذا كان الرمز الخاص بك سيكون تحت العلامة التجريبية ، فيمكنني المراجعة بسرعة. كما يمكننا تمكين الميزة افتراضيًا في Powershell.config.json.

من السيء جدًا أن يسمح PowerShell بأسماء الأوامر أن تبدأ بـ "-".

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

"عنصر الأنبوب الفارغ غير مسموح به" ، لذلك يجب ألا تكون هناك مشكلة في توافق القطع إذا تم استخدام أنبوب لمتابعة السطر وبداية السطر التالي ، في نفس الوقت:

Get-Process | Where CPU | Where Path |
    | Get-Item | Where FullName -match "AppData" |
    | Sort FullName -Unique

الذي يعالج العديد من الشكاوى - لا توجد علامات خلفية ، أنبوب في بداية السطر للإشارة البصرية للاستمرارية ؛ لا يوجد تغيير في سلوك الفوري التفاعلي بعد كتابة السطر الأول لأنه يمكن أن يخبرنا ما إذا كان من المتوقع استمرار سطر ؛ لا يوجد الكثير من الالتباس مع عامل التشغيل المحجوز || لأنه مقسم على عدة أسطر ؛ ليست الكتابة أكثر من استخدام backtick وأنبوب ؛ لا تحتاج إلى مشاكل مع سطر تعليق بينهما وفقًا لأمثلة Jaykul if/else ، try/catch .

HumanEquivalentUnit - لا أستطيع أن أقول إنني معجب بهذا الاقتراح لأنني بصفتي كاتب سيناريو قد أقرر أنني أريد إزالة الأسطر الجديدة داخل برنامج نصي لاستخدام cmdline وسيترك سطر واحد غير عملي وغير بديهي أن IMO
تبدو فظيعة

Get-Process | Where CPU | Where Path |    | Get-Item | Where FullName -match "AppData" |    | Sort FullName -Unique

أي

kilasuit هذا الخط الذي تم تحريره يبدو غريبًا (لا يبدو فظيعًا بالنسبة لي ، فقط غريب) ، لكن هل هذا يختلف حقًا عن الكود الذي يحتوي على backticks وهو صالح الآن ، إذا قمت بإزالة الأسطر دون إزالة استمرار السطر؟ هل تعاني حاليًا من هذه المشكلة مع كود backtick؟

Get-Process | Where CPU | Where Path `    | Get-Item | Where FullName -match "AppData" `    | Sort FullName -Unique

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

تم تنفيذ الطلب الأولي.
نناقش الآن https://github.com/PowerShell/PowerShell-RFC/pull/179