Я сейчас не говорю про скриптинг. Как мне ее воткнуть вместо баша, например? Понятно, что он выполняет команды которые находятся в /bin, /user/bin... Да, и нужно придумать синтаксис скрипта, чтобы парсер его потом переводил.
>Вдруг он собирается писать интерпретатор на интерпретаторе(bash)? и с C не знаком.
Ненуачо, написать интерпретатор на питоне, придумать свой синтаксис, в принципе равный синтаксису питона, только чуть другой. Читать, парсить, запускать аналогочиные функции. Дениска Попов отдыхает!
>Ты сам толком скажи как работает интерпретатор, а не тычь меня в исходники и маны
Лол.
Читает строку (если не хочется велосипедить readline). Разбирает синтаксис. Выполняет встроенные функции. Если в синтаксисе шелла предполагается «всё, что не встроено — внешняя команда» (как правило), то запустить команду (с раскрытием $PATH). Организует межпроцессное взаимодействие (пайпы).
#!/bin/sh
while read i; do
i=`echo $i|sed 's/L/\|less/g'`
eval "$i";
done
Теперь мой supershell умеет глобальный алиас (почти как zsh!). L пайпает всё, что до него, через less.
В версии 4.0 запилю киллерфичу — команду alias с ключом -g и хранением глобальных алиасов в отдельном файле. Даёшь возможности zsh в posix shell!
>Вот, если я возьмусь писать свой shell, с чего начать?
Начать с того, что отказаться от идеи писать свой shell, а влиться в багзиллу любого интересующего, чтобы фиксить баги и добавлять фичи. Уже сотни людей проделали огромную работу (ты только представь себе количество человеко-часов!). Будь мужиком и рациональным! Получи удовольствие от работы в коллективе! :)
Как он работает?
Взять любой шелл и посмотреть исходники. dash из Debian, например. Да какой хочешь.
Скорость — побочное свойство. Шелл выбирают по синтаксису (в первую очередь извращенцы, предпочитающие *csh, в запущенных случаях — тиклешеллы, в особо запущенных — rc, es, kes) или исходя из ограничений (busybox, BSD-шеллы).
Сидит и ждёт, пока в stdin не появятся какие-то байтики. Как только появились - он их парсит. И в зависимости от того, что он там напарсит, делает соответсвующие вещи. Например загружает какой-то /usr/bin/cat и ждёт пока тот не сдохнет. Как только сдох - опять ждёт байтики в stdin.
Если распарсить не получатся - на юзера матюком тогда: «Юзер, я не понял, чё за фигня?!».
А если чуть серьёзнее, то читает стандартный ввод и разбирает всё что с него приходит до тех пор пока не получится либо некий statement, либо какая-то лажа. В первом случае рисует на основе statement'а дерево и сворачивает его (при этом совершая какаие-то действия над окружающим миром и памятью), во втором — падает с грохотом. К этому ещё следует добавить gc на счётчиках ссылок или регионах по вкусу.
если просто начать разобрираться как работает интерпретатор, то я бы советовал начать с внутренностей tcl - они очень просты и стиль проектирования и кода на хорошем уровне.
С осиливания какой нибудь приличной книжки, вроде Design and Implementation of 4.4BSD МакКьюсака, где в начале немного объясняется, как работают интерпретаторы в плане процессов и их взаимодействия.
Ну и потом ДрегонБук - командный язык же надо реализовать.
Еще можешь посмотреть в сторону Linux Application Development, Michael K. Johnson, Erik W. Troan. Там они таки осуществляют мечту, подобную твоей-пишут небольшой интерпретатор на C
O_O быстрее С? С распаралеливанием на БлюДжин или Ломоносове??? Хочу Вас огорчить - скорость работы шелла значения вообще не имеет, он не применяется в задачах где скорость критична. Все равно все упрется в производительность диска...
А так... делаете семейство классов, строите из их экземпляров дерево реализующее конечный автомат и вперед... что может быть проще?