Powershell: Можем ли мы использовать | на следующей строке как символ продолжения?

В сценарии - да, но это нарушит возможность использования старой закалки правой кнопкой мыши или вставки Alt + e, p в консоль, потому что после ввода у вас будет полная командная строка.

Связанное обсуждение # 2819

Я вижу плохой UX для интерактивного сеанса: после первого NewLine parser будет ждать следующего NewLine или пропускать пробелы до | или NewLine - это запутает пользователя .

Для скрипта это запрос на удаление символа продолжения `(обратная кавычка) во времени, поскольку мы всегда можем ввести:

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

Парсер уже делает это в других местах.

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

@lzybkr, очевидно, что синтаксический анализатор может понять, что это не означает, что люди _должны_ писать несколько строк таким образом - многие люди приняли стиль stroustrup, как указано выше, или даже "скобки на своей собственной строке" и другие элементы стиля, которые нарушают вставку (особенно после того, как PSReadLine испортил щелчок правой кнопкой мыши и заставил Ctrl + V работать). Это не должно иметь никакого значения.

@iSazonov интерактивно, если вы нажмете Enter, он не будет ждать, он просто запустит его. Точно так же, как сейчас с else выше. Вы можете нажать shift + enter чтобы ввести его в консоли (если у вас есть PSReadLine).

PSReadline не мешает щелчку правой кнопкой мыши, хотя есть угловой случай, когда символ TAB расширяется до чего-то, чего у него не было бы без PSReadline, но это больше связано с тем, как многострочный ввод не работает как ожидается, если вы не используете PSReadline.

Но моя точка зрения была действительно проще - интерактивный опыт должен был быть как можно ближе, в идеале идентичен помещению того же текста в сценарий. Эта функция будет отходом от этого намерения в обычно используемом сценарии - щелчок правой кнопкой мыши.

Здесь я говорю, что так или иначе выношу суждение по этому предложению, я просто указываю на то, что может быть неочевидным для всех.

Щелчок правой кнопкой мыши и вставка может потребовать некоторой модернизации, вставив весь буфер обмена в консоль, как если бы вы вводили shift + каждую строку, а затем запускали ее таким образом. Даже не учитывая эту проблему, я думаю, что это было бы полезно само по себе - сколько раз вы щелкали правой кнопкой мыши что-то, что было не совсем правильно (ошибки синтаксического анализа) и видели кучу сообщений об ошибках, возможно, перемежающихся с несколькими командами что казнили? Это может быть довольно вредно, в зависимости от того, что вы вставляли (ой, эта команда cd не разбиралась должным образом, поэтому я оставался в моем текущем каталоге C: \ при выполнении команды del *.* -r -fo . ..). Было бы лучше, если бы щелчок правой кнопкой мыши и вставка фактически вставлял весь блок, и PowerShell уже хорошо справляется с этим на стороне выполнения.

Технически интерактивный опыт сегодня уже отличается от помещения того же текста в сценарий, потому что щелчок правой кнопкой мыши и вставка выполняет команды по мере их вставки, а не как набор команд. В результате ошибки синтаксического анализа не предотвращают частичное выполнение при щелчке правой кнопкой мыши и вставке, в отличие от скриптов.

Кроме того, для интерактивной специальной оболочки PowerShell, я думаю, довольно редко пользователи вводят многострочные команды, набирая их в консоли, и для пользователей, которые делают это сегодня, они могут продолжать делать это так же, как и всегда. сделано. Для остальных из нас, нормальных людей, наши конвейеры будут в одной строке, если мы не щелкнем правой кнопкой мыши и не вставим, что, как было указано выше, можно и, вероятно, нужно улучшить, чтобы интерактивный опыт действительно был как можно ближе , в идеале идентично помещению того же текста в сценарий.

Все, что нужно сказать: +1 за наличие конвейеров поддержки PowerShell в начале строки без символов продолжения строки и запрос на исправление щелчка правой кнопкой мыши и вставки, чтобы обеспечить лучшую согласованность между интерактивным использованием и опытом написания сценариев.

Щелчок правой кнопкой мыши - это не функция PowerShell, это функция conhost. Conhost не всегда может предположить, что имитация набора текста эквивалентна вставке без некоторой координации с текущим консольным процессом.

да. Это может затруднить вставку при нажатии правой кнопкой мыши. Точно так же else .

Это сделало бы команды (как в консоли, так и в файлах) с несколькими каналами намного более читабельными и, как указывалось ранее, имеет ту же проблему, что и if / else при выполнении в командной строке.

До сих пор a | поскольку последний символ в строке работал как символ продолжения. Что приносит это изменение, особенно если оно перестает работать раньше

отправлено с моего айпада

8 марта 2017 года в 17:04 Майкл Т. Ломбарди < [email protected] [email protected] > написал:

Это сделало бы команды (как в консоли, так и в файлах) с несколькими каналами намного более читабельными и, как указывалось ранее, имеет ту же проблему, что и if / else при выполнении в командной строке.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на 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, я никогда не понимал использования обратной кавычки в длинных конвейерах и пытался подавить ее всякий раз, когда видел ее в обзорах кода, поскольку в ней не было необходимости.

Я явно предпочитаю канал в качестве первого символа, как в вашем первом примере, @JamesWTruher (хотя и с одним пробелом между каналом и первым символом команды) - это дает очень четкий и явный визуальный индикатор продолжающегося конвейера . Отступ дает аналогичный, но менее явный вывод при прокрутке кода.

@Jaykul Это полностью нарушит интерактивную работу с командной строкой. Например, вы вводите команду и нажимаете return.

PS> dir
>

Вы получаете результат? Нет, нет, потому что синтаксический анализатор ожидает следующего токена, который _может_ быть продолжением. Теперь ударь по клавише возврата. Ничего не происходит, за исключением того, что вы видите больше запросов, потому что синтаксический анализатор все еще ожидает токена, чтобы узнать, является ли он продолжением.

PS> dir
>
>

ОК - добавьте | sort Length и нажмите return.

PS> dir
>
>
> | sort Length
>

И по-прежнему ничего не происходит, потому что еще может быть токен продолжения, поэтому он все равно должен прослушивать новую строку. Теперь вы говорите: «Я с этим покончил - это не работает, давайте просто назначим дату». Вы вводите Get-Date и нажимаете return. Ура - получаешь выход. Но это не от Get-Date . Нет - вы, наконец, выполнили команду dir | sort Length так что это результат, который вы видите. Тем временем программа чтения команд ожидает, пока вы завершите команду, которую вы начали с Get-Date . Или все это может быть просто ошибкой.

Это было бы ужасным интерактивным опытом для любого пользователя.

Можно ли заставить его работать только в файлах? Да - возможно, но, как упомянул @lzybkr , один из наших базовых принципов проектирования заключался в том, что то, что работало в командной строке, можно было просто вставить в файл и наоборот. Мы даже поддерживаем вставку из документов Word с помощью символов emdash и endash.

Так что, хотя мне действительно нравится, как '|' смотрит на начало строки в таких вещах, как сопоставление с образцом Haskell:
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' }

В стороне, я бы ожидал / был в порядке со следующей ошибкой в ​​приглашении без мягких возвратов, как это происходит в случае с if / else без объятий:

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

@BrucePay Итак, верно. Интерактивный интерфейс не поддерживает его _ явно_.

Если вы, ребята, действительно думаете, что между интерактивом и сценариями нет различий, _ вам нужно время от времени пробовать использовать 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

Как уже отмечалось, отступы значительно упрощают чтение при быстром сканировании кода - я знаю, что эти три строки кода «связаны» вместе, и мне не нужно смотреть в конец, чтобы увидеть конвейер. Читаемость для меня - одна из самых важных вещей, когда я пишу код.

Иногда я добавляю обратную кавычку в конец после вертикальной черты, но когда я вспоминаю, что в этом нет необходимости, я бичеваю себя за это. Я пытаюсь избавиться от этой привычки (обратная кавычка, а не бричинг).

Копирование и вставка в консоль с помощью 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. Этого достаточно?

Это сообщение об ошибке в командной строке, если не используются мягкие возвраты, обратите внимание на две пустые строки;

Как это обрабатывается, зависит от реализации хоста. Если вы хотите, чтобы это изменилось, откройте проблему на хостах-нарушителях.

точно такая же проблема, что и if / else при выполнении в командной строке.

Ага. Это неоднозначно. Извините. Я не мог придумать, как заставить его работать надежно. Если бы мы выбрали OTBS вместо того, чтобы соответствовать стилю скобок C #, это не имело бы большого значения. Фактически, использование OTBS (например, DSL) имело бы множество преимуществ. Также обратите внимание: на исходном хосте консоли это «сработало», потому что после получения первого исключения IncompleteParse хост просто продолжал читать строки до тех пор, пока не достигнет пустой строки, а затем выполнил результат. Но это означает, что вам всегда приходилось нажимать лишнюю новую строку.

@Jaykul Так вы хотите противоположность директиве #light в F #? Что-то вроде #heavy, где пробелы неуместны, а точка с запятой обязательна?

Экранирование символов новой строки в PS, на мой взгляд, более проблематично, чем в большинстве языков. Эскейп-персонаж PS - это проклятая обратная кавычка . Подсветка синтаксиса по большей части не выделяет его - большинство схем выделения делают его довольно скучным.

Добавьте к этому тот факт, что когда вы возвращаетесь и редактируете что-то, заваленное обратными кавычками, вероятность того, что вы просто случайно пропустите один или два обратных кавычки, которые оказались неуместными среди правок, довольно высока.

Я бы использовал эту форму, если отслеживание ошибок обратных кавычек не было похоже на поиск иголки в стоге сена. Нет, я думаю, что было бы лучше разрешить формат вертикальной черты в начале как самостоятельный стиль, не требуя экранирования строки. : /

@ vexx32 Хотя я согласен с тем, что '' 'трудно увидеть,' | ' не является.

@Jaykul Так вы хотите противоположность директиве #light в F #? Что-то вроде #heavy, где пробелы неуместны, а точка с запятой обязательна?

Нет @BrucePay , я просто хочу еще один синтаксический трюк вроде этого:

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

что позволяет мне писать вещи _ аккуратно_ в сценариях, не беспокоясь о том, работает ли это, когда вы печатаете в консоли или нет.

@BrucePay правильно, и у меня есть код, использующий эти обратные кавычки, но мы ищем здесь возможность писать код без них по всем причинам, перечисленным @ vexx32 .

Совершенно справедливо отметить, что несколько существующих вариантов поведения в PowerShell, на которые полагаются люди, на самом деле являются результатом реализации хоста, поэтому спасибо за разъяснение этих вещей! С другой стороны, это также означает, что в языке есть вещи, которые уже нарушают эти ожидания, если реализация хоста не выполняет дополнительную работу для их обработки, верно?

@michaeltlombardi Плохая реализация хоста приведет к плохому взаимодействию, но не повлияет на сам язык. Тем не менее, интерактивность очень важна, поскольку большинство «скриптов» PowerShell набираются интерактивно.

мы ищем здесь возможность писать код без них

Я хочу сказать, что если вы поместите | в конец строки, продолжение будет неявным, и при запросе символа продолжения не потребуется. А символ | легко увидеть. И используйте отступы, чтобы структура кода была четко видна. В отличие от F # или Python, мы не применяем отступы, потому что PowerShell - это оболочка, и иногда вам нужно писать очень плотный код.

@Jaykul

не беспокоясь о том, работает ли он, когда вы набираете текст в консоли или нет.

Работа с консолью остается основным сценарием для нас и большинства наших клиентов. Однако у нас есть мета-функция для поддержки экспериментальных функций. Мы могли бы попробовать сделать то, что вы хотите, в качестве экспериментальной функции, а затем посмотреть, какие отзывы мы получим об общем опыте.

Я полностью понимаю, что консоль - это главное. Я просто хочу сказать, что это не должно сломать консоль, как вы предложили в своем _first_ комментарии.

Он должен вести себя в консоли _так же_, что и второй catch выше: вы можете ввести его только в консоли, где у вас есть многострочная ReadLine, такая как PSReadLine, и можно Shift+Enter чтобы ввести лишняя строка (или вы можете вставить ее) - ей вообще не нужно менять существующее поведение.

В конце концов, это функция, направленная на улучшение форматирования кода, а не на сокращение набора текста. Он должен работать в среде создания сценариев, а не в интерактивной консоли.

Но одно из обещаний, которые мы дали пользователю с самого начала, заключалось в том, что вы можете вставить скрипт (пример и т. Д.) В консоль и заставить его работать. Это даже включало вставку из документов word с emdash и т. Д. Копирование и вставка - безусловно, самая распространенная форма повторного использования (мы провели исследование, чтобы подтвердить это)

Верно. Но функция копирования и вставки в настоящее время работает только _ полностью_ только до тех пор, пока вы вставляете в PSReadLine Ctrl + V, а не с помощью щелчка правой кнопкой мыши - и это изменение будет работать и там. То есть для этого потребуется ReadLine с возможностью многострочной вставки, но она будет работать по умолчанию в PowerShell 5+.

Как я уже упоминал выше , существует довольно много случаев (if / else, try / catch, комментарии, фигурные скобки Allman и т. Д.), Когда это _ уже_ не тот случай, если у вас _ нет_ PSReadLine.

Я считаю, что еще один крайний случай в списке проблем с хостами, не относящимися к PSReadLine, не является достаточно серьезной причиной для исключения функции - в конце концов, этот синтаксис в любом случае не будет работать в PowerShell 4 или 5, поэтому он никогда не буду работать в ISE или хостах, не поддерживающих PSReadline. Меня _ немного сводит с ума_, что мы тратим столько усилий на обсуждение еще одной _more_ проблемы с вставкой в ​​{{not-our-problem}}, но нас устраивает тот факт, что это синтаксис, который не работает в более старых версиях версии PowerShell ...

PS Я использовал аргумент вставки как одно из оправданий для BestPractices, выбирая OTBS вместо Страуструпа или Оллмана , но сейчас я определенно собираюсь сослаться на эту ветку в книге 😁

Я действительно_ хотел бы, чтобы мы пошли с OTBS. DSL было бы намного проще.

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 принесло нам и всем нам, чтобы иметь возможность провести хорошее и открытое обсуждение с командой разработчиков продукта, MVP, доверенными членами сообщества и теми, кто плохо знаком с языком, подобным этому. фантастика. Процитирую ответ @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 позволяет именам команд начинаться с "-". В противном случае мы, вероятно, могли бы заключить параметры в символы новой строки без обратных кавычек. Конечно, у нас есть сплаттинг, но это может работать _с Intellisense и подсветкой синтаксиса_, если имена команд не могут совпадать с именами параметров:

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

Что касается многих жалоб - отсутствие обратных кавычек, вертикальная черта в начале строки для визуальной индикации непрерывности; никаких изменений в поведении интерактивной подсказки после ввода первой строки, потому что она может определить, следует ли ожидать продолжения строки; нет особой путаницы с зарезервированным оператором || потому что он разбит на несколько строк; набирает не больше, чем использовать обратную кавычку и вертикальную черту; не должно быть проблем со строкой комментария между ними, как в примерах if/else , try/catch Джайкула.

@HumanEquivalentUnit - я не могу сказать, что я поклонник этого предложения, потому что я, как автор сценария, могу решить, что я хочу удалить символы новой строки в сценарии для использования cmdline, и у меня останется неработающая и неинтуитивно понятная единственная строка это ИМО
выглядит ужасно

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

Который

@kilasuit, который отредактировал строку, выглядит странно (для меня не выглядит ужасным, просто странным), но действительно ли это отличается от кода с обратными кавычками, который действителен сейчас, если вы удалили строки, не удаляя продолжение строки? Страдаете ли вы сейчас от этой проблемы с кодом обратной кавычки?

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

Если вы спросите меня, это явная причина, по которой пиар Кирка приветствуется, если честно. Не требуя ни обратной петли, ни дополнительной трубы, это очень удобно при конденсационных трубопроводах.

Первоначальный запрос был выполнен.
Теперь обсудим https://github.com/PowerShell/PowerShell-RFC/pull/179