When we run a command and we get the correct output, but it is preceded by the output of another command, somehow this unexpected command is run before our intended command.
The usual suspect is a batch file created with the same name that the command we are calling, but in this case, being time an internal command, this can not be the case, internal commands have precedence over external commands (default behaviour).
If time is an internal command, how can another command being called?
When for /f needs to process the output of a command a separate cmd instance is created to execute that command. The output generated in this separate instance is processed by the code in the do clause of the for /f command.
The creation of this separate instance can be the source of the unexpected output.
Reading the help information shown by cmd /? we can see that there are two registry keys
HKEY_LOCAL_MACHINESoftwareMicrosoftCommand ProcessorAutoRun
HKEY_CURRENT_USERSoftwareMicrosoftCommand ProcessorAutoRun
that can be configured to run commands every time a new cmd instance is created (unless the /D switch is used when starting the cmd instance).
This is the most probable place where to find why you get the Active code page: 65001 output.
Утилиты GDAL/OGR и кириллица в именах файлов и путей Windows. Рецепт использования кодировки UTF-8.
Содержание
- 1 Вступление:
- 1.1 Утилиты GDAL/OGR краткие сведения:
- 1.2 Утилиты GDAL/OGR не «любят» русские буквы в именах файлов Windows:
- 2 Решение проблемы. Костыль №1
- 2.1 Вывод:
- 2.2 Технические детали:
- 2.3 И все бы было хорошо, если бы не … :
- 2.3.1 Общая неудовлетворенность запретом UTF-8:
- 2.3.2 Проблемы со скриптами на языке Python:
- 3 Решение проблемы. Костыль №2 (надпиленный)
- 3.1 Описание решаемой задачи
- 3.2 Костыль №2 (надпиленный)
- 4 Решение проблемы. Костыль №3
- 4.1 Анализ
- 4.2 Решение получено, но … . Опять «но»
- 4.3 Продолжаем исследование
- 4.4 Вывод
- 4.5 Решение
- 4.6 Примеры:
- 5 Итог
[править] Вступление:
[править] Утилиты GDAL/OGR краткие сведения:
GDAL/OGR — это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [1] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице Software Using GDAL очень достойный (хотя и не очень дешевый 
) российский продукт SCANEX IMAGE PROCESSOR®, так же использует библиотеки GDAL/OGR.
Кроме самих библиотек GDAL и OGR в инсталяционном пакете присутствует набор уже созданных утилит GDAL/OGR, запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.
О GDAL/OGR можно узнать на форуме в разделе Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR. Один из вариантов установки дан в этой статье. Мне известно, что утилиты командной строки так же входят состав ГИС NextGIS QGIS.
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами «ГИС». Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых «убивают» многие графические редакторы и ГИС-программы.
[править] Утилиты GDAL/OGR не «любят» русские буквы в именах файлов Windows:
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень «кусачие» минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет «кросс-платформенные» библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не «любят» русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки ACSII, заканчивались как то так:
F:21>gdalinfo результат.tif
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system, and is not recognised as a supported dataset name. gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
F:21>chcp 1251 F:21>gdalinfo результат.tif
ERROR 4: `результат.tif' does not exist in the file system, and is not recognised as a supported dataset name. gdalinfo failed - unable to open 'результат.tif'.
В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке CP1251, которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.
[править] Решение проблемы. Костыль №1
Тема обсуждалась на нашем форуме и закончилась диагнозом. Расширенная версии обсуждения русских букв: GDAL и русские буквы в именах файлов Windows.
[править] Вывод:
Установите переменную окружения GDAL_FILENAME_IS_UTF8 в значение NO, и при работе в пределах одной кодовой страницы — будет вам счастье:
set GDAL_FILENAME_IS_UTF8=NO
[править] Технические детали:
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет «неправедной» жизнью с вредными кодировками (во вредных ОС), в то время как «прогрессивное человечество» использует кодировку UTF-8, которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения GDAL_FILENAME_IS_UTF8 не установлена или имеет значение YES.
Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке UTF-16, но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( командный процессор cmd) служит команда CHCP. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой CHCP 65001. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.
Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.
[править] И все бы было хорошо, если бы не … :
[править] Общая неудовлетворенность запретом UTF-8:
Ну в самом деле, у всех (видимо англоязычных) есть, а нам — нельзя. А вдруг к русскому языку захочется еще немецких умляутов или другой какой UNICODE экзотики, а тут нельзя — оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.
[править] Проблемы со скриптами на языке Python:
Если предыдущий абзац — это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ‘gdal_merge.bat из настроенной казалось системы:
C:OSGeo4W64bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO
C:OSGeo4W64bin>al_merge.bat -o "F:21результат.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.tif"
ERROR 4: `F:20 x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.
ERROR 4: `F:20 x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.
Traceback (most recent call last):
File "C:OSGEO4~1bingdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:OSGEO4~1bingdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
огорчает. И «танцы с бубном»: как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы 65001 и переменной окружения GDAL_FILENAME_IS_UTF8=YES результата не дают:
@setlocal chcp 65001 Set GDAL_FILENAME_IS_UTF8=YES @python "%OSGEO4W_ROOT%bingdal_merge.py" %* @endlocal
Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).
[править] Решение проблемы. Костыль №2 (надпиленный)
Как видно выше, на самом деле BAT-файл gdal_merge.bat — это всего навсего обертка на python-скриптом gdal_merge.py. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед — все заработает как было задумано. Хоть с GDAL_FILENAME_IS_UTF8=YES, хоть GDAL_FILENAME_IS_UTF8=NO.
Очевидное решение для этого — скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.
Еще более очевидный вариант переименовать файл на время работы с ним, а потом восстановить исходное имя.
Не очевидный вариант — переместить файл в пределах одного диска, так что бы ни в имени, ни в пути к каталогу, где лежит файл не было русских букв. Потому как русские буквы в имени каталога то же бывают, а переименовывать весь каталог это совсем неудобно.
[править] Описание решаемой задачи
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
- Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
- Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
- Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
- В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что «русская буква есть принятый стандарт, от которого отойти — нельзя».
- После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра — не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
- Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний …кад много мелких файлов (по 200 МБ) не понимает.
Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python’е. Тут работа крепко встала. Пока не было найдено решение с переименованием.
[править] Костыль №2 (надпиленный)
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите gdal_merge, переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался «надпиленный» и навернуться, опираясь на него, можно очень больно.
Вариант с копированием конечно был более безопасным, но гонять туда-сюда 60 ГБ промежуточных файлов, вышло по времени столько же, сколько работали сами программы.
Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.
[править] Решение проблемы. Костыль №3
[править] Анализ
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта dal_merge.py, как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция
gdal.Open( filename )
была готова открывать файлы в системной кодировке CP1251, если GDAL_FILENAME_IS_UTF8=NO, или в кодировке UFT-8, если GDAL_FILENAME_IS_UTF8=YES. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.
Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
Не зависимо от настроек функция gdal.GeneralCmdLineProcessor считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.
Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной GDAL_FILENAME_IS_UTF8:
- GDAL_FILENAME_IS_UTF8=NO — кодовая страница должна быть CP1251;
- GDAL_FILENAME_IS_UTF8=YES — кодовая страница должна быть UTF-8;
[править] Решение получено, но … . Опять «но»
Решение получено — надо закомментировать строку с gdal.GeneralCmdLineProcessor. Но тут есть пара «но»:
- ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо «извести» — это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
- gdal.GeneralCmdLineProcessor — что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.
[править] Продолжаем исследование
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи gdal.GeneralCmdLineProcessor и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
--optfile filename: expand an option file into the argument list.
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.
[править] Вывод
И этот параметр позволяет поместить в файл параметры в полностью контролируемой кодировке, а потом программе считать их без искажений на стыке «операционная система» — «оболочка командной строки» — «прикладаня программа»/»прикладная среда».
[править] Решение
Оно показалось очевидным:
- устанавливаем кодировку «приятную» нам и «оболочке командной строки». я выбрал UTF-8 или CP65001 ( космополитизм, однако …);
- сохраняем параметры программы, получаемые из командной строки в выбранный файл в выбранной кодировке;
- считываем это файл через параметр —optfile filename
- и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.
В результате получился для gdal_merge.py вот такой BAT-Файл gdal_mergeF.bat
@setlocal @echo off @chcp 65001 Set GDAL_FILENAME_IS_UTF8=YES set ARGV=%* if "%1"=="" @python "%OSGEO4W_ROOT%bingdal_merge.py" if "%1"=="" goto iExit if "%2"=="" @python "%OSGEO4W_ROOT%bingdal_merge.py" %~1 if "%2"=="" goto iExit set iTmp=%tmp%%RANDOM%_%~n0_%RANDOM%.tmp @rem echo %iTmp% @echo %ARGV%>"%iTmp%" @python "%OSGEO4W_ROOT%bingdal_merge.py" --optfile "%iTmp%" :iExit @endlocal
Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для ogrinfo.exe получился вот такой BAT-Файл ogrinfoF.bat
@setlocal @echo off @chcp 65001 Set GDAL_FILENAME_IS_UTF8=YES set ARGV=%* if "%1"=="" @ogrinfo if "%1"=="" goto iExit set iTmp=%tmp%%RANDOM%_%~n0_%RANDOM%.tmp @rem echo %iTmp% @echo %ARGV%>"%iTmp%" set iTmp=%tmp%%RANDOM%_%~n0_%RANDOM%.tmp ogrinfo --optfile "%iTmp%" :iExit @endlocal
Для стандартных программ-скриптов на Python в комплекте OSGeo4W используются оболочки в виде BAT-файлов с аналогичным именем. Стандартно они создаются (перезаписываются) командным файлом «make-bat-for-py.bat», который запускается в конце инсталляции. Стандартный «make-bat-for-py.bat» состоит только из одной строки, вызывающей программу python.exe для скрипта с аналогичным именем.
Поскольку при таком вызове невозможно использование файлов с кириллическими символами, в файл оболочку необходимо добавить строки, обеспечивающие дополнительные настройки, призванные обеспечить корректную передачу имен файлов. Для это предлагается замена стандартного»make-bat-for-py.bat» на файл, приводимый ниже, с последующим запуском этого файла, что вызовет массовую замену BAT-файлов, оболочек для скриптов python, в каталоге «%OSGEO4W_ROOT%bin»:
@echo on echo. echo. Generating .bat files for all .py files in %OSGEO4W_ROOT%bin echo. pushd "%OSGEO4W_ROOT%bin" for %%g in (*.py) do ( echo @setlocal 1> %%~ng.bat echo @echo off 1>> %%~ng.bat echo @chcp 65001 1>> %%~ng.bat echo Set GDAL_FILENAME_IS_UTF8=YES 1>> %%~ng.bat echo set ARGV=%%* 1>> %%~ng.bat echo if "%%1"=="" goto iExit 1>> %%~ng.bat echo set iTmp=%%tmp%%%%RANDOM%%_%%~n0_%%RANDOM%%.tmp 1>> %%~ng.bat echo @rem echo %%iTmp%% 1>> %%~ng.bat echo @echo %%ARGV%%^>"%%iTmp%%" 1>> %%~ng.bat echo @python "%%OSGEO4W_ROOT%%bin%%g" --optfile "%%iTmp%%" 1>> %%~ng.bat echo @endlocal 1>> %%~ng.bat echo exist /b echo :iExit 1>> %%~ng.bat echo @python "%%OSGEO4W_ROOT%%bin%%g" %%* >> %%~ng.bat echo @python "%%OSGEO4W_ROOT%%bin%%g" --optfile "%%iTmp%%" echo @endlocal 1>> %%~ng.bat echo exist /b ) popd
[править] Примеры:
Приведенный выше BAT файлы сработали одинаково и в случае верных данных,
- ==== EXE-файл ====
F:21>ogrinfoF.bat "f:20 набор тестовых файловtsp.TAB"
Active code page: 65001
Had to open data source read-only.
INFO: Open of `f:20 набор тестовых файловtsp.TAB'
using driver `MapInfo File' successful.
1: tsp (Point)
- ==== Py-скрипт ====
F:21>gdal_mergeF.bat -o "результат.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.tif"
Active code page: 65001 0...10...20...30...40...50...60...70...80...90...100 - done.
и в случае, когда входные данные породили сообщение об ошибке:
- ==== EXE-файл ====
F:21>ogrinfoF.bat "f:20 набор тестовых файловtsp.T__"
Active code page: 65001 FAILURE: Unable to open datasource `f:20 набор тестовых файловtsp.T__' with the following drivers. -> FileGDB -> ESRI Shapefile ...
- === Py-скрипт ===
F:21>gdal_mergeF.bat -o "результат.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.t__" "F:20 набор тестовых файловx2_9140_N-37-28-Г.t__"
Active code page: 65001
ERROR 4: `F:20 набор тестовых файловx2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.
ERROR 4: `F:20 набор тестовых файловx2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.
Traceback (most recent call last):
File "C:OSGEO4~1bingdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:OSGEO4~1bingdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
[править] Итог
Решение найдено. Но т.к. костыли не заменяют ног, то кроме неудобства связанно с необходимостью для всех утилит создать Bat-Файлы со специальными настройками, и помнить внесенные изменения на случай выхода новой версии утилит или библиотеки в целом, при таком подходе мы лишились возможности в ряде случаев использовать команды, начинающиеся с двойного тире «—«, описанные в [Gdal-dev] GDAL General Command Line Processor, т.к. эти опции несовместны с опцией —optfile filename .
- Remove From My Forums
-
Question
-
Добрый день, с нуля поставили Windows Server 2012 R2 Eng. Добавили русские региональные настройки, добавили русский язык, отображение
программ нормальное, но возникли проблемы с русской кодировкой в CMD. При этом Язык программ, не поддерживающих Юникод» стоит Русский. Проблема заключается вот в чем:
Если пишешь команду например через CMD -то все хорошо, русские символи в пути воспринимает нормально.
Если создаешь батник в текстовом редакторе (например Notepad) то при открытии файла все читаемо, а при выполнении кодировка
«Съезжает».
Если создавать батник через CMD ( с помощью copy con) — то полученный файл выполняется нормально, но при редактировании идет
сбой кодировки.
Также, если создавать батник на сервере, где таких проблем нет, то при выполнении опять-же ошибка из-за кодировки… Где копать? и
как решить?
При этом с PS проблем с указание пути на русском языком языке нет.
Утилиты GDAL/OGR и кириллица в именах файлов и путей Windows. Рецепт использования кодировки UTF-8.
Содержание
- 1 Вступление:
- 1.1 Утилиты GDAL/OGR краткие сведения:
- 1.2 Утилиты GDAL/OGR не «любят» русские буквы в именах файлов Windows:
- 2 Решение проблемы. Костыль №1
- 2.1 Вывод:
- 2.2 Технические детали:
- 2.3 И все бы было хорошо, если бы не … :
- 2.3.1 Общая неудовлетворенность запретом UTF-8:
- 2.3.2 Проблемы со скриптами на языке Python:
- 3 Решение проблемы. Костыль №2 (надпиленный)
- 3.1 Описание решаемой задачи
- 3.2 Костыль №2 (надпиленный)
- 4 Решение проблемы. Костыль №3
- 4.1 Анализ
- 4.2 Решение получено, но … . Опять «но»
- 4.3 Продолжаем исследование
- 4.4 Вывод
- 4.5 Решение
- 4.6 Примеры:
- 5 Итог
[править] Вступление:
[править] Утилиты GDAL/OGR краткие сведения:
GDAL/OGR — это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [1] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице Software Using GDAL очень достойный (хотя и не очень дешевый ) российский продукт SCANEX IMAGE PROCESSOR®, так же использует библиотеки GDAL/OGR.
Кроме самих библиотек GDAL и OGR в инсталяционном пакете присутствует набор уже созданных утилит GDAL/OGR, запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.
О GDAL/OGR можно узнать на форуме в разделе Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR. Один из вариантов установки дан в этой статье. Мне известно, что утилиты командной строки так же входят состав ГИС NextGIS QGIS.
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами «ГИС». Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых «убивают» многие графические редакторы и ГИС-программы.
[править] Утилиты GDAL/OGR не «любят» русские буквы в именах файлов Windows:
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень «кусачие» минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет «кросс-платформенные» библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не «любят» русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки ACSII, заканчивались как то так:
F:21>gdalinfo результат.tif
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system, and is not recognised as a supported dataset name. gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
F:21>chcp 1251 F:21>gdalinfo результат.tif
ERROR 4: `результат.tif' does not exist in the file system, and is not recognised as a supported dataset name. gdalinfo failed - unable to open 'результат.tif'.
В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке CP1251, которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.
[править] Решение проблемы. Костыль №1
Тема обсуждалась на нашем форуме и закончилась диагнозом. Расширенная версии обсуждения русских букв: GDAL и русские буквы в именах файлов Windows.
[править] Вывод:
Установите переменную окружения GDAL_FILENAME_IS_UTF8 в значение NO, и при работе в пределах одной кодовой страницы — будет вам счастье:
set GDAL_FILENAME_IS_UTF8=NO
[править] Технические детали:
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет «неправедной» жизнью с вредными кодировками (во вредных ОС), в то время как «прогрессивное человечество» использует кодировку UTF-8, которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения GDAL_FILENAME_IS_UTF8 не установлена или имеет значение YES.
Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке UTF-16, но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( командный процессор cmd) служит команда CHCP. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой CHCP 65001. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.
Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.
[править] И все бы было хорошо, если бы не … :
[править] Общая неудовлетворенность запретом UTF-8:
Ну в самом деле, у всех (видимо англоязычных) есть, а нам — нельзя. А вдруг к русскому языку захочется еще немецких умляутов или другой какой UNICODE экзотики, а тут нельзя — оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.
[править] Проблемы со скриптами на языке Python:
Если предыдущий абзац — это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ‘gdal_merge.bat из настроенной казалось системы:
C:OSGeo4W64bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO
C:OSGeo4W64bin>al_merge.bat -o "F:21результат.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.tif"
ERROR 4: `F:20 x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.
ERROR 4: `F:20 x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.
Traceback (most recent call last):
File "C:OSGEO4~1bingdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:OSGEO4~1bingdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
огорчает. И «танцы с бубном»: как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы 65001 и переменной окружения GDAL_FILENAME_IS_UTF8=YES результата не дают:
@setlocal chcp 65001 Set GDAL_FILENAME_IS_UTF8=YES @python "%OSGEO4W_ROOT%bingdal_merge.py" %* @endlocal
Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).
[править] Решение проблемы. Костыль №2 (надпиленный)
Как видно выше, на самом деле BAT-файл gdal_merge.bat — это всего навсего обертка на python-скриптом gdal_merge.py. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед — все заработает как было задумано. Хоть с GDAL_FILENAME_IS_UTF8=YES, хоть GDAL_FILENAME_IS_UTF8=NO.
Очевидное решение для этого — скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.
Еще более очевидный вариант переименовать файл на время работы с ним, а потом восстановить исходное имя.
Не очевидный вариант — переместить файл в пределах одного диска, так что бы ни в имени, ни в пути к каталогу, где лежит файл не было русских букв. Потому как русские буквы в имени каталога то же бывают, а переименовывать весь каталог это совсем неудобно.
[править] Описание решаемой задачи
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
- Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
- Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
- Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
- В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что «русская буква есть принятый стандарт, от которого отойти — нельзя».
- После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра — не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
- Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний …кад много мелких файлов (по 200 МБ) не понимает.
Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python’е. Тут работа крепко встала. Пока не было найдено решение с переименованием.
[править] Костыль №2 (надпиленный)
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите gdal_merge, переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался «надпиленный» и навернуться, опираясь на него, можно очень больно.
Вариант с копированием конечно был более безопасным, но гонять туда-сюда 60 ГБ промежуточных файлов, вышло по времени столько же, сколько работали сами программы.
Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.
[править] Решение проблемы. Костыль №3
[править] Анализ
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта dal_merge.py, как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция
gdal.Open( filename )
была готова открывать файлы в системной кодировке CP1251, если GDAL_FILENAME_IS_UTF8=NO, или в кодировке UFT-8, если GDAL_FILENAME_IS_UTF8=YES. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.
Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
Не зависимо от настроек функция gdal.GeneralCmdLineProcessor считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.
Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной GDAL_FILENAME_IS_UTF8:
- GDAL_FILENAME_IS_UTF8=NO — кодовая страница должна быть CP1251;
- GDAL_FILENAME_IS_UTF8=YES — кодовая страница должна быть UTF-8;
[править] Решение получено, но … . Опять «но»
Решение получено — надо закомментировать строку с gdal.GeneralCmdLineProcessor. Но тут есть пара «но»:
- ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо «извести» — это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
- gdal.GeneralCmdLineProcessor — что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.
[править] Продолжаем исследование
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи gdal.GeneralCmdLineProcessor и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
--optfile filename: expand an option file into the argument list.
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.
[править] Вывод
И этот параметр позволяет поместить в файл параметры в полностью контролируемой кодировке, а потом программе считать их без искажений на стыке «операционная система» — «оболочка командной строки» — «прикладаня программа»/»прикладная среда».
[править] Решение
Оно показалось очевидным:
- устанавливаем кодировку «приятную» нам и «оболочке командной строки». я выбрал UTF-8 или CP65001 ( космополитизм, однако …);
- сохраняем параметры программы, получаемые из командной строки в выбранный файл в выбранной кодировке;
- считываем это файл через параметр —optfile filename
- и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.
В результате получился для gdal_merge.py вот такой BAT-Файл gdal_mergeF.bat
@setlocal @echo off @chcp 65001 Set GDAL_FILENAME_IS_UTF8=YES set ARGV=%* if "%1"=="" @python "%OSGEO4W_ROOT%bingdal_merge.py" if "%1"=="" goto iExit if "%2"=="" @python "%OSGEO4W_ROOT%bingdal_merge.py" %~1 if "%2"=="" goto iExit set iTmp=%tmp%%RANDOM%_%~n0_%RANDOM%.tmp @rem echo %iTmp% @echo %ARGV%>"%iTmp%" @python "%OSGEO4W_ROOT%bingdal_merge.py" --optfile "%iTmp%" :iExit @endlocal
Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для ogrinfo.exe получился вот такой BAT-Файл ogrinfoF.bat
@setlocal @echo off @chcp 65001 Set GDAL_FILENAME_IS_UTF8=YES set ARGV=%* if "%1"=="" @ogrinfo if "%1"=="" goto iExit set iTmp=%tmp%%RANDOM%_%~n0_%RANDOM%.tmp @rem echo %iTmp% @echo %ARGV%>"%iTmp%" set iTmp=%tmp%%RANDOM%_%~n0_%RANDOM%.tmp ogrinfo --optfile "%iTmp%" :iExit @endlocal
Для стандартных программ-скриптов на Python в комплекте OSGeo4W используются оболочки в виде BAT-файлов с аналогичным именем. Стандартно они создаются (перезаписываются) командным файлом «make-bat-for-py.bat», который запускается в конце инсталляции. Стандартный «make-bat-for-py.bat» состоит только из одной строки, вызывающей программу python.exe для скрипта с аналогичным именем.
Поскольку при таком вызове невозможно использование файлов с кириллическими символами, в файл оболочку необходимо добавить строки, обеспечивающие дополнительные настройки, призванные обеспечить корректную передачу имен файлов. Для это предлагается замена стандартного»make-bat-for-py.bat» на файл, приводимый ниже, с последующим запуском этого файла, что вызовет массовую замену BAT-файлов, оболочек для скриптов python, в каталоге «%OSGEO4W_ROOT%bin»:
@echo on echo. echo. Generating .bat files for all .py files in %OSGEO4W_ROOT%bin echo. pushd "%OSGEO4W_ROOT%bin" for %%g in (*.py) do ( echo @setlocal 1> %%~ng.bat echo @echo off 1>> %%~ng.bat echo @chcp 65001 1>> %%~ng.bat echo Set GDAL_FILENAME_IS_UTF8=YES 1>> %%~ng.bat echo set ARGV=%%* 1>> %%~ng.bat echo if "%%1"=="" goto iExit 1>> %%~ng.bat echo set iTmp=%%tmp%%%%RANDOM%%_%%~n0_%%RANDOM%%.tmp 1>> %%~ng.bat echo @rem echo %%iTmp%% 1>> %%~ng.bat echo @echo %%ARGV%%^>"%%iTmp%%" 1>> %%~ng.bat echo @python "%%OSGEO4W_ROOT%%bin%%g" --optfile "%%iTmp%%" 1>> %%~ng.bat echo @endlocal 1>> %%~ng.bat echo exist /b echo :iExit 1>> %%~ng.bat echo @python "%%OSGEO4W_ROOT%%bin%%g" %%* >> %%~ng.bat echo @python "%%OSGEO4W_ROOT%%bin%%g" --optfile "%%iTmp%%" echo @endlocal 1>> %%~ng.bat echo exist /b ) popd
[править] Примеры:
Приведенный выше BAT файлы сработали одинаково и в случае верных данных,
- ==== EXE-файл ====
F:21>ogrinfoF.bat "f:20 набор тестовых файловtsp.TAB"
Active code page: 65001
Had to open data source read-only.
INFO: Open of `f:20 набор тестовых файловtsp.TAB'
using driver `MapInfo File' successful.
1: tsp (Point)
- ==== Py-скрипт ====
F:21>gdal_mergeF.bat -o "результат.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.tif"
Active code page: 65001 0...10...20...30...40...50...60...70...80...90...100 - done.
и в случае, когда входные данные породили сообщение об ошибке:
- ==== EXE-файл ====
F:21>ogrinfoF.bat "f:20 набор тестовых файловtsp.T__"
Active code page: 65001 FAILURE: Unable to open datasource `f:20 набор тестовых файловtsp.T__' with the following drivers. -> FileGDB -> ESRI Shapefile ...
- === Py-скрипт ===
F:21>gdal_mergeF.bat -o "результат.tif" "F:20 набор тестовых файловx2_9140_N-37-28-Г.t__" "F:20 набор тестовых файловx2_9140_N-37-28-Г.t__"
Active code page: 65001
ERROR 4: `F:20 набор тестовых файловx2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.
ERROR 4: `F:20 набор тестовых файловx2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.
Traceback (most recent call last):
File "C:OSGEO4~1bingdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:OSGEO4~1bingdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
[править] Итог
Решение найдено. Но т.к. костыли не заменяют ног, то кроме неудобства связанно с необходимостью для всех утилит создать Bat-Файлы со специальными настройками, и помнить внесенные изменения на случай выхода новой версии утилит или библиотеки в целом, при таком подходе мы лишились возможности в ряде случаев использовать команды, начинающиеся с двойного тире «—«, описанные в [Gdal-dev] GDAL General Command Line Processor, т.к. эти опции несовместны с опцией —optfile filename .
Comments
docker-compose raise an error under PowerShell or cmd with code page 65001(UTF-8):
PS> chcp
Active code page: 65001
PS> docker-compose --version
Traceback (most recent call last):
File "<string>", line 3, in <module>
File "C:projectscomposecomposeclimain.py", line 54, in main
File "C:projectscomposecomposeclidocopt_command.py", line 23, in sys_dispatch
File "C:projectscomposecomposeclidocopt_command.py", line 26, in dispatch
File "C:projectscomposecomposeclidocopt_command.py", line 29, in parse
File "C:projectscomposecomposeclidocopt_command.py", line 13, in docopt_full_help
File "c:projectscomposevenvlibsite-packagesdocopt.py", line 575, in docopt
File "c:projectscomposevenvlibsite-packagesdocopt.py", line 484, in extras
LookupError: unknown encoding: cp65001
docker-compose returned -1
$Env:PYTHONIOENCODING = 'utf-8' is no effect.
It works fine with cp932(Shift-JIS, Japanese default code page):
PS> chcp 932
現在のコード ページ: 932
PS> docker-compose --version
docker-compose version 1.6.0rc2, build a7636be
I’m guessing the python we use to build the binary doesn’t have this encoding installed. Is it a common encoding? Why isn’t it utf-8 ?
I ran into a variant of this, with chcp showing codepage 437 but python detecting cp65001 somehow. docker-compose works in another shell window, so I guess this is somehow environment-specific.
$ chcp
Active code page: 437
wx-sample feature/VSP-1582-selenium-tests-to-docker* $ docker-compose --version
Traceback (most recent call last):
File "<string>", line 3, in <module>
File "C:projectscomposecomposeclimain.py", line 54, in main
File "C:projectscomposecomposeclidocopt_command.py", line 23, in sys_dispatch
File "C:projectscomposecomposeclidocopt_command.py", line 26, in dispatch
File "C:projectscomposecomposeclidocopt_command.py", line 29, in parse
File "C:projectscomposecomposeclidocopt_command.py", line 13, in docopt_full_help
File "c:projectscomposevenvlibsite-packagesdocopt.py", line 575, in docopt
File "c:projectscomposevenvlibsite-packagesdocopt.py", line 484, in extras
LookupError: unknown encoding: cp65001
docker-compose returned -1
I’m using Cmder (Conemu mod) which sets cp65001 by default in the environment variables.
Is there a workaround here we can use for now? What are the implications of changing it?
use powershell
PS C:Usersinsekticid> docker-compose —version
docker-compose version 1.8.0, build d988a55
The same error in PS too.
PS C:UsersRoma> docker-compose --version
Traceback (most recent call last):
File "<string>", line 3, in <module>
File "composeclimain.py", line 58, in main
File "composeclimain.py", line 89, in dispatch
File "composeclidocopt_command.py", line 25, in parse
File "composeclidocopt_command.py", line 12, in docopt_full_help
File "site-packagesdocopt.py", line 575, in docopt
File "site-packagesdocopt.py", line 484, in extras
LookupError: unknown encoding: cp65001
docker-compose returned -1
But runs under Cygwin:
Roma@roma-desktop /cygdrive/c/Users/Roma
$ docker-compose --version
docker-compose version 1.8.0, build d988a55
As a workaround, it works with ConsoleZ.
I was able to fix it by adding this line to my Powershell profile: source forum post
[Console]::OutputEncoding = [System.Text.Encoding]::Default
If using ConEmu, I found removing chcp utf-8 from Startup > Environment seemed to do the trick for removing the warning, and doesn’t appear to be messing with any unicode characters.
This issue is not happening on Python 3.5 so it may be a good reason to start bundling this with Py3 instead of Py2?
I also get these errors when executing docker tools from FAKE build scripts.
I found in ConEmu using mysis gitbash on Windows 10 i needed to add chcp.com 437 to my ConEmu Startup > Environment to get rid of the python debug info. It’s worth noting that 437 is the output i got when i ran chcp.com from the shell even before i added it to my environment.
I get this error when using the PowerShell Integrated Console in VS Code as well.
Works fine in a regular PowerShell window on the same machine.
This error occurs with the combination of Windows10 and the Quick Start Terminal without changing the code page to another one (e.g. 932) by running chcp.com [code page].
$ docker-compose version
docker-compose version 1.12.0, build ee0f34e1
docker-py version: 2.2.1
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.2j 26 Sep 2016
$ docker version
Client:
Version: 17.04.0-ce
API version: 1.28
Go version: go1.7.5
Git commit: 4845c56
Built: Wed Apr 5 23:33:17 2017
OS/Arch: windows/amd64
Server:
Version: 17.04.0-ce
API version: 1.28 (minimum version 1.12)
Go version: go1.7.5
Git commit: 4845c56
Built: Wed Apr 5 18:45:47 2017
OS/Arch: linux/amd64
Experimental: false
Workaround in steps:
- Start -> Run ->
cmd(no, really don’t use anything else — cmder, conemu, anything) - run
chcp - copy the currently active code page (for example for Czech it’s 852)
- run
chcp [number](e.g.chcp 852) in the shell that does not work
Cmder specific workaround if you don’t want to change behaviour of all of your consoles:
- in Setings -> Tasks click the
+button - name the new task
dockerfor example - copy values from your preffered task
- in my case:
- Task parameters:
/icon "%CMDER_ROOT%cmder.exe" - Commands:
cmd /k "%ConEmuDir%..init.bat" -new_console)
- Task parameters:
- in my case:
- to the «Commands» textarea add
&& chcp [number](in my case&& chcp 852) to the end of each line that has a command- in my case there is only one line, but generally there can be more of them
- open that console (by selecting in the drop down in the new console dialog) and use it for anything docker-related
@tomasfejfar Are you saying to run docker-compose in nothing other than cmd.exe?
I had opened an issue about this here as well: PowerShell/PowerShell#3819
I try to use PS in general. But because I’m on windows I have several terminals…
@412andrewmortimer no, you only need «clean» and «plain» cmd.exe to get the default value of code page. You can then run docker-compose anywhere you like
For VSCode run following [Console]::OutputEncoding = [System.Text.Encoding]::Default in console to fix.
On Windows, this error occurs when console’s code page is 65001(UTF). For powershell, I change that to 936(Chinese) and it is solved. But for WSL, I can’t change the code page, so I’m out of luck here. Hope the upgrading to Py3 happens soon.
The supposed workaround, of running chcp 850 or chcp 437 has a terrible side effect: it starts messing up characters.
Example:
11:58:02 ~$ cmd.exe /c chcp 437 > /tmp/chcp 2>&1 11:58:06 ~$ sudo find / -iname "pkg.?config" find: ΓÇÿ/mnt/c/$Recycle.Bin/S-1-5-18ΓÇÖ: Permission denied 11:58:12 ~$ cmd.exe /c chcp 65001 > /tmp/chcp 2>&1 11:58:19 ~$ sudo find / -iname "pkg.?config" find: ‘/mnt/c/$Recycle.Bin/S-1-5-18’: Permission denied 11:58:23 ~$ docker-compose stop Traceback (most recent call last): File "logging__init__.py", line 872, in emit LookupError: unknown encoding: cp65001 Logged from file main.py, line 74
I need cp65001, and I need docker-compose. There needs to be a better fix.
@killerspaz your post doesn’t appear to be anything to do with encoding or codepages.
Ah that’s weird, I replied to an email with that asking how to get docker inside a container. It won’t let me delete it on my phone, will check when I’m back at a computer.
This issue just started for me after updating Docker via the auto updater for Windows 10.
$ docker-compose --version
Traceback (most recent call last):
File "docker-compose", line 3, in <module>
File "composeclimain.py", line 67, in main
File "composeclimain.py", line 99, in dispatch
File "composeclidocopt_command.py", line 25, in parse
File "composeclidocopt_command.py", line 12, in docopt_full_help
File "site-packagesdocopt.py", line 575, in docopt
File "site-packagesdocopt.py", line 484, in extras
File "site-packagescoloramaansitowin32.py", line 40, in write
File "site-packagescoloramaansitowin32.py", line 141, in write
File "site-packagescoloramaansitowin32.py", line 169, in write_and_convert
File "site-packagescoloramaansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Failed to execute script docker-compose
I’m running Version 17.06.1-ce-win24 (13025)
This issue will be fixed (for all use cases, like from inside WSL) once docker-compose is released with embedded Python3 as an option: #5063
I rebooted my computer and the problem was fixed.
Had the issue when running from Terminal in VS Code.
Running from Powershell Console — no problem.
Could we solve this with using docker stack instead of docker-compose?
This seems to be happening for a lot of people with the latest creators update to Windows 10.
Is there any way we can resolve this?
I also confirmed that this problem exists/surfaces using vscode on a Windows machine when there are comments in the docker-compose file. I got a workaround which did the trick for me docker-compose pull | % ToString on my Powershell prompt within vscode. Thanks @mklement0 !
I was able to ‘resolve’ this issue with a workaround, using the win-unicode-console package for Python with pip install win-unicode-console and then restarting the terminal application.
Since updating docker today I have not been able to run docker-compose.
$ docker --version
Docker version 19.03.5, build 633a0ea
I found in ConEmu using mysis gitbash on Windows 10 i needed to add
chcp.com 437to my ConEmu Startup > Environment to get rid of the python debug info. It’s worth noting that 437 is the output i got when i ranchcp.comfrom the shell even before i added it to my environment.
This solution worked for me.
Think i upgraded my powershell recently, forgot i had something like :
# $OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding =
# New-Object System.Text.UTF8Encoding
in my profile. Removed it and i don’t have this problem anymore.