У меня на свежем сизифе не воспроизводится. Возможно, это зависит от терминала?

echo $TERM

что там?

$ echo $TERM
linux
$

Наблюдаю на эту проблему двух разных машинах. Дополнительно:

$ echo $LESS
-MM
$ echo $LESSKEY
/etc/.less
$ echo $LESSOPEN
'|/usr/share/less/lesspipe.sh %s'
$ cat /etc/.less
cat: /etc/.less: Нет такого файла или каталога
$

Изучая код lesspipe.sh и вывод strace, заметил, что этот скрипт почему-то считает вывод помощи Перл как "ELF " или как "data". Из-за этого выбирает hexdump для отображения на экране. Другой причины я не вижу, по которой бы из скрипта lesspipe.sh был бы вызван hexdump.

(Ответ для serpiph на комментарий #3)
> Изучая код lesspipe.sh и вывод strace, заметил, что этот скрипт почему-то
> считает вывод помощи Перл как "ELF " или как "data". Из-за этого выбирает
> hexdump для отображения на экране. Другой причины я не вижу, по которой бы
> из скрипта lesspipe.sh был бы вызван hexdump.

значит, это все из-за file. 
попробуйте не выходя из perldoc -f open
скопировать созданный временный файл из $TMP
сохраните и посмотрите, что на этот файл скажет file -bLz

$ file - bLz perl-open
data
$

Прикладываю файл, который получается от perldoc.

Created attachment 12809 [details]
Результат работы perldoc

Данный файл получается у perldoc, который потом выдаётся в hexdump с параметром -C.

(In reply to serpiph from comment #5)
> $ file - bLz perl-open
> data
> $
> 
> Прикладываю файл, который получается от perldoc.

Опечатка, правильно:

$ file -bLz perl_open
data
$

у меня c вашим файлом ситуация воспроизвелось и на p10.
less perl_open показывает как hexdump.

Остается вопрос, почему у вас получается именно такой файл?
Я приложу результат своего perldoc -f open
который показывается нормально.
diff показал, что у вас строки не wrapped, у меня wrapped.
Похоже на некорректную работу с терминалом.

Покажите, пожалуйста, что у вас

rpm -qa | grep perl | grep -i pod

rpm -qa | grep terminfo

И если нет terminfo-extra, что будет, если установить пакет terminfo-extra ?

Created attachment 12818 [details]
результат perldoc от viy

$ rpm -qa | grep perl | grep -i pod
perl-Pod-Usage-2.03-alt1.noarch
perl-pod-5.34.1-alt1.noarch
perl-Pod-Simple-3.43-alt1.noarch
perl-Pod-Escapes-1.07-alt1.noarch
perl-podlators-5.01-alt1.noarch
perl-Pod-Perldoc-3.20-alt1.noarch
perl-Pod-Parser-1.65-alt1.noarch
perl-Pod-Checker-1.75-alt1.noarch
$ rpm -qa | grep terminfo
terminfo-6.3.20220618-alt1.noarch
$ 
После установки terminfo-extra поведение perldoc не изменилось.

На второй машине:
$ rpm -qa | grep perl | grep -i pod
perl-Pod-Usage-2.03-alt1.noarch
perl-pod-5.34.1-alt1.noarch
perl-Pod-Simple-3.43-alt1.noarch
perl-Pod-Escapes-1.07-alt1.noarch
perl-podlators-5.01-alt1.noarch
perl-Pod-Perldoc-3.28-alt1.noarch
perl-Pod-Parser-1.65-alt1.noarch
perl-Pod-Checker-1.75-alt1.noarch
perl-Gtk2-Ex-PodViewer-0.18-alt2.noarch
perl-Pod-POM-2.01-alt1.noarch
perl-Pod-Strip-1.100-alt1.noarch
$ rpm -qa | grep terminfo
terminfo-6.3.20220618-alt1.noarch
$ 
После установки terminfo-extra на этой машине perldoc заработал нормально.

Даже интереснее становится. На второй машине в обычной текстовой консоли вызывается hexdump даже при установке terminfo, а в программе konsole в KDE команда perldoc показывает всё правильно даже без установки terminfo-extra.

В текстовой консоли
TERM=linux

В графической консоли
TERM=xterm-256color

посмотрите, что говорит в разных ситуациях 
echo $COLUMNS

и в проблемных ситуациях попробуйте запустить
perldoc с PERLDOCDEBUG=1

Такое ощущение, что в проблемных случаях либо $COLUMNS 
не выставляется корректно, тогда это связано с некорректной настройкой терминала,
вот похожие баги:
https://bugzilla.altlinux.org/show_bug.cgi?id=865
https://bugzilla.altlinux.org/show_bug.cgi?id=25245
https://bugzilla.altlinux.org/show_bug.cgi?id=35555

либо все же $COLUMNS корректно, но что-то другое ломает обертывание строк в Pod::Perldoc.

В графике COLUMNS=253, в текстовой консоли COLUMNS=128.

При указании PERLDOCDEBUG=1 перед командой диагностические сообщения одинаковы, последняя строка сообщает

'page: About to call Pod::Perldoc::ToTerm->pager_configuration("/usr/bin/less -isR")

Попробовал в текстовой консоли сделать

$ (unset LESSOPEN; perldoc -f open)

Команда отработала как в графике, без hexdump. То есть почему-то LESSOPEN отрабатывает в текстовой консоли и не отрабатывает в графике.

В общем, похоже, причиной подземный стук внутри file:
это видно на имеющемся у вас образце.

$ file perl_open*
perl_open:     data
perl_open_viy: ASCII English text, with escape sequences

file определил ваш выхлоп perldoc как (binary) data,
мой выхлоп file определил как ASCII English text,
при чем возможно file'у определить, что это ASCII English text,
помогли как раз escape sequences.

Соответственно, гипотеза:
у вас, когда вы на одной из машин установили terminfo-extra,
perldoc понял, что терминал поддерживает escape sequences
И ДОБАВИЛ их в свой выхлоп,
что помогло file'у определить, что это ASCII English text
и все заработало.

Попробуйте проанализировать выхлоп на второй машине:
если с terminfo-extra
file говорит ASCII English text, with escape sequences
а без terminfo-extra
file говорит data

то проблема именно в file, что он не может почему-то корректно определить ASCII English text без костыля в виде escape sequences.

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

После всех проверок сделал всё более внимательно. Наличие или отсутствие terminfo-extra не влияет на поведение perldoc. perldoc отрабатывает нормально, если набрать

$ TERM=xterm perldoc -f open
$ TERM=xterm-256color perldoc -f open
$ (unset LESSOPEN; perldoc -f open)

Неважно, в текстовой или графической консоли это происходит, есть или нет terminfo-extra.

Если написать

$ TERM=linux perldoc -f open

То в любой консоли вне зависимости от наличи или отсутствия terminfo-extra будет hexdump.

Формирование текста выполняется ещё до запуска скрипта lesspipe.sh. Поэтому первый вопрос к модулю Perldoc, зачем он вообще форматирует текст по-разному, если потом идёт через lesspipe.sh. На каком этапе это случилось? На что влияет TERM? Где играет свою роль LESSOPEN? Нужен ли он? 

И уже последующий вопрос к file: что для него есть текст, а что бинарные данные?

Created attachment 12865 [details]
Вывод perldoc с терминалом linux

Результат вывода "TERM=linux perldoc -f open". В файле есть символы с кодом 0x0F.

Created attachment 12866 [details]
Вывод perldoc с терминалом xterm

Результат работы "TERM=xterm perldoc -f open". В тексте нет символа с кодом 0x0F. Определяется как ASCII.

(Ответ для serpiph на комментарий #18)
> Создано вложение 12866 [details] [подробности]
> Вывод perldoc с терминалом xterm
> 
> Результат работы "TERM=xterm perldoc -f open". В тексте нет символа с кодом
> 0x0F. Определяется как ASCII.

ESC это 0x1B, не 0x0F. У меня file пишет
perldoc_xterm: ASCII English text, with escape sequences.

(In reply to viy from comment #19)
> (Ответ для serpiph на комментарий #18)
> > Создано вложение 12866 [details] [подробности]
> > Вывод perldoc с терминалом xterm
> > 
> > Результат работы "TERM=xterm perldoc -f open". В тексте нет символа с кодом
> > 0x0F. Определяется как ASCII.
> 
> ESC это 0x1B, не 0x0F. У меня file пишет
> perldoc_xterm: ASCII English text, with escape sequences.

Сравните 2 файла, что я прислал, между собой. У них разница только в наличии или отсутствии символа с кодом 0x0F после ESC-команды. ESC-символы с кодом 0x1B есть в обоих файлах.

$ diff -Naur file1 file2 | less

Покажет дополнительный байт в виде "^O":

ESC[1m-iESC[m^O

вместо

ESC[1m-iESC[0m

с символом нуля перед последней m.

Воспроизведено на Sisyphus (perl-podlators 6.0.2-alt1, perl-Pod-Perldoc 3.28). При TERM=linux Term::Cap возвращает для sgr0 (me) последовательность ESC[m + SI (\017); Pod::Text::Termcap использует её как NORM, поэтому в выводе pod2text -t / perldoc после каждого выделения остаётся байт \017, и file(1) определяет вывод как data (lesspipe показывает hex-дамп). Причина в perl-podlators, не в perl-Pod-Perldoc. Готовлю исправление в perl-podlators (убрать завершающий SI из NORM) и патч для апстрима.