OSDev

для всех
Текущее время: 16 дек 2018, 00:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 19 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: 09 май 2015, 13:01 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Всем привет! Давайте немного поговорим о шелле. А в более узком смысле - о текстовом шелле.
Текстовом в том смысле, что ввод команд осуществляется преимущественно с клавиатуры, и вывод соответственно осуществляется преимущественно в текстовом виде.
Сразу сознаюсь, я не линуксоид, т.е. весь мой опыт общения с такими оболочками ограничивается виндовой cmd. Понятно, что возможности cmd достаточно скудны, или сделаны просто для галочки, но не суть.

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

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

Про автодополнение скажу отдельно, вижу его в таком же виде, как это реализовано в современных IDE, т.е. ctrl+пробел вызывает список возможных значений, из которых можно выбрать нужное. Поскольку с линуксовой консолью я не знаком, не знаю, может быть там реализовано более удобно? Тогда хотелось бы услышать, как. Автодополнение по tab видится мне не очень удобным, т.к. варианты не представлены наглядным списком.

Является ли описанный набор возможностей необходимым минимумом для комфортной работы, или я забыл какие то возможности, цена реализации которых меньше выгод, которые они приносят? Ну и вообще хотелось бы услышать рассуждения на заданную тему. Спасибо :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 13:07 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Речь о том, чтобы свой реализовать или готовый использовать? Из текста как-то непонятно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 13:50 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Речь о том, чтобы реализовать свой. Проблема в чём, таких шеллов (КМК, хотя я не искал) вагон и маленькая тележка, поэтому особо утруждаться над созданием не хочется, т.к. по сути это просто написание очередного велосипеда. Однако, если придерживаться принципа здорового минимализма, может получиться нечто, не сильно сложное в разработке, но достаточно удобное в использовании. Если же попытаться скомпилировать какой то уже имеющийся шелл под голое ядро, сразу потянется куча зависимостей от libc или ещё чего нибудь эдакого. Так то можно попробовать поковырять что нибудь из готового и простого, но мне кажется там рисков больше чем профита. Саму текстовую консоль всё равно придётся почти с нуля делать, так ведь?

В целом, мне интереснее скорее UI шелла, чем сам движок командного интерпретатора (подразумевается возможность лёгкой замены используемого движка).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 14:10 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Мда. Еще одна тема для Skype. Без проговаривания текстом не смогу написать. :oops:

Центральная идея -- не делать командную строку, делать командный мемо. Так сделано в оболочках к СУБД, нечто похожее в ОС Oberon, да и вообще в любой неклассической ОС, тяготеющей к объектам. Я эту идею продумываю не только как замену командной строке, но и как замену Far, без которого я как без рук. Идея организации среды на замену им обоим ценна сама по себе, даже помимо ZUI.

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

В Skype посмотрел, контактами мы еще не обменивались.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 14:18 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1092
Цитата:
Речь о том, чтобы свой реализовать или готовый использовать? Из текста как-то непонятно.

osdev - это собрание альтернотивщиков здесь каждый пишет своё. Поэтому вопрос не уместен.

tab - как по мне удобнее. Одна клавиша вместо двух. Вывод списка там тоже есть, если двойной tab(быстрое нажатие) нажать или напротив долго держать.

А во вторых не понятно. Вы видите оболочку как консоль или как редактор или как что?

Терминал:
Одно дело когда мы работаем с сетью и можем передавать 3-5 потока.
1. Коды клавишь и их состояния и задержки между нажатием.
2. Координаты мыши и состояния.
3. Коды символов.
4. Протокол отображения

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

Другое дело когда мы работаем через UART порт и у нас всего 2 потока
1. На прием
2. На передачу

И нам надо как-то упаковать предыдущие 4 пункта в эти 2.

Оболочка:
Что касается оболочки(shell), то она может быть разной но надо учитывать особенности разной аппаратуры.

Консоль:
То что интерпретирует команды.
Команды как правило делятся на 2 вида, а то и на 3.
1. Скиповый язык.
2. Встроенные команды консоли.
3. Сторонние программы которые вызываются с параметрами.

Пункт 1 почти тоже самое что 2 только записанные в файл. Есть и отличия в поведении некоторых команд. Плюс наличие переменных.

Как организовать внутреннее устройство? Как сказал Вирт Структуру+Алгоритмы=программы.
Так что я бы сделал по нормальному парсер, который бы разбирал строку на структуры.
Как временное решение подойдет и просто строку передавать. Просто первоначальный выбор архитектуры в дальнейшем отразится на всём. Откуда предпочтение отдаю сделать сразу все по нормальному.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 14:58 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1092
dragon писал(а):
Речь о том, чтобы реализовать свой. Проблема в чём, таких шеллов (КМК, хотя я не искал) вагон и маленькая тележка, поэтому особо утруждаться над созданием не хочется, т.к. по сути это просто написание очередного велосипеда. Однако, если придерживаться принципа здорового минимализма, может получиться нечто, не сильно сложное в разработке, но достаточно удобное в использовании. Если же попытаться скомпилировать какой то уже имеющийся шелл под голое ядро, сразу потянется куча зависимостей от libc или ещё чего нибудь эдакого. Так то можно попробовать поковырять что нибудь из готового и простого, но мне кажется там рисков больше чем профита. Саму текстовую консоль всё равно придётся почти с нуля делать, так ведь?

В целом, мне интереснее скорее UI шелла, чем сам движок командного интерпретатора (подразумевается возможность лёгкой замены используемого движка).

Тогда FreeMan прав. Вам надо взять memo или браузер. И списать интерфейс оттуда.
Есть два пути. Либо вы пишете и тогда из-сходя из потребностей будут появляться идеи либо вы копируете. А вот так вот придумывать много не напридумываешь.

memo - является оконным компонентом. Т.е. memo является наследником окна или окно является делегатом memo.
Окно содержит координаты, размеры, полосы прокрутки, обработку сообщений(событий, сигналов).
Может выводить графические или текстовые примитивы.

Memo уже умеет выделять область копировать данные вставлять. Уметь вписывать слова если надо.

Оболочка еще поддерживает историю команд и вывод окна с вариантами для автозаполнения.
А также обрабатывает ввод и вывод для отделения "командной строки" от остального текста.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 15:30 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Цитата:
не делать командную строку, делать командный мемо


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

Цитата:
tab - как по мне удобнее. Одна клавиша вместо двух. Вывод списка там тоже есть, если двойной tab(быстрое нажатие) нажать или напротив долго держать.


Так то одна клавиша удобней чем две, но можно ли в этом списке курсорными клавишами выбрать вариант?

Цитата:
Вы видите оболочку как консоль или как редактор или как что?


Ну мне самому до конца непонятно, иначе нечего было бы обсуждать. Скорее как что: как текстовый документ (массив строк) с полем ввода в конце. "Протокол отображения" без окон. Что значит "с goto или без" не понял. Если предположить работу через UART например, то в одну сторону пойдут пакеты с устройств ввода, а в обратную сторону - обновления буфера в виде (x, y, w, h, data).

Цитата:
Что касается оболочки(shell), то она может быть разной но надо учитывать особенности разной аппаратуры.


Какие например особенности аппаратуры надо учитывать?

Цитата:
То что интерпретирует команды.


Как я уже говорил, сама интерпретация команд будет реализована простейшим способом - отделение первого слова, поиск по нему адреса функции и вызов её с аргументом - введённой строкой команды. Такой подход позволит не городить огород из парсеров и в случае необходимости подставить любой другой интерпретирующий движок. Также подразумевается, что оболочка не будет выполнять функцию интерпретатора скриптов, а лишь будет служить рабочей средой для оператора (т.е. реализация всяких конструкций типа FOR, IF и т.п. отбрасывается). Поэтому внутреннее устройство меня не сильно волнует. Хотя идеи по поводу движка готов выслушать.

Ещё один мелкий вопрос:

Имеет ли смысл держаться за подход read-write + ццикл интерпретатора, или можно уйти на событийно-ориентированную модель (грубо говоря, 2 memo + обработка onKeyPress для командного memo). Что из этого предпочтительнее и почему?

Цитата:
Вам надо взять memo или браузер.


Проблема только в том, что ни того ни другого под рукой готового нет. Есть только голый текстовый буфер и очередь сигналов от устройств ввода. Или подразумевается "взять и скомпилировать"? Откуда взять и чего они потянут вместе с собой в качестве зависимостей?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 15:51 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1092
Цитата:
Проблема только в том, что ни того ни другого под рукой готового нет. Есть только голый текстовый буфер и очередь сигналов от устройств ввода. Или подразумевается "взять и скомпилировать"? Откуда взять и чего они потянут вместе с собой в качестве зависимостей?
Я имел в виду взять подсмотреть как сделано у других. Не надо брать всё. Достаточно выписать названия функций. И то не всех.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 17:07 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
dragon писал(а):
Ну это я считаю как бы само собой разумеющееся (возможность многострочного ввода).

Да вот, если отказаться от командной строки и консоли как таковой, это в корне меняет подход к интерфейсу, старые шаблоны перестают работать. Я потому и хотел поговорить, поскольку из-за своего СУБД-шного окружения имею значительный практический опыт работы с системой на основе команд, не являющейся командной строкой, и вижу разницу изнутри. СУБД-шные админки -- уже не консоль, но еще не ZUI.

dragon писал(а):
Имеет ли смысл держаться за подход read-write + ццикл интерпретатора, или можно уйти на событийно-ориентированную модель (грубо говоря, 2 memo + обработка onKeyPress для командного memo). Что из этого предпочтительнее и почему?

Это взаимосвязанные вещи. Потоковая консоль ориентирована на потоковый ввод-вывод, даже банальное редактирование к ней сбоку прикручивается. Мемо же подразумевает событийную модель. При этом события можно сериализовать для передачи по сети а-ля консоль, а наоборот уж слишком костыльно выйдет, разве нет?

pavia писал(а):
Я имел в виду взять подсмотреть как сделано у других. Не надо брать всё. Достаточно выписать названия функций. И то не всех.

Ага, ага. Сначала названия функций подсмотреть, потом еще что-нибудь, типа потокового ввода-вывода, потом еще. Думать некогда. :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 17:49 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Цитата:
Так то одна клавиша удобней чем две, но можно ли в этом списке курсорными клавишами выбрать вариант?


Пока никто не ответил, буду считать (проверять лень), что двойной таб только выводит список вариантов, а выбор в нём с помощью курсорных клавиш невозможен.

Цитата:
СУБД-шные админки


Если подразумевается html-ная форма с полем ввода для запроса, мне бы хотелось нечто более интерактивное. И заодно про событийную модель. Загвоздка вот в чём. Консольные приложения пишутся довольно легко потому что там есть ReadLn/WriteLn. Логика приложения становится тривиальной: (ReadLn -> Eval -> WriteLn) * loop; В случае же с событийной моделью имеем обработчики, разбросанные по разным участкам кода, что размывает логику. Беспокоит меня тривиальная программа: begin var Name := ReadLn; WriteLn('hello, ' + Name); end. Её нельзя будет выполнить в случае событийной модели, или я чего то недосмотрел? По-моему, потоковый подход выглядит в этом случае более естественным. Конечно событийная модель имеет свои преимущества, но что то они как то от меня ускользают, поэтому у меня возникло желание избавиться от неё где возможно. Ведь придётся для ReadLn делать всю эту возню с Application.ProcessMessages... не знаю.

Вообще задача кажется настолько простой, что заимствование даже как то не приходит в голову. Что можно из других проектов тягнуть? Из каких? GNU ReadLine? Вообще непонятно где искать мостик между текстовым буфером вывода и очередью событий с устройств ввода. Больше всего интересуют таки концептуальные вопросы, но судя по обсуждению я ничего из них не забыл. Если есть что добавить - всегда рад.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 19 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB