ESC-ENTER в mc начал вставлять не имя под указателем а ./ИМЯ - Можно побороть?

Думаю это не настраивается, а зачем сделано - по-моему очевидно.

Если же он: -Name…

…ты сам создал себе проблему.

Конкретно это поведение задано здесь:

https://github.com/MidnightCommander/mc/blob/master/lib/util.c Строка 264:

    if (*s == '-')
        g_string_append (ret, "." PATH_SEP_STR);

Легко видеть, что отключение не предусмотрено. Но вы можете на свой страх и риск закомментировать эти строки в коде из репозитария и перекомпилировать. Слава Open Source.

P.S. У mc на удивление ясные исходники. Нашëл нужный код очень быстро за завтраком.

Если же он: -Name…

…ты сам создал себе проблему.

Хорошо, предложите для ZFS другой протокол именования подтомов?
Не хочу, и не могу я помнить все ньюансы, а при работе с zfs - всё мешается в кучу - подкаталоги, подтома...

P.S. У mc на удивление ясные исходники. Нашëл нужный код очень быстро за завтраком.

РЕСПЕКТ!

Расскажите потом стали ли перекомпилировать :-)

Используй @. Вообще бред, конечно, что там запрещены какие-то символы. А минус в начале имени файла всегда создаёт неудобства.

Расскажите потом стали ли перекомпилировать :-)

Нет, если это предопределено то так и должно быть. Чтобы везде было одинаковое поведение, а то «автопилот» штука опасная, потом за чужим компом «наавтопилотишь».
Спасибо за раскрытие первоисточника (строчек кода). Буду думать, над новым протоколом именования.

Используй @. Вообще бред, конечно, что там запрещены какие-то символы. А минус в начале имени файла всегда создаёт неудобства.

Увы, но пока «нашел» только минус... :)
А на счет «бреда» - весьма спорно. Есть определенный синтаксис командной строки и спецсимволы интерпретируются как его компоненты. Это всё же имена подтомов а не файлов, вполне допустимы ограничения.

#zfs create S1T1Archive/@Horse-1.11
cannot create 'S1T1Archive/@Horse-1.11': snapshot delimiter '@' is not expected here

Впрочем, пробежался:

# zfs create S1T1Archive/@Horse-1.11 
cannot create 'S1T1Archive/@Horse-1.11': snapshot delimiter '@' is not expected here

# zfs create S1T1Archive/!Horse-1.11 
bash: !Horse: event not found

# zfs create S1T1Archive/#Horse-1.11 
cannot create 'S1T1Archive/#Horse-1.11': bookmark delimiter '#' is not expected here

# zfs create S1T1Archive/$Horse-1.11 
ЭТОТ СРАБОТАЛ! Но! $Horse посчитал переменной а она равна пустоте...

Вариант:
root@0F-BMAX:/zfs/S1T1Archive# zfs create S1T1Archive/\$Horse-1.11 
cannot create 'S1T1Archive/$Horse-1.11': invalid character '$' in name
Тоже не прошел.

# zfs create S1T1Archive/%Horse-1.11
cannot create 'S1T1Archive/%Horse-1.11': invalid character % in name

# zfs create S1T1Archive/^Horse-1.11 
cannot create 'S1T1Archive/^Horse-1.11': invalid character '^' in name

# zfs create S1T1Archive/&Horse-1.11 
[1] 701909
bash: Horse-1.11: команда не найдена
root@0F-BMAX:/zfs/S1T1Archive# cannot create 'S1T1Archive/': trailing slash in name
Этот логично отправил zfs в фон...

[1]+  Выход 1            zfs create S1T1Archive/

Так что пока протокола именования не найдено... Можно конечно "-" запихать в конец...

# zfs create S1T1Archive/Horse-1.11-

Но оно не отсортируется вверх...

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

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

Нужно удобное решение, а не юникод коды...


Пока нарыл только:

# zfs create S1T1Archive/:Horse-1.11

Но боюсь тоже чем то черевато... Но попробую...

Попробуй подчёркивание «_»

Попробуй подчёркивание «_»

Позволительно, но ох уж эти сортировки....
mc:
-Horse-1.11
:Horse-1.11
Horse-1.11-
_Horse-1.11

ls:
-Horse-1.11
:Horse-1.11
_Horse-1.11
Horse-1.11-

Пока "-" выигрывает у всех... А вот «_» почему то в mc идёт после букв, а в ls перед буквами...

Сначала попробую перейти на ":" - вдруг прокатит, и выглядит логично.

Нужно удобное решение, а не юникод коды…

~ 
> btrfs subvolume create '#test'
Create subvolume './#test'
~ 
> btrfs subvolume create @test
Create subvolume './@test'

> btrfs subvolume create '#test'
Create subvolume './#test'
~ 
> btrfs subvolume create @test
Create subvolume './@test'

Замечательно, но у меня zfs а не btrfs.
Ни чего удивительного что на btrfs это позволено.

Замечательно, но у меня zfs а не btrfs.

Ну вот мы и нашли проблему.

Ни чего удивительного что на btrfs это позволено.

Удивительно, что на ZFS это не позволено. Видимо, «не всем нужно удобство»©

Замечательно, но у меня zfs а не btrfs.

Ну вот мы и нашли проблему.

Не проблему, а «особенность».

Ни чего удивительного что на btrfs это позволено.

Удивительно, что на ZFS это не позволено. Видимо, «не всем нужно удобство»©

Знаете, ZFS была выпущена в промышленую эксплуатацию, за 10 лет до появления btrfs. Я не так хорошо всё понимаю, но эти спецсимволы зарезервированы для разных нужд и вразрез удобству именования - идёт удобство манипулирования.
Я не знаю, но подозреваю что по определенному пути с использованием скажем «@» - можно обратиться к любому файлу в любом снапшоте fs.

А вот «_» почему то в mc идёт после букв, а в ls перед буквами…

$ LANG=en_US.UTF-8 l1
-Horse-1.1
:Horse-1.1
_Horse-1.1
Horse-1.1

$ LANG=C l1
-Horse-1.1
:Horse-1.1
Horse-1.1
_Horse-1.1

Спасибо за акцент. Вот оно в чём дело...

В общем добавил в исходное сообщение:

P.P.S. Спасибо всем за обсуждение! По результатам обсуждения - пока избрал другой «протокол».
Монтировать zfs Том буду в /zfs/=Том
А подтома создавать с именами :Подтом
Если вдруг подтом потребуется смонтировать в отдельный каталог то соответственно mountpoint будет в =Имя, Имя будет выбираться по потребности, хотя случаи разные бывают. Надо рассмотреть протокол монтирования во всякие /var/spool или /var/log (Скажем чтобы распухшие каталоги можно было вынести из сиситемного раздела.)
Нужно предусмотреть индикацию того что этот каталог за пределами fs. ну скажем в виде подкаталога \#zfs=ТОМ--ПОДТОМ.
Просто скажем видел уже на ЛОР жалобы на распухшие каталоги - забивавшие системный раздел в ноль. Стоит рассмотреть такой вариант подстраховки.

Всем спасибо, инцидент пока исчерпан.