Не удаётся перекодировать текст

iconv?

на самом деле я не понимаю в чем проблема.

Это не перекодировать, там ошибка в программном коде screen. Вроде, была отдельная ветка, в которой это исправляли.

screen запускается с ″-U″? Какая версия screen?

Как перекодировать текст в файле?

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

А этот hardcopy может выводить в stdout, а не сразу в файл?

Параметр -U присутствует.

Screen version 4.06.02 (GNU) 23-Oct-17

Проверю на латест версии.

Саахрикту заносите.

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

Да-да, двоешник не лох, а просто не любит нормальные оценки…

Среднему в вакууме американцу (а большинство разработчиков проекта GNU именно в США), если он пишет и читает на английском языке, вполне достаточно ASCII. Это нам в России ещё и вторую половину кодовой таблицы с кириллицей подавай.

Юникод актуален прежде всего для арабов, китайцев, японцев, индийцев,... и т.д. Европейцы тоже могут находить его удобным.

То есть, актуален для 80% населения планеты…

Пусть так. Но для 20% тогда не так уж и актуален. А в абсолютных числах это не так уж и мало - это миллионы людей.

Вот скриншот с пруфом, что hardcopy screen'а дампит не в 7-ми битном ASCII, а в однобайтной кодировке (некоторые коды может не совсем корректно обрабатывать, но тем не менее): http://saahriktu.org/tmp/scr1574124658.png

В общем, KOI8-R поддерживается. А UTF-8 - нет.

Но для 20% тогда Эти 20% пользуются кодом, который или пишут 80% или пишут с учётом этих 80%…

Эти 20% пользуются кодом, который или пишут 80% или пишут с учётом этих 80%...

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

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

Профессора свои статьи оформляют в TeX'е. Там для формул достаточно ASCII. А вот русский и французский в одну однобайтную кодировку, да, не уместить. Но не всем это нужно.

да, не всем, но всем - локализация программ.

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

Вечер августа спустился...

Среднему в вакууме американцу (а большинство разработчиков проекта GNU именно в США), если он пишет и читает на английском языке, вполне достаточно ASCII. Это нам в России ещё и вторую половину кодовой таблицы с кириллицей подавай.

Да первые может бы и с радостью юзали всякие красивые таблички линиями из второй половины, но добрая старая европа взяла и испортила там всё :)

Проникнитесь проблемой https://savannah.gnu.org/bugs/?55138 , в целом unicode в screen работает, а во всяких hardcopy, hardstatus возникают проблемы. Тут вот есть другие ветки https://github.com/amade/screen/tree/encoding-rewrite , в том числе брошеная unicode++, в которой hardcopy вроде бы исправляли. Но, если я правильно понял, там в кишках всё запутано, и исправляя в одном месте, ломается в другом.

Проникнитесь проблемой https://savannah.gnu.org/bugs/?55138 , в целом unicode в screen работает, а во всяких hardcopy, hardstatus возникают проблемы. Тут вот есть другие ветки https://github.com/amade/screen/tree/encoding-rewrite , в том числе брошеная unicode++, в которой hardcopy вроде бы исправляли. Но, если я правильно понял, там в кишках всё запутано, и исправляя в одном месте, ломается в другом.