Книга посвящена дистрибутиву Linux Mint и одной из его главных


Просто псевдонимы и псевдонимы глобальные



Скачать 21.34 Mb.
Pdf просмотр
страница15/30
Дата22.11.2016
Размер21.34 Mb.
Просмотров5949
Скачиваний0
1   ...   11   12   13   14   15   16   17   18   ...   30
Просто псевдонимы и псевдонимы глобальные
Что такое псевдонимы, по простому aliases, — знают все, кто применяет любую командную оболочку их поддержка существует соврем н перворождённого шелла Борна. Это один из простых способов минимизировать ввод командных директив, начиная с простейшего рекурсивного копирования файлов cp='cp -R'
И заканчивая бессчётным количеством псевдонимов для команды Однако весть ещё одна фича — глобальные псевдонимы, посей день не имеющие аналогов, насколько я знаю, во всяких там ваших башах. И даже в почти соплеменных тсишах их нет.
Но начну по порядку. Опять же, кого не раздражала ситуация в ответ на поиск файла ом или поиск фрагмента текста ом выдаётся сто пятьсот экранов сообщений, что доступ к каталогу запрещён?
Разумеется, каждый применитель а знает, как с этим бороться достаточно присобачить к конструкции поиска посредством той или другой утилиты маленький аппендикс в виде 2> /dev/null, отправляющий в небытие все сообщения об ошибках.
Сложнее применителям Tcsh — там подавления вывода нежелательных сообщений об ошибках возможно в виде такой конструкции (command > out)>& err где command — команда со всеми её опциями и аргументами, out условное имя файла, в который перенаправляется полезный вывод команды, а & в данном контексте представляет весь остаток от оного, то есть сообщения об ошибках, которые помещаются в файл err. Имя последнего также условно, так что никто не запрещает подменить его сакраментальным Конструкция далеко не столь проста, как в совместимых оболочках типа. Кроме того, для просмотра полезного вывода она потребует ещё
одной команды — вызова какого-либо пейджера вроде less:
% (command > out)>& err ; less out А вот применителям Zsh — проще всех. Им достаточно задать такой глобальный псевдоним alias -g N='2>/dev/null' где -g указывает, что следующий символ (или символы) являют собой на простой псевдонима глобальный, N — его имя, а следующая после равенства последовательность в строгих кавычках — подменяемое им выражение. После чего можно практиковать такое find path3 -name [filename] N И больше не заботиться о фильтрации зёрен от плевел.
Глобальные псевдонимы очень полезны в командных конструкциях перенаправления по конвейеру, например, для поэкранного вывода alias -g L='|less' Пример для «пролистывания» вывода команды dmesg:
$ dmesg L
Для фильтрации по вхождению слова можно задать такой глобальный псевдоним -g G='|grep' После чего использовать его в конструкциях, подобных такой dmesg G raid что выведет нечто вроде 1.434246] md: raid0 personality registered for level 0
[ 1.434376] md/raid0:md0: md_size is 390742016 sectors. Мне весьма полезен глобальный псевдоним вида alias -g W='|wc -m' Поскольку часто требуется прибегать к такой конструкции cat filename W которая в данном случае выведет число символов в текстовом файле — для меня оно важнее числа байта при использовании 16-битной кодировки для преимущественно кириллического текста эти значения не совпадают).
К именам глобальных псевдонимов применяются те же требования, что и к именам псевдонимов обычных они должны быть по возможности короткими,
мнемонически прозрачными. И, разумеется, определения всех постоянно используемых глобальных псевдонимов следует занести в свой кондуитик то есть в Разумеется, здесь не описаны всевозможные случаи употребления глобальных псевдонимов — они лимитируются только потребностями применителя и его фантазией. И, конечно, наказом, который дал атаман
Платов небезызвестному Левше:
Не пей мало, не пей много, а пей средственно.
То есть — не придумывайте глобальных псевдонимов больше, чем сможете запомнить.
Псевдонимы-суффиксы
Кроме обычных и глобальных псевдонимов, в Zsh существует ещё одна их разновидность — псевдонимы «суффиксные», более удачного определения на языке родных осин я не придумал, псевдонимы.
Подобно тому, как добаление к команде alias опции -g с помощью магии превращает обычный псевдоним в глобальный, таки опция -s делает обычный псевдоним «суффиксным». То есть привязывает суффикс имени файла (те,
кто, подобно автору этих строк, затронуты порчей чёрным ом, до сих пор часто называют его расширением) к некоей программе, которая может
сотворить над ним нужное действо. Например, если задать псевдоним такого вида alias -s html=links а затем набрать в CLI такое некто то этот самый некто будет открыт в текстовом браузере Чем, разумеется, возможности «суффиксных» псевдонимов не исчерпываются — как всегда, предел им ставит только фантазия применителя применительно к его задачам. Ограничусь одним примером.
Какой же русский не любит Командера-полуночника? В том числе и потому,
что он — один из сыновей прославленного командера Нортона, имя которого,
в свою очередь, не более чем alias незабвенного лейтенанта Шмидта (история его чудесного спасения из лап царской охранки и последующей блестящей карьере сначала в ВМС Пендостана, а затем в интернациональном софтверном бузиненсе реконструирована нашими замечательными историками из славного Екатеринбурга. Впрочем, со временем наш русский применитель, несмотря навесь свой патриотизм, начинает понимать, что слепая любовь к MC связывает ему руки в операциях с возлюбленной CLI, и хорошо бы с командиром расстаться, как это делают цивилизованные люди без скандалов и истерик.
Но тут возникает проблема MC — один из самых удобных способов просмотра того, из чего состоят файлы пакетов (будь то deb, rpm или что ещё
из серии. Так вот, механизм «суффиксных» псевдонимов Zsh предлагает нам адекватную замену если дать команду, например alias -s deb='dpkg -c' а затем набрать в командной строке такое path3/opera-beta_25.0.1614.11_amd64.deb то мы сразу увидим, что же припасли для нас разработчики этого многими любимого браузера в своём полуподпольном пре-релизе за нумером впрочем, за время сочинения этой книги он стал вполне официальным,
приобретя номер версии 27):
drwxr-xr-x root/root 0 2014-09-13 03:54 ./ drwxr-xr-x root/root 0 2014-09-13 03:54 ./usr/ drwxr-xr-x root/root 0 2014-09-13 03:54 ./usr/bin/ drwxr-xr-x root/root 0 2014-09-13 03:54 ./usr/lib/ drwxr-xr-x root/root 0 2014-09-13 03:54 ./usr/lib/x86_64-linux-gnu/ Понятное дело, что аналогичные псевдонимы можно придумать и для
всяких и пакетов. И, разумеется, наиболее востребованные из них занести в кондуит. то есть в
/.zshrc.
Конфигурирование
В качестве обобщения всего сказанного выше в заключение этого очерка я размещаю свой конфигурационный файл
/.zshrc, прокомментированный, по мере сил, подробно. Этот конфиг существует с 2001 года, кочуя с машина на машину, из системы в систему, постоянно модернизируюсь в соответствие с изменениями моих потребностей и возможностей Zsh. Ив текущем состоянии он обеспечивает все функции и особенности, о которых я говорил ранее, и некоторые другие, которые станут понятными после знакомства с Mint- утилитой пакетного менеджмента Данный конфиг может быть использован полностью или фрагментарно всеми заинтересованными лицами блоки, заключённые в теги пригодны для прямого копирования, за одним исключением, о котором будет сказано в своё время. Однако я отнюдь не призываю к этому, напротив:
настоятельно рекомендую, используя данный конфиг и аналогичные, которые можно найти в Сети, по мере сил и возможности создавать конфиг собственный. Ибо хороший (для конкретного применителя)
/.zshrc — это не результата процесс, и причём процесс преувлекательный.
Как и большинство уважающих себя конфигов, мой начинается с секции,
закрытой комментариями, в которой сообщается, что:

это
/.zshrc — то есть домашний конфигурационный файл для командной оболочки Zsh; используется только в интерактивных её экземплярах содержит крманды для определения псевдонимов, функций, опций и прочих кейбиндингов; укладывается в последовательность считывания конфигов таким образом zshenv, zprofile, zshrc, zlogin.
Всё это потибрено унаследовано от прототипа, распространяющегося разрабочиками Zsh. От себя я добавил лишь такую строку
# Alv's edition for Mint
# Это не значит, что данный конфиг нельзя использовать вне подавляющая часть его строк будет иметь силу в любых дистрибутивах
Linux'а или в системах. Но отдельные его блоки (специально оговоренные) в них просто не будут иметь смысла.
Далее начинается собственно строки определения конфигурируемых параметров. Для удобства восприятия (по крайней мере, моего собственного)
они разделены на блоки целевого назначения. Последовательность блоков,
как и строк внутри них, в большинстве случаев рояля не играет, отдельные
исключения также оговорены специально.
Поскольку всё имеет своё начало, начать свой конфиг мне показалось логичным с блока строк, имеющих отношение к истории команд. Перво- наперво — определение числа команд, сохраняемых в буфере вовремя данного сеанса, имени файла истории, и числа сохраняемых в нём команд
HISTFILE=
/.zhistfile
SAVEHIST=10000 Обычно для HISTSIZE и SAVEHIST рекомендуют принимать одинаковые значения (по умолчанию при автоматическом конфигурировании они равны. Однако если действительно трудно представить ввод более чем тысячи команд в течении сеанса, то вот завесь цикл жизнедеятельности оболочки в системе превысить этот лимит достаточно просто.
Кроме того, надо учесть, что в обоих случаях сохраняются непросто команды, а целые директивы с опциями и аргументами, перенаправлениями и конвейерами, подчас достаточно сложными и редко используемыми. В Zsh имеются очень эффективные механизмы извлечения командных строк из сохранённой истории — не только по именам командно и по их опциями аргументам. Обычно этим мало кто заморчивается, однако в некоторых, пусть и нечастых, случаях такие командные конструкции могут потребоваться вторично. И тогда приятно сознавать, что они храняться в файле истории,
откуда вытащить их всё равно проще, чем пытаться воспроизвести по памяти или отыскивать аналоги в сети.
Так что со временем я, увеличив на всякий пожарный случай вдвое, отвёл подстрок. Кстати, когда предупреждают о том,
что увеличение обоих значений может привести к торможению, следует учитывать, что в памяти постоянно находится только содержимое тогда как из SAVEHIST оно извлекается по мере необходимости. Не говоря уже о том, что при типичных для современных машин объёмах памяти об этом просто смешно говорить.
Имя файла истории я тоже изменяю на
/.zhistfile. Во-первых потому, что иногда по старой памяти балуюсь Tsch, а в ней файл истории по умолчанию также именуется
/.histfile (собственно, оттуда он в Zsh и был потибрен, в хорошем смысле этого слова. А во-вторых, просто для удобства восприятия чтобы все имеющие отношение к Zsh файлы в домашнем каталоге были рядом.
Однако продолжим наши исторические опции. Следующие строки задают условия сохранения команд в файле истории INC_APPEND_HISTORY setopt HIST_IGNORE_ALL_DUPS setopt HIST_REDUCE_BLANKS setopt HIST_IGNORE_SPACE
Они определяют, соответственно. инкрементное наращивание файла истории — без указания этой опции
(или одной из однотипных) его прежние команды будут заменены командами текущего сеанса
2. удаление предыдущих полных дубликатов нововведённых командных конструкций
3. избавление от пустых строк, возникающих после ошибочного нажатия в голом приглашении
4. удаление лишних пробелов из командной конструкции. Зачем нужны пункты 2–4 — ясно без комментариев. А вот о пункте м надо сказать несколько слов. Ибо он непросто обеспечивает наращивание файла истории (для этого было бы достаточно опции, APPEND_HISTORY), но делает это входе сеанса, не дожидаясь его завершения. В результате команда,
введённая водном терминальном окне или вкладе терминала, будет доступна в истории команд другого терминала или вкладки (хотя и с некоторой задежкой).
Далее следуют две очень важные строки, определяющие одну из полезнейших возможностей Zsh — тот самый механизм history-substring- search, о котором говорилось ранее "^[[A" up-line-or-search bindkey "^[[B" down-line-or-search Следующие две строки касаются уже простого пролистывания истории в командной строке, позволяя делать это клавишами PageUp и PageDown (а не только стрелками Up и Down, которые в этом качестве работают всегда и везде "^[[5
" up-line-or-history bindkey "^[[6
" down-line-or-history Этими строками перебрасывается логический мостик к определению кейбиндингов для клавиш, которые в Zsh по умолчанию работают
«неправильно» в большинстве терминалов (если не во всех. У меня это Home,
End, Delete — их поведение исправляется такими, соответственно, строками "^[OH" beginning-of-line bindkey "^[OF" end-of-line bindkey "^[[3
" delete-char Это как раз пример тех строк, которые as is копировать ненужно. Во- первых, в общем случае, могут не работать другие клавиши (скорее, не только эти. Во-вторых же и главных, в более иных терминалах коды тех же клавиш могут быть совсем другими. Какими — легко определить, нажав, а затем неправильную клавишу. Именно таким образом получены коды для Home, End ив системе, в которой сочиняются эти строки.
Теперь — опции, определяющие магию Zsh при навигации по файловой системе /home/current/alv.me /etc) setopt autocd Первая строка позволяет с помощью команды cd переходить в подкаталоги перечисленных каталогов, не набирая никаких путей, ни относительных, ни абсолютных, вторая же — обходиться без команды На грани между опциями навигации и автодополнения находятся такие строки menucomplete zstyle ':completion:*' menu select=1 _complete _ignored _approximate Они в паре обеспечивают «менюобразный» вывод списка доступных дополнений по нажатию клавиши табуляции. И это как раз тот случай, когда последовательность строк имеет значение.
Аналогично и со следующими строками — теми самыми, которые обеспечивают волшебство развёртывания сокращённого ввода пути в полный -Uz compinit compinit Расширенные подстановки и дополнения обеспечиваются вот этими строками extendedglob nomatch notify zstyle ':completion:*' completer _expand _complete _ignored _correct
_approximate Строка zstyle ':completion:*' use-compctl false знаменует собой отречение от старого мира — системы дополнения в пользу новой системы Строка zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}' устанавливает равноправие при дополнениях символов нижнего регистра с верхним.
А строка zstyle :compinstall filename '/home/zsh/.zshrc' фиксирует файл, в который compinstall (функция автоматического
конфигурирования compsys) будет вносить свои изменения при грядущих её
вызовах (если они, конечно, будут).
Пора переходить к псевдонимам. Сначала — серия таковых для команд манипуляции файлами, предписывающие запрос подтверждения на таковые или, напротив, форсированное исполнение, в зависимости от ситуации mv='mv -i' alias cp='cp -iR' alias cpr='cp -fR' alias rm='rm -i' alias rmf='rm -f' alias rmrf='rm -fR' Оказывается, что для одной-единственной команды ls можно придумать больше псевдонимов, чем для всех файломанипулирующих команд, вместе взятых ls='ls -F' alias ll='ls -lh' alias la='ls -A' alias li='ls -ial' alias lsd='ls -ld *(-/DN)' alias lsa='ls -ld .*' На самом деле их можно придумывать ещё и ещё — этот тот необходимый минимум, который я в состоянии запомнить без вреда для рассудка.
Расшифровывать псевдонимы не буду — кому надои так могут сорвать с них маски, а кто не знает — так ему это и не нужно.
Далее идёт серия псевдонимов для различных команд и утилит разного назначения. Здесь также расшифровка будет лишней. Ибо они или оболее- менее общеприняты h=history alias df='df -h' alias du='du -h' Либо обусловлены давними привычками (как, например, образный вывод команды less):
alias less='less -M'
alias wget='wget -c' alias nano='nano -$' Либо связаны со спецификой деятельности wcl='wc -l' alias wcw='wc -w' alias wcm='wc -m' alias wcc='wc -c' Так что можно переходить к следующей убойной фиче Zsh — определению глобальных псевдонимов -g N='2>/dev/null' alias -g L='|less' alias -g G='|grep' alias -g W='|wc -m' Где, впрочем, комментарии тоже излишни.
А посему перехожу к тем самым дистрибутив-специфическим блокам,
которые я предназначил для применения в Mint. Это — псевдонимы для субкоманд её утилиты apt, призванные минимизировать ввод при наиболее частых действиях по пакетному менеджменту aptin='apt install --yes' alias apter='apt purge' alias aptup='apt update' alias aptug='apt upgrade' alias aptse='apt search' alias aptsh='apt show' Псевдонимы для внутренних команд apt из APT также имеет смысл определить, по крайней мере один, для получения списка инсталлированных пакетов aptlist='/usr/bin/apt list --installed' Смысл этих псевдонимов будет ясен после знакомства с очерком об утилите apt. Ив них нет ничего специфичного. В отличие от альтернативного метода, основанного на псевдонимах глобальных, которые определяются для соответствующих аргументов команды sudo. Правда, особенность реализации утилиты apt в Mint такова, что она не требует ввода этой команды в явном виде. И потому здесь у меня осталась единственная строка для псевдонима
команды добавления репозиториев:
alias -g Ar='add-apt-repository' Хотя я и утверждал не так давно, что приглашение оболочки — нечто вроде вешалки для театра, сам добрался до этой темы только к концу своего конфига. Однако вот — обычное левосторонне приглашение:
#PROMPT='%B[%n]$=>%b ' Вторичное приглашение:
#PROMPT2='%i%U> ' Правостороннее приглашение' %B[%
]%b ' А вот это — альтернативы, которыми я баловался вовремя сочинения раздела про приглашения. Все они начинаются с такой пары строк -Uz promptinit promptinit После которых вызывается уже одна из конкретных тем fade prompt fade white grey blue
#prompt clint Естественно, что остальные строки должны быть закомментированы.
Осталось немного — всякая всячина. Например, предотвращение выхода из оболочки после случайного нажатия Control+D в пустой командной строке IGNORE_EOF Отключение раздражающего звукового сигнала при ошибках набора NO_BEEP Фиксация образного поведения клавиш (хотя это итак имеет место быть по умолчанию -e И под занавес — определение пары переменных среды, для начала умолчального пейджера. Хотя я не так давно говорил, что расширенное перенаправление делает его практически ненужным, но, кроме всего прочего, это ещё и средство для просмотра страниц PAGER="less"
И умолчальный редактор несмотря на свою любовь к Joe, навыки работы с ним я утратил напрочь, поэтому так EDITOR="nano" Вот вроде и всё. Остаётся последний дистрибутив-специфичный стришок исправление нехорошего поведения history-substring-search в унаследованного от Ubuntu. А точнее, поведения никакого — эта фича без дополнительных мер просто не работает. Благо меры эти очень просты создание файла
/.zshenv с единственной строкой Вот теперь действительно всё — с конфигурированием Zsh «мануальным»
способом покончено.
Пакеты и репозитории
Все дистрибутивы Linux, и Mint тут не исключение, организованы по пакетному принципу. Точно также, в виде пакетов, распространяются и любые дополнительные программы для них, создаваемые независимыми разработчиками. И потому одна из важных задач пользователя — это интеграция пакетов в свою систему. Она решается средствам управления пакетами, предназначенным для установки, обновления и удаления программ,
учета и разрешения их зависимостей. Однако, прежде чем говорить о таких средствах, не худо посмотреть, что такое пакеты вообще, пакеты в частности и пакеты дистрибутива Mint в особенности. А также — каким образом они организованы в репозитории.
Пакеты, зависимости, библиотеки
Пакеты — это своего рода программные кванты, на которые делится система или дистрибутив. Это могут быть и простые монофункциональные утилиты (например, строчный текстовый редактор ed или архиватор более или менее обширные наборы функционально связанных программ
(скажем, coreutils) или составные части огромных программных комплексов
(примером чему — Cinnamon, о котором столько гворилось в прошлых очерках).
Термин пакет (английское package) употребляется в двух смыслах как авторский набор исходных текстов, созданный разработчиком программы, и как комплект скомпилированных из него исполняемых программ и всех их служебных файлов, собранный майнтайнерами дистрибутива или вообще третьими лицами. Пакеты в первом смысле называются исходниками или вообще сырцами (от английского Source), во втором — бинарниками. Далее в этой книге речь пойдёт почти исключительно о пакетах во втором понимании этого термина.
Бинарные пакеты специфичны для семейств некогда родственных дистрибутивов, почему часто говорят о системах rpm based или deb based. Но даже если они собраны водном формате (например, rpm или deb), бинарные пакеты из разных дистрибутивов далеко не всегда совместимы в рамках одной системы. Впрочем, к формату deb, принятому в дистрибутиве Mint и потому в интересующему нас больше всех остальных, вместе взятых, это относится в наименьшей степени его пакеты сохраняют почти полную бинарную совместимость с пакетами родительской Ubuntu и частичную — с
пакетами прародительского Debian'а.
Ключевым для бинарных, или дистрибутивных, пакетов является понятие зависимостей. Суть его в том, что пакет packagename1 для сборки, установки и (или) функционирования требует наличия в системе пакета тот, в свою очередь, может потребовать пакета packagename3, итак далее.
Следует различать зависимости жёсткие и мягкие. Удовлетворение первых абсолютно необходимо для сборки и функционирования данного пакета. Так, практически любая программа использует главную системную библиотеку glibc (или libc), любое приложение для системы X — одну из главных Иксовых библиотек старые — xlib, новые — xcb, любая интегрированная рабочая среда — одно из двухосновных семейств высокоуровневых библиотек, Qt/kdelibs или Мягкие зависимости данного пакета не критичны для его функционирования — удовлетворение их лишь добавляет ему дополнительные функции (например, печати и сканирования для офисных и графических приложений) или возможности (скажем, доступ к файлам данных определённых форматов для той же графики или мультимедиа).
В формате бинарных пакетов предусмотрено более дробное разделение
«мягких» зависимостей, но об этом подробнее будет говориться чуть позже. А
пока замечу, что часто приходится учитывать итак называемые конфликтующие зависимости — то есть альтернативные по назначению пакеты, неспособные ужиться водной системе.
Понятие зависимостей пронизывает насквозь совместимые системы, и особенно важно для свободных их представителей. В тоже время пользователи Windows с ним сталкиваются очень редко, и потому постижение его вызывает у них определённые трудности.
Традиционная модель разработки программ (то, что задумчиво именуют UNIX Way) характеризуется ярко выраженным стремлением не множить сущности без крайней необходимости. Или, говоря попросту, не изобретать велосипеды. То есть если требуемая разработчику данной программы функция уже реализована и включена в какую-либо распространённую библиотеку, то наш разработчик скорее всего этой библиотекой и воспользуется, а не будет переписывать ее с нуля. Благо,
поскольку все распространённые и общеупотребимые библиотеки открыты, он имеет полную возможность это сделать.
Ведь все программы, вне зависимости от их назначения, неизбежно должны выполнять некоторые однотипные действия, как то открыть файл, записать его, вывести на экран его содержимое, итак далее, вплоть до закрытия.
Сущность таких действий не меняется, чтобы программа ни делала. И потому нет никакого смысла программировать такие манипуляции каждый раз заново.
Вот их, как правило, поддаваясь смертному греху лености, и не программируют с нуля. А объединяют соответствующие директивы в отдельные программные комплексы, именуемые библиотеками (Сами по себе они к автономному исполнению непригодны. Однако любая программа, при необходимости совершить одно из типовых действий,
вызывает из такой библиотеки некий фрагмент кода, содержащий требуемую последовательность директив.
Библиотеки обычно привязаны к определённым языкам программирования,
синтаксису которого подчиняются описания директив, так называемых функции. Поскольку наиболее употребимым в системах и их приложениях является язык C, то его функции и требуются чаще всего. Они собираются в главную системную библиотеку, которая почти во всех дистрибутивах Linux именуется Однако главной системной библиотекой список не исчерпывается. В UNIX- подобных системах при создании пользовательских интерфейсов используются библиотеки свойств терминала (например, ncurces) для консольных программ и библиотеки, описывающие процедуры отрисовки окон и управления ими — для графических программ системы X, библиотеки интерфейсных элементов и графических примитивов более высокого уровня, Qt, Gtk), библиотеки описания графических и мультимедийных форматов файлов и тому подобные сборники. Иными словами, существует тенденция к вынесению в разделяемые библиотеки всех повторяющихся действий и элементов, какие только возможно.
Если библиотек, используемых в программах для консольного режима, не так много, они достаточно универсальны и легко поддаются учту, то с библиотеками для обеспечения графического режима существенно сложнее.
Даже простое перечисление их заняло бы немало места. Поэтому ограничусь констатацией факта, существенного для нашей темы. Обе основные рабочие среды дистрибутива Mint, MATE и Cinnamon, а также штатные приложения обеих редакций базируются на библиотеках Gtk — й и й версий,
соответственно. К ним же примыкает и левая редакция с Xfce. И лишь KDE- редакция Mint основывается на библиотеках Qt и kdelibs. Поскольку основной героиней этого романа является Cinnamon, то дальше речь пойдёт в основном о пакетах, связанных зависимостями с библиотекой Gtk 3.

Каталог: wp-content -> uploads -> 2016
2016 -> Государственное областное бюджетное
2016 -> В. П. Зинченко писал о том, что если человек в детстве не дополучил некую норму участия в игровом времяпрепровождении, он приобретает социально-психологическую ущербность вроде «игровой дистрофии», которую в последу
2016 -> Общешкольное родительское собрание «Об ответственности родителей за воспитание детей»
2016 -> 1 июня 2016 года Международный день защиты детей 1 июня
2016 -> «Формирование социально-нравственной позиции дошкольников посредством введения сказочных сюжетов в компьютерные дидактические игры»
2016 -> Принята Утверждена
2016 -> Конкурс по разработке компьютерных игр патриотической направленности «патриот by»


Поделитесь с Вашими друзьями:
1   ...   11   12   13   14   15   16   17   18   ...   30


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал