Powershell не работает shift

PowerShell и Shift+Ins, или как обрести скорость Гермеса при работе с GPP

Буфер обмена и PowerShell ускорят, но не ослепят.

Использовать GPP для добавления файлов реестра жутко и неудобно — все эти ветки реестра, тип ключа, значения… Особенно если веток и значений изрядно. Но есть пара лайфхаков, которые могут значительно ускорить работу с групповыми политиками.

Можно, конечно, повесить logon-скрипт с командой импорта ветки реестра. Но это же не наш метод.

Способ первый. Слегка сложный

Первым вариантом можно создать свой шаблон GPO. Такой способ особенно удобен, если нужно изменять параметры значений в зависимости от пользователя. Если не хочется изучать принципы формирования шаблонов, то можно просто экспортировать «правильный» reg-файл и конвертировать его в файл шаблона при помощи скрипта REG_2_ADMXL.vbs, опубликованного в галерее скриптов Technet.

Предположим, мы хотим облегчить жизнь пользователям, прикрутив к Internet Explorer несколько поисковых машин следующим образом:

• при вводе в адресной строке «g текст запроса» запрос искался бы в Google;
• «y текст запроса» — в Яндексе;
• а «w текст запроса» — в русской Википедии.

Для этого достаточно подготовить файл реестра:

Конвертируем его в шаблон следующей командой:

Получившийся шаблон и папку с языковым файлом закинем в каталог с шаблонами. Теперь наша политика появится в оснастке управления GPO.

Установленный шаблон.

Механизм не очень удобен в плане обслуживания, но в принципе работает. И не надо вручную ничего вбивать.

Другим вариантом будет использование командлетов PowerShell для работы с GPO. Например, для восстановления у пользователей пункта контекстного меню «Отправить» набор командлетов будет следующий:

Так выглядит вариант только для одного ключа. Если ключей много, то для удобства придется изобретать велосипед и опять же конвертировать файл реестра в набор командлетов PowerShell.

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

Способ второй. Копировать — Вставить (почти)

Как вы могли заметить (я так заметил очень не сразу), в оснастке управления групповыми политиками доступны действия над объектами, в том числе и стандартные операции буфера обмена.

Контекстное меню в параметрах реестра GPP.

Если скопировать объект в буфер обмена и вставить его, то окажется, что этот объект представляет собой файл в формате xml. Это значит, что файл можно предварительно сформировать и добавить в оснастку без заполнения полей вручную.

Для этого Malcolm McCaffery написал специальный скрипт. Он формирует файл xml на основе экспортированного файла реестра. Скрипт можно взять в блоге автора.

В скрипте у автора присутствуют лишние вызовы функции Convert-Reg2Xml и лишний блок параметров. Эти ошибки легко исправить при тестовом запуске через PowerShell ISE. Тем не менее я на всякий случай закинул исправленную версию на pastebin. Также существует и форк этого скрипта на github, и даже онлайн-сервис, который делает то же самое.

Использование скрипта предельно простое.

Получившийся xml можно даже просто перетащить в поле для параметров реестра.

Разберем конкретный пример. Для начала экспортируем «правильную» ветку реестра. В этом примере мы сделаем политику для включения отображения скрытых файлов, папок, расширений и заодно сделаем автозапуск ctfmon.exe для беспроблемной смены раскладки.

Файл реестра получился такой:

Преобразуем его в xml. Если посмотреть в получившийся файл, он уже будет таким:

Теперь можно просто вставить его в поле настройки параметров реестра. Получится такая красота:

Настроенная политика.

При должной сноровке процесс занимает меньше времени, чем чтение этого текста.

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

Достаточно будет создать новый тип действия для объектов типа regfile и прописать путь к нужному скрипту. Для вашего удобства я скомпоновал это, конечно же, в файл реестра:

Путь к скрипту задается в последней строке.

Чтобы скрипт отрабатывал такое, необходимо добавить в него следующие строки:

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

Новый пункт контекстного меню.

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

Источник

Win7: Cyrillic input with shift partially does not work #798

Comments

MVKozlov commented Nov 7, 2018 •

Environment data

Steps to reproduce or exception report

Installed latest PSReadline under PSv5.1 / Win7

switch keyboard to russian input, type:

• without shift — йцукенгшщзхъ
• should be (without shift but with caps) — ЙЦУКЕНГШЩЗХЪ
• with shift only — ЦУШЩХЪ
• with caps + shift — цукшщхъ

and many other symbols got eaten too

The text was updated successfully, but these errors were encountered:

MVKozlov commented Nov 7, 2018

MVKozlov commented Nov 7, 2018

Something breaks between beta1 and beta2

lzybkr commented Nov 7, 2018

Are you changing the layout after starting PowerShell? If so, this might be hard to fix, the api I rely on the determine if Shift is necessary does not honor keyboard layout changes.

MVKozlov commented Nov 7, 2018 •

Yes, I start PS and press shortcut to change layout. The same version (Beta3) works ok on Linux but does not work on Windows (both 7 and 10)

Moreover, if I change default layout to Russian, (I start PSs with RUS layout) I can’t get any russian upper case symbols with shift (at least qwerty line) and even when I switch to English I can’t type any English symbols with shift as well!

Seems there should be another PlatformWindows.cs override

ForNeVeR commented Dec 1, 2018 •

The impact of this issue is very high, because multi-layout users switch their layouts literally all the time. I have some file names and content I want to enter into my PowerShell session in my native layout, and so I need to change my layout from time to time without restarting the whole PowerShell session, that’s a disaster.

@lzybkr, how could we help you with the issue? Could you please share any thoughts on that or show where I could find the code of that problematic API and PSReadLine’s usage of that API? I’ll be glad to help with the fix.

Источник

Исправление проблемы ввода заглавных букв в Powershell

Столкнулся с интересной проблемой. В Powershell, не вводятся заглавные буквы. Делюсь своими изысканиями как решить эту проблему.

После недолгого поиска решения проблемы, стало понятно, что всё дело в модуле PSReadLine, который в основном нужен для синтаксической раскраски, но ещё много чего делает.

Подробную информацию о модуле можно найти на сайте проекта, на Github, по адресу https://github.com/PowerShell/PSReadLine. Ошибка, о которой я говорю, описана там же, в issue 798.

Дело в том, что какое-то время, в поставку Windows входила версия 2.0.0, которая появилась 6.12.2017 в статусе BETA. Она и содержала эту ошибку. 7.11.2018 разработчик с ником MVKozlov сообщил о проблеме и уже 26.11.2018 ошибка была устранена. К тому времени проект успел получить статус beta3. А уже в мае 2019 года проект получил статус beta4 и не содержал данной ошибки.

Воспроизвести проблему можно следующим образом. Нужно переключиться на русскую раскладку клавиатуры и запустить Powershell. Если у Вас установлена версия модуля 2.0.0.beta1, beta2 или beta3, то вы не сможете в консоли Powershell набрать заглавные буквы. Проблема была решена 3 декабря 2018 года и всё решение сводится к тому, чтобы переустановить модуль. Делается это просто.

Затем удаляем папку C:\Program Files\WindowsPowerShell\Modules\PSReadLine и устанавливаем модуль ещё раз.

Текущая стабильная версия модуля 1.2, она и будет установлена по умолчанию. С сайта проекта вы можете поставить майскую версию v2.0.0-beta4, но, насколько я понимаю, она далека от релиза. Там ещё требуется много доработок. На сегодняшний день по версии 2.0.0.beta4 заявлено 60 багов и 9 из них всё ещё открыты.

Источник

Powershell не работает shift

Вопрос

Описание ошибки

В Windows 10 версии 1809 в Powershell не вводятся русские заглавные символы

Как воспроизвести

1. Потребуется Windows 10 1809, в частности Windows 10 x64 Version 1809 (OS Build 17763.253)
2. Открыть командную строку Powershell, в Powershell ISE проблема не воспроизводится.
3. Пробовать вписать русские заглавные буквы используя Shift.
4. Итог не все символы пропечатываются (только некоторые проходят — ЦУШЩХЪФЫСТ).
5. А если использовать вместо Shift клавишу Caps Lock то все нормально.
6. Ну это ладно бы, можно привыкнуть и Caps Lock использовать. Так еще и Copy/Paste русских букв также иногда отрезает заглавные буквы.

Что пробовали

• Пробовали менять шрифт в консоли и перезапускать консоль.
• Менять кодировку в консоли командой:
  [Console]::OutputEncoding = [ System .Text. Encoding ]::GetEncoding(«utf-8»)
• Менять порядок языков ввода [EN-US] [RU-RU]
• Изменять настройки консоли Powershell, такие как «Use legacy console», «Filter clipboard contents on paste», «Discard Old Duplicates» и прочие.

Вопрос

Как решить данныую проблему, чтобы без проблем можно было в консоли Powershell набирать заглавные русские буквы с использованием Shift?

Источник

Терминал шрифта PowerShell не работает после обновления Windows 10 Creators

Для тех, кто не знает, Microsoft выпустила серьезное обновление для Windows 10, и одно из изменений заключается в том, что PowerShell заменяет cmd.exe по умолчанию. Например, когда вы открываете меню Win + X, вы видите ссылки PowerShell и больше не получаете командную строку.

Во всяком случае, при запуске PowerShell я получаю это сейчас:

Этого не было до обновления.

РЕДАКТИРОВАТЬ: изменение шрифта помогает, но не решает проблему для приложений, которые не имеют функции для изменения шрифта. Неработающий шрифт — Терминал. Замена его из другого источника / переустановка или сброс шрифтов по умолчанию на панели управления не решает проблему.

Например, открытие новой свежей копии шрифтов Terminal на рабочем столе по-прежнему не отображает их, а показывает иероглифы. Таким образом, это как не сам шрифт сломан, а что-то в Windows, что не делает шрифт?

Также вы не можете переустановить .net Framework 4.7 на Win10, нет деинсталлятора, он поставляется с Windows, все, что вы можете, это удалить директории, поставить галочку / убрать галочку в программах и функциях, возможно, запустить утилиту очистки, но не решает проблему со шрифтами ,

Microsoft исправила это для Creators Update 1703 с обновлением KB4020102 (сборка ОС 15063.332) .

Устранена проблема, из-за которой некоторые шрифты, отличные от Unicode (Courier, MS Sans Serif и т. Д.), Неправильно отображают символы в нелатинских, однобайтовых системных локалях (греческий, иврит, арабский и т. Д.). Вместо этого появляются черные полосы или другие артефакты.

Поэтому откройте Центр обновления Windows и установите обновление, чтобы устранить проблему.

Проблема не так страшна, как кажется. Это похоже на проблему со шрифтом, которую можно исправить, изменив шрифт.

Для этого сделайте следующее.

Нажмите верхний левый значок в окне Powershell (значок powershell) и выберите свойства.

Перейдите на вкладку « Шрифт» и измените ее на что-нибудь другое, например, Ludica Console.

Нажмите ОК Проблема должна быть исправлена.

Источник