Названия консольных команд.

> автодополнение по s<tab>e<tab> нарисует system.editor

это если использовать только лишь эту идею. Если совсместно с существующими именами, то бардак будет множиться...

su изначально было «set UID», что приводит к варианту «set user».

> system.editor.sed => /usr/bin/sed

system.application.editor.stream.sed

system.application.editor.console.stream.sed

system.editor.vim => /usr/bin/vim

system.application.editor.console.vim

system.application.editor.console.interactive.vim

system.application.editor.console.ncurses.vim

system.application.editor.console.ncurses5.vim

system.editor.gedit => /usr/bin/gedit

system.application.editor.graphics.gedit

system.application.editor.X.gedit

system.application.editor.gtk.gedit

system.application.editor.gtk2.gedit

system.application.editor.gnome.gedit

--------------------------------------

Что кошернее и почему?

Надо сделать соответствующий help наподобие gdb'шного:

$ help
adm - system administration
file - file management
text - working with text
...
$ help adm
apt - soft management
dpkg - working with packet
...
$ help adm.dpkg
deb - creates deb-packet
reconfigure - configures packet
...

Не стоит доводить до абсурда, достаточно посмотреть как уже сделано в меню всяких WM. Например, app.text.vim вполне достаточно.

> Что кошернее и почему?
хз. пока обсуждаем жизнеспособность самой идеи. Стандартизация названий - это повод для отдельного холивара :).

> Не стоит доводить до абсурда, достаточно посмотреть как уже сделано в меню всяких WM. Например, app.text.vim вполне достаточно.

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

>ибо именно как-то так будет выглядеть твоя консоль с воплощением этой идеи

примеры, которые используют максимум 3 уровня

Что-то у тебя не сходится, товарищ.

Okay, as I see, this idea don't have interest for most...

Быстро ты сдался :(

>Есть google, есть поиск в вашем пакетном менеджере, есть apropos.
Интернет может не работать. Пользователю как раз могут понадобиться команды чтобы проверить/настроить сеть.
apropos - а как пользователь догадается, что есть такая штука?
(Словарь apropos: уместный, своевременный)

Эта штука не намного лучше чем man -k

> хз. пока обсуждаем жизнеспособность самой идеи. Стандартизация названий - это повод для отдельного холивара :)

Проблема «интуитивного» стандарта в полный рост. :)

Правильно! Моя идея - не Ъ!
Ъ это когда ты пишешь кучу непонятных другим слов в консоль, повышая ЧСВ.
Как в фильмах про хацкеров.

>Для отделения таких команд можно ввести особый первый элемент:
Хорошая мысль!

А кто-нибудь проверил уже, шелл с сотней алиасов не начнет тормозить?

>Получается что всеравно читать прийдется. тоесть система ненужна.
Да читать всегда надо, даже с gui. Хотя если поставить tts...

Да, разбираться с параметрами команд все равно надо будет.
То, что я предлагаю упрощает поиск команд.

Об этой концепции достаточно услышать 1 раз, а обычные команды надо запоминать все по одной.
Пользователю достаточно увидеть, что есть adm. [TAB] или stat. [TAB], все остальные группы и их содержимое он найдет сам.
Тем более, если сделать префикс, как тут предложили.

>Алиасы и симлики в $HOME/bin/ изобрели давно. Что вы пытаетесь переизобрести?

Ага, только пользователю надо сначала узнать нужные ему команды, а потом наклепать к ним алиасов.
А если он узнает команды, то, зачем ему алиасы?

Это для начинающих пользователей.

>> примеры, которые используют максимум 3 уровня

Что-то у тебя не сходится, товарищ.

Да. 3 уровня — серьёзное ограничение и так ли оно функционально?

system.utilites...

utilites...

system.network...

system.utilites.network...

utilites.network...

system.boot...

system.utilites.boot...

utilites.boot...

system.fs...

system.utilites.fs...

utilites.fs...

system.editor...

system.application.editor...

system.application.spreadsheet...

application.editor...

application.spreadsheet...

Что относится к «system», нужно ли выносить отдельно «application» или «utilites» и прочие вопросы... Будет ли это удобно новичку или придётся учить новую параллельную реальность?

Это для начинающих пользователей.

Для начинающих пользователей есть «The Linux bible» и команды apropos и man.

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

> Потом проводить обряд инициации и называть Истинные Имена Команд.
alias adm.users.add='echo Use useradd, Luke&&useradd'

> Проблема «интуитивного» стандарта в полный рост. :)

Кстати, такие утилиты, как tcpdump, iptraf, netcat — относятся к утилитам администрирования или утилитам разработки?

Эт смотря что ты разрабатываешь :)

Да не, просто менять сорокалетний стандарт - это немного слишком. Это как umount и creat - никому не нравится, но ничего не поделаешь.

Начальная подготовка тут заключается в запоминании свалки из команд, которая образовалась исторически.
Когда добавлялись новые вещи, никто просто не заботился от том, чтобы это хоть как то организовать, имя не занято - и ладно, добавляют утилиту.

На них будет по два алиаса.

>Не знаешь что делать с картинками? apropos image
Ты сам то пробовал?

>К тому же, длина всех этих команд просто убивает сам смысл использования консоли - быстроту и удобство работы.
Быстрота тут пострадает не сильно, т.к. тут больше половины команды дощелкается Tab'ом.

>Мне проще ввести ls, чем system.io.files.list.
Ты это, первое сообщение просчитай целиком, да.

Кстати, list, copy и т.п. - тоже не плохо было бы.

Трололо!

>Надо сделать соответствующий help наподобие gdb'шного:
Отличная мысль!

> Быстро ты сдался :(

не боись, пусть в умах брожение пойдёт. Потом ещё один вброс сделаем ненавязчиво. Но уже с более конкретными предложениями. Типа, «фолк, вот как лучше заалиасить tcpdump: net.dump, или net.sniffer?».

А если несколько разных людей ещё спросят подобное про различные казалось бы разные утилиты, но объединённые такой доменной нотацией, то уже и противники заинтересуются: а чего они там воротят-то? :)

>system.utilites

Бесполезно. Надо делить по функционалу.

application.spreadsheet

Для обычных приложений есть меню, им это не нужно.

>Озвучил идею в девелоперском списке рассылки Федоры

Ответы характерно показывают опенсорс во всей красе или «1000 и 1 способ намекнуть, что ты нуб» :}

>Есть гугл, поэтому документацию надо упразднить, да :}

Ни разу нет. Перечитай мои посты.

Уж кто посты в этой теме не читает, так это ты.

>apropos - а как пользователь догадается, что есть такая штука?

Пойми же, пользователь должен знать хоть что-то, чтобы пользоваться консолью.

no wai! помнить придется не меньше, а больше, да и man -k никто не отменял.

http://www.pixelbeat.org/cmdline_ru_RU.html
http://cb.vu/unixtoolbox.xhtml
http://find.unixpin.com/ru/
http://mymans.org/category/unixlinux и пр.

По-моему, хорошая идея.

Идея №2:

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

Первый - не такой объемный по необходимым изменениям, но менее гибкий.
При нажатии tab shell должна вызывать команду с --help и парсить вывод, конкретно, вырезать из вывода описание той опции, что пользователь уже написал (или написал частично). Получится не сложно, но и не гибко.

Второй - примерно такой же - парсить соответствующую man страницу.

Третий - наиболее полноценный - отдать автодополнение самой проге.
Да, это значит, что проги надо переписать, но это будет самое лучшее автодополнение.
Надо сделать протокол общения shell'а и программ. При нажатии Tab shell запускает программу с особым параметром, например, --autocomplit, после чего передает ей (через pipe или еще как, но уже не в качестве параметров) те параметры, что уже ввел пользователь.
Прога полноценно парсит и проверяет параметры, выдает варианты дописания команд, сообщает об ошибках в параметрах, показывает справку по кусочкам.

То, что в настоящее время - костыль, т.к. дополнение полностью на стороне shell, какие-то параметры в него включены, какие-то - нет.

Для Ъ хочу сказать, что это можно сделать опционально, а так же с изменяемым уровнем подробности.

>>Да, это значит, что проги надо переписать, но это будет самое лучшее..

да, а ещё можно расстрелять всех плохих людей.

да, надо всё взять и переписать. Уж у нас-то получится лучше. Мы будем писать только хорошие неглючные программы без ошибок.

То, что в настоящее время - костыль

Для Ъ хочу сказать, что это можно сделать опционально

А ты в курсе чем настоящая программа отличается от ненаписанной?

В случае реализации подобной структуры не обязательно обоходиться простым автодополнением. Для совсем новичков опционально можно сделать полноценную менюшку, с хоткеями и краткими описаниями команд (вот тут, думаю, сработали бы идеи ls-h).

Более того, если дело примет радикальный оборот, можно сделать не просто альясы, но полноценные оболочки с единым API. Тогда подобный подход позволит ещё и сгладить различия для новичков в различных дистрибутивах.

Утопично, конечно, но, если кто возьмётся и доведёт до ума, почему бы и нет...

Запостил только что в OpenFATE - https://features.opensuse.org/309371 - может подтвердят

Вот это мне кажется несколько нереальным :)

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

> откуда ему знать, что это называется apt?

из ридми.

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

>Третий - наиболее полноценный - отдать автодополнение самой проге.
Хорошая идея. Для лучшей интеграции с шеллом можно ещё сделать программы расширениями шелла.
И ещё. Обычный текстовый интерфейс сильно устарел. Нужно сделать программы (уже расширения шелла) объектно-ориентированными.
В качестве языка для расширений предлагаю mono.

</fat-mode>

Второй - примерно такой же - парсить соответствующую man страницу.

АФАИК такое уже есть в некоторых толстых шеллах.

Не знаю, шутка это или нет, смущает «</fat-mode>», но в общем идея интеграции шела и утилит мне нравится.