git-gui

Одна из двух официально-поставляемых вместе с Git графических утилит, созданных с использованием Tcl/Tk. Позволяет управлять коммитами, ветками и удалёнными репозиториями.

gitk

Вторая часть официального графического инструментария Git. Позволяет подробно просматривать историю репозитория, включая графическую визуализацию ветвления.

Giggle

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

Git Cola

Git Cola предлагает функциональность схожую с git-gui.

gitg

gitg предоставляет возможность как просмотра истории репозитория, так и управления коммитами. Просмотр истории реализован похожим на gitk и giggle образом. Дополнительно предлагает графическое представление количества сделанных изменений. Управление коммитами похоже на то, как это реализовано в git-gui, за исключением некоторых функций.

QGit

QGit предлагает функциональность gitk, используя интерфейс построенный на базе QT.

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

Принцип работы

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

Установка

Установить Gitosis можно как из пакетов (как минимум в актуальных Ubuntu и Debian он есть) или же «вручную» с Github. И в том, и в другом случаях вам сперва понадобится системная учётная запись, от имени которой будет работать Gitosis. Я обычно выбираю что-нибудь короткое и понятное для имени учётной записи:

$ sudo adduser --system --shell /bin/sh --gecos 'git version control' --group --disabled-password --home /home/git git

Обратите внимание на опцию --disabled-password, которая не даст этой учётной записи возможности аутентифицироваться в системе, используя пароль. Аутентификация будет возможно только при помощи ключа или программы su. Теперь вам необходимо скопировать отрытый ключ пользователя, который будет администрировать будущий Gitosis-сервер и скопировать его в домашний каталог (или куда-нибудь, откуда вышесозданный пользователь сможет его достать, файл с ключом понадобится лишь временно) только созданного пользователя. Я, например, обычно использую свой RSA-ключ, которым пользуюсь для аутентификации на всех серверах, чтобы не запутаться. Сначала копируем файл открытого ключа с локальной системы на сервер в какой-нибудь каталог:

$ scp ~/.ssh/id_rsa.pub ashep@myserver.com:/home/ashep/tmp

после чего, уже на сервере, делаем его доступным пользователю git:

$ sudo mkdir /home/git/tmp
$ sudo mv /home/ashep/tmp/id_rsa.pub /home/git/tmp/
$ sudo chown git:git /home/git/tmp/id_rsa.pub

Теперь можно приступать к установке. Если необходимо установить Gitosis из пакета, всё просто:

$ sudo apt-get install gitosis

«Ручная» установка также особых сложностей не вызывает (обратите внимание, у вас в системе должен быть установлен пакет python-setuptools):

$ git clone git://eagain.net/gitosis
$ cd gitosis
$ sudo python setup.py install

После того, как Gitosis установлен, необходимо инициализировать окружение, в котором он будет работать. Входим в систему под пользователем git, которого создали ранее:

$ sudo -i -u git

И, оказавшись в домашнем каталоге пользователя git, выполняем инициализацию:

$ gitosis-init < ~/tmp/id_rsa.pub
Initialized empty Git repository in /home/git/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /home/git/repositories/gitosis-admin.git/

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

$ rm ~/tmp/id_rsa.pub

Последним шагом убедитесь, что файл  repositories/gitosis-admin.git/hooks/post-updatе является исполняемым, иначе Gitosis не сможет обновлять конфигурацию:

$ chmod 0755 ~/repositories/gitosis-admin.git/hooks/post-update

Вот и всё. Ваш Gitosis-хост готов принимать посетителей.

Управление Gitosis

Всё конфигурирование Gitosis базируется на работе с git-репозиторием, содержащим конфигурацию и ключи пользователей. Звучит слегка неожиданно, но давайте посмотрим, что это значит на практике. Находясь на вашем локальном хосте, под учётной записью, открытый ключ которой вы скопировали ранее, клонируйте следующий репозиторий с вашего Gitosis-сервера:

$ git clone git@myserver.com:gitosis-admin.git
Cloning into gitosis-admin...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 0), reused 5 (delta 0)
Receiving objects: 100% (5/5), done.

Обратите внимание на имя учётной записи, от которой мы подключаемся к серверу. Перейдите в каталог с репозиторием и откройте в текстовом редакторе файл gitosis.conf:

[gitosis]
[group gitosis-admin]
writable = gitosis-admin
members = ashep

Файл имеет традиционную ini-структуру и используется для конфигурирования Gitosis на сервере. Не забывайте о том, что выполнять конфигурацию Gitosis вы должны только таим способом!

Итак, представим, что вам необходимо создать новый репозиторий, который будет называться myproj, и предоставить к нему доступ на чтение/запись пользователям mike и bob. Добавьте ещё одну секцию в файл gitosis.conf:

[group myteam]
writable = myproj
members = mike bob

Здесь в начале секции объявляется группа с именем myteam, в которую входят пользователи перечисленные в значении параметра members и имеющие доступ на запись в репозиторий myproj. Интересующиеся могут увидеть пример возможных опций конфигурационного файла Gitosis здесь.

Далее, поместите открытые ключи новых пользователей в каталог keydir админ-репозитория. Обратите внимание на имена файлов ключей: они должны состоять из имён пользователей, которых вы перечислили в значении параметра members, плюс суффикс «.pub».

$ cp ~/tmp/mike.pub ~/tmp/bob.pub ./keydir

Добавьте файлы ключей, а также файл конфигурации в индекс:

$ git add ./keydir/* ./gitosis.conf

И сделайте коммит:

$ git commit -m 'Новый проект myproj, который делают mike и bob'

Теперь осталось лишь обновить конфигурацию на сервере:

$ git push

Создание репозитория

Теперь указанные пользователи могут работать с репозиторием. Представим, что mike оказался первым, кому выпала честь инициализировать репозиторий на сервере. Ему необходимо перейти в каталог с локальным репозиторием, добавить новый remote-сервер:

$ cd myproj
$ git remote add origin git@myserver.com:myproj.git

после чего выполнить push репозитория:

$ git push origin master

Если всё настроено корректно, mike получит сообщение об успешной синхронизации нового репозитория.

Клонирование репозитория

Здесь тоже всё традиционно:

$ git clone git@myserver.com:myproj.git

Ссылки

• Gitosis на ArchWiki

Уверен, эта работа знакома практически каждому, кто хоть чуточку интересовался Git, однако нередко бывает так, что очевидное и не замечаем. Вот она, в большом разрешении:

Как это работает

Чтобы тем, кто впервые слышит о Zen Coding, было сразу понятно, какие «плюшки» они получат в результате, рассмотрим пару примеров.

Допустим, вы начинаете верстать новый HTML5-документ. С чего вы начнёте? Как правило с создания «скелета» документа, включающего в себя несколько строк. От документа к документу этот «скелет» остаётся одним и тем и набирать его вручную — занятие не из разряда полезных. Да, можно хранить шаблон где-то в файле и при создании нового документа просто копировать его оттуда при помощи буфера обмена. Но здесь опять возникает неприятный момент: найти файл, открыть, скопировать...

Пользователи Zen Coding имеют возможность создать новый HTML5-документ следующим образом. В новом файле вводится аббревиатура:

html:5

Нажимается определённая клавиатурная комбинация, и вуаля:

<!DOCTYPE HTML>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title></title>
</head>
<body>
</body>
</html>

Или, например, вам нужно создать маркированный список из 5 элементов? Нет ничего проще:

ul>li*3

лёгким движением руки превращается в:

<ul>
	<li></li>
	<li></li>
	<li></li>
</ul>

Впечатляет? И это далеко не всё, что умеет Zen Coding! Прежде, чем приступать к изучению возможностей библиотеки, установим необходимый плагин в Vim.

Установка Zen Coding в Vim

Список плагинов Zen Coding для различных редакторов вы можете найти на странице загрузок проекта. Плагин для Vim живёт на GitHub и вы можете либо скачать zip-архив с плагином, либо получить его при помощи git:

$ git clone http://github.com/mattn/zencoding-vim.git

Установка плагина заключается в копировании двух каталогов в каталог ~/.vim:

$ mkdir -p ~/.vim
$ cp -Rv zencoding-vim/autoload ~/.vim
$ cp -Rv zencoding-vim/plugin ~/.vim

Аббревиатуры

Принцип работы Zen Coding основан на т. н. аббревиатурах — сокращениях, из которых Zen Coding умеет строить код, или «расширять аббревиатуры».

Пара простых примеров расширения аббревиатур приведены в начале заметки, а сейчас посмотрим, как это работает в Vim.

Откройте новый файл:

$ vim index.html

перейдите в режим вставки и введите:

теперь (обратите внимание на то, где находится курсор), используя клавиатурную комбинацию <c-y>, (Ctrl + y + запятая), расширьте аббревиатуру:

Zen Coding «знает» массу HTML-тэгов и корректно их расширяет из аббревиатур. Например, аббревиатура

a

будет расширена в

<a href=""></a>

а, например

img

будет расширена в

<img src="" alt="" />

поскольку аббревиатуры совпадают HTML-тэгами, сложности в их использовании возникнуть не должно.

Селекторы

Расширение аббревиатур — это, конечно, здорово, однако имея в распоряжении только их, сильно производительность кодинга не увеличишь. К счастью, Zen Coding умеет работать с селекторами (очень напоминают и максимально приближены по смыслу к селекторам в CSS).

Именно селекторы использовались во втором примере из начала статьи, когда строился список из пяти элементов. Сейчас давайте рассмотрим использование селекторов подробнее.

# (решётка)

Этот селектор, как вы уже могли догадаться, используется для определения идентификаторов элементов. Например:

div#header

будет преобразовано в

<div id="header"></div>

. (точка)

Этим селектором определяется CSS-класс элементов. Например:

p.first

будет преобразовано в

<p class="first"></p>

> (символ «больше»)

Этот селектор используется, когда вам нужно определить вложенный элемент. Например:

ul>li

будет преобразовано в

<ul>
	<li></li>
</ul>

или, например:

table>tr>td

будет преобразовано в

<table>
	<tr>
		<td></td>
	<tr>
</table>

[] (квадратные скобки)

На примере тэга img вы увидели, что Zen Coding умеет автоматически вставлять атрибуты некоторых тегов. Используя селектор [], вы можете самостоятельно определять атрибуты тэгов и их значения. Например:

a[href=http://www.ashep.org title="Cool Site"]

будет преобразовано в

<a href="http://www.ashep.org" title="Cool Site"></a>

или, например:

div[myprop1="My Value One" myprop2]

будет преобразовано в

<div myprop1="My Value One" myprop2=""></div>

| (вертикальная черта)

Zen Conding, начиная с версии 0.6, поддерживает использование т. н. фильтров, которые позволяют выполнять некоторые преобразования после того, как выражение Zen Coding будет преобразовано. Давайте посмотрим, как это работает, на примере использования фильтра «e» (escape):

p.first|e

будет преобразовано в

<p class="first"></p>

С полным списком фильтров Zen Coding вы можете ознакомиться на соответствующей странице проекта.

+ (плюс)

Этот селектор по разному рассматривается в двух вариантах использования. Первый вариант, это когда необходимо создать несколько невложенных элементов подряд. Например

p+div+p

будет преобразовано в

<p></p>
<div></div>
<p></p>

Во втором случае селектор «+» используется для построения минимально-завершённой структуры некоторых элементов. Например:

table+

будет преобразовано в

<table>
	<tr>
		<td></td>
	<tr>
</table>

* (звёздочка)

Как можно догадаться, глядя на символ селектора, он используется в качестве мультипликатора элементов. Например:

div*3

будет преобразовано в

<div></div>
<div></div>
<div></div>

$* (доллар и звёздочка)

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

div#myitem-$*3

будет преобразовано в

<div id="myitem-1"></div>
<div id="myitem-2"></div>
<div id="myitem-3"></div>

Объединение селекторов

Конечно же, вся мощь Zen Coding кроется в одновременном использовании селекторов, позволяющем за один присест генерировать сколь угодно большие объёмы структурированного кода. Например:

img.small.square#img1

будет преобразовано в

<img id="img1" src="" alt="" class="small square" />

а выражение

table>tr>td*3

развернётся в

<table>
	<tr>
		<td></td>
		<td></td>
		<td></td>
	<tr>
</table>

Или, например:

select>option#username-$*3

превратится в

<select id="" name="">
    <option id="username-1" value=""></option>
    <option id="username-2" value=""></option>
    <option id="username-3" value=""></option>
</select>

Резюме

Zen Coding является отличным инструментом для повышения производительности труда верстальщиков XML-подобных документов, и потраченные 15 минут на изучение и установку плагина в вашем редакторе с лихвой окупятся уже через час. Получить больше информации вы, как всегда, можете на сайте проекта по адресу http://code.google.com/p/zen-coding/. В одной из следующих заметок я расскажу о некоторых фишках плагина Zen Coding для Vim.

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

Недавно наткнулся в Сети на неплохую подборку частых полезностей, которую можно распечатать и использовать в настольном варианте, чем радостно делюсь с читателями. Блог автора, на всякий случай: http://freeworld.posterous.com. Также есть устаревшая онлайн-версия, для тех кому вдруг не подходит PDF-вариант.

Ещё одна шпаргалка размером с простыню, но весьма структурированная и мегаполезная есть здесь. На стену в полном объёме не вывесишь, но деражть на рабочем столе в виде PDF — вполне.

Для почитателей же «настольных» вариантов шпаргалок существует масса разнообразных обоев. Из интересных полезняшек, найденных в Сети, хочу поделиться популярной обойкой с коллекцией команд UNIX/Linux, разбитых по категориям:

небольшой подборкой памятной информации для убунтоидов:

и коллекцией шорткатов для пользователей Ubutu Unity:

Специально для защитников авторских прав: обои найдены в Сети и точное авторство каждого из них установить сейчас уже трудно, да и не вижу смысла. Гугл в помощь! ;)

Утилита stat является частью GNU Coreutils, а значит должна быть доступна в любом современном Linux-дистрибутиве. Задачей stat является вывод информации об одном или более файлов, а также о файловых системах. При помощи утилиты вы сможете узнать, например, сколько блоков диска выделено для хранения файла, сколько индексных дескрипторов доступно на той или иной ФС, а также многое другое. Основным преимуществом stat является то, что вы можете получать информацию в любом удобном для вас виде, что даёт возможность очень легко получать нужные данные и манипулировать ими в сценариях оболочки.

В общем случае формат вызова stat таков:

stat [опция]... [путь]...

Давайте, например, посмотрим на вывод информации о /etc/passwd:

$ stat /etc/passwd
 File: `/etc/passwd'
 Size: 2154          Blocks: 8          IO Block: 4096   regular file
Device: 802h/2050d    Inode: 786548      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-06-20 19:00:01.606463000 +0300
Modify: 2011-05-24 20:39:21.836670002 +0300
Change: 2011-05-24 20:39:21.860670002 +0300

Из полученного вывода можно определить следующее:

• файл имеет размер 2154 байта, занимает восемь 512-байтных блоков ;
• размер блока ФС, на которой расположен файл, при операциях ввода/вывода составляет 4 килобайта;
• идентификатор устройства, на котором расположен файл: 802h (шестнадцатеричный) или 2050d (десятичный);
• номер индексного дескриптора файла — 786548;
• файл не имеет жёстких ссылок (одна ссылка в отчёте stat — и есть сам файл);
• режим доступа к файлу: 0644;
• владелец файла — root, группа-владелец — root;
• время последнего доступа к файлу: 2011-06-20 19:00:01;
• время последнего изменения файла: 2011-05-24 20:39:21;
• время последнего изменения индексного дескриптора файла: 2011-05-24 20:39:21;

Как уже говорилось, вы можете явно определять, какую информацию нужно выводить, а какую нет. Для этих целей в программе предусмотрена опция '--printf', после которой необходимо указать нужный вам формат вывода. Например, следующая команда выведет, разделив знаком табуляции: имя файла, его размер в байтах, размер в блоках, номер его inode и тип файла с точки зрения ОС. Вывод будет завершён символом новой строки:

$ stat --printf '%n\t%s\t%b\t%i\t%F\n' /etc/passwd
/etc/passwd    2154    8    786548    regular file

Подобным образом вы можете выводить информацию сразу о нескольких файлах, перечислив пути к ним в качестве аргументов:

$ stat --printf '%n\t%s\t%b\t%i\t%F\n' /etc/passwd /dev/dvd /dev/sg0
/etc/passwd    2154    8    786548    regular file
/dev/dvd       3       0    6997      symbolic link
/dev/sg0       0       0    5519      character special file

или же, естественно, вы можете использовать wildcards оболочки:

$ stat --printf '%n\t%s\t%b\t%i\t%F\n' /tmp/*
/tmp/gnucash.trace         0       0    392110    regular empty file
/tmp/hsperfdata_ashep      4096    8    392064    directory
/tmp/keyring-XJ5URh        4096    8    392007    directory
/tmp/mc-ashep              4096    8    413063    directory
/tmp/orbit-ashep           4096    8    391967    directory
/tmp/orbit-gdm             4096    8    391960    directory
/tmp/plugtmp               4096    8    412871    directory
/tmp/pulse-rwNQrxNhZvCt    4096    8    392060    directory
/tmp/ssh-PYSARO7941        4096    8    391958    directory
/tmp/virtual-ashep.ENf1ty  4096    8    392104    directory

Подробную информацию обо всех возможных параметрах, которые можно перечислять в опции '--format' можно получить на странице руководства утилиты.

stat может быть использована также для получения информации о файловых системах. Для этого программе нужно передать опцию '-f':

$ stat -f /
 File: "/"
 ID: 5d2e58a2f8a69ac2 Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 3844964    Free: 1684537    Available: 1489222
Inodes: Total: 977280     Free: 510081

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

• идентификатор файловой системы: 5d2e58a2f8a69ac2;
• максимальная длина имени файла: 255 символов;
• тип ФС: ext2/ext3;
• размер блока: 4 килобайта;
• общее количество блоков: 3844964, свободных: 1684534, доступных не суперпользователю: 1489222;
• общее количество индексных дескрипторов: 977280, свободных: 510081.

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

$ stat --printf '%i\t%d\t%b\n' -f /
5d2e58a2f8a69ac2    510081    3844964

Файловые системы, как правило, состоят из двух частей:

1. метаданных, т. н. данных о данных;
2. самих данных.

Первый пункт звучит довольно забавно: «данные о данных», однако он является ключевым моментов в работе файловых систем. Если быть более точным, метаданные содержат информацию о данных, хранящихся на диске, таких как имена файлов, время их создания, права доступа и так далее. Роль метаданных крайне важна, поскольку без них файловая система представляла бы из себя лишь набор байт, в котором невозможно было бы определить что и где физически находится на диске.

Индексный дескриптор

В общем случае в файловых системах операционных систем *NIX с каждым файлом и каталогом связан соответствующий дескриптор — inode, который обычно обозначается целым числом и в котором хранятся метаданные. Происхождение термина «inode» точно неизвестно. Из статьи на Википедии, согласно словам Дениса Ритчи, одного из первых разработчиков UNIX-систем:

Честно говоря, я мало об этом знаю. Это был всего лишь термин, который мы начали использовать. 'Индекс', как я полагаю, использовался из-за несколько необычной структуры файловой системы, хранившая информацию о доступе к файлам в плоском (двумерном) массиве на диске, а вся информация об иерархии каталогов хранилась отдельно. Таким образом, и-номер являлся индексом в этом массиве, и-нод — выбранным элементом массива. (Приставка 'и-' использовалась в первой версии руководства; со временем дефис перестали употреблять).

Каким образом создаются дескрипторы и вообще, создаются ли они, зависит от реализации конкретной файловой системы. Некоторые файловые системы создают дескрипторы в момент создания файловой системы, в результате располагая фиксированным количеством индексных дескрипторов, то есть фиксированным пределом количества файлов, хранящихся в ФС.  Так, например, работает файловая система Ext-3. Таким образом получается, что вы в какой-то момент не сможете создать файл, даже если свободного пространства на диске будет достаточно. Такое случается крайне редко, но, тем не менее, не исключено. Если, используя такую файловую систему, вам понадобиться больше индексных дескрипторов, вам придётся заново создавать ФС, средств увеличить количество inode без потери данных нет.

Одним из способов обойти вышеописанное поведение ФС являются экстенты и/или динамическое выделение индексных дескрипторов. Такие системы могут динамически расширяться и/или увеличивать количество inode.

Индексные дескрипторы не являются чем-то мистическим, они являются частью Linux. Вы можете увидеть их присутствие, например при помощи команды 'ls -i':

laytonjb@laytonjb-laptop:~/Documents/FEATURES/STORAGE088$ ls -il
total 1024
8847368 -rw-r--r-- 1 laytonjb laytonjb 115020 2011-04-24 07:33 Figure_1.png
8847366 -rw-r--r-- 1 laytonjb laytonjb  39200 2011-04-24 07:38 Figure_2.png
8847361 -rw-r--r-- 1 laytonjb laytonjb  30691 2011-04-24 07:40 Figure_3.png
8847367 -rw-r--r-- 1 laytonjb laytonjb  28835 2011-04-24 07:42 Figure_4.png
8847363 -rw-r--r-- 1 laytonjb laytonjb 115103 2011-04-24 07:43 Figure_5.png
8847362 -rw-r--r-- 1 laytonjb laytonjb 125513 2011-04-24 07:44 Figure_6.png
8847365 -rw-r--r-- 1 laytonjb laytonjb  77831 2011-04-24 07:44 Figure_7.png
7790593 -rw-r--r-- 1 laytonjb laytonjb  15632 2011-04-26 19:40 storage088.html
8847364 -rw-r--r-- 1 laytonjb laytonjb    183 2011-04-24 07:33 text1.txt
3089319 drwxr-xr-x 2 laytonjb laytonjb   4096 2011-04-24 07:54 TRIM_WORKS
5554211 -rw-r--r-- 1 laytonjb laytonjb 449110 2011-04-24 07:52 trim_works.tar.gz

Числа в первом столбце и есть номера inode. Также обратите внимание на каталог "TRIM_WORKS”, который тоже имеет номер inode, связанный с ним.

Linux, которая в большинстве реализаций является POSIX-совместимой ОС, требует обязательного наличия атрибутов файла, располагающегося на ФС, в частности:

• размер файла в байтах;
• идентификатор устройства;
• идентификатор владельца файла;
• идентификатор группы-владельца файла;
• режим доступа к файлу, определяющий кто и какой доступ имеет к файлу;
• дополнительные системные и пользовательские флаги, которые дополнительно могут ограничивать доступ к файлу и его модификацию;
• таймштампы, отражающие время модификации индексного дескриптора (ctime, changing time), время модификации содержимого файла (mtime, modification time) и время последнего доступа к файлу (atime, access time);
• счётчик для учёта количества жёстких ссылок на файл;
• указатели на физические блоки диска, в которых хранится содержимое файла (об этом ниже).

Любая POSIX-совместимая Linux ОС должна хранить указанную информацию в индексных дескрипторах или же быть способной представлять эту информацию так, будто бы она хранится в них. Например, ReiserFS не использует традиционные inode. Вместо этого для хранения метаданных в ReiserFS используется комбинированное B±дерево, к роли ключей которого выступают универсальные идентификаторы объектов. Однако при запросе информации ReiserFS предоставляет её в POSIX-совместимом виде.

Структура указателя индексного дескриптора

Согласно POSIX, в файловой системе есть элемент, называемый inode pointer structure — структурой указателя индексного дескриптора. Как говорилось выше, inode хранит метаданные, включая список блоков на диске, в которых располагается непосредственно содержимое файла. Структура указателя индексного дескриптора используется для извлечения списка дисковых блоков, ассоциированных с файлом.

Согласно описанию с Википедии, эта структура хранит 11 или 13, а в самых современных ФС — 15 указателей. Назначение этих указателей следующее:

• 12 указателей используются для хранения номеров блоков, содержащих непосредственно данные файла, и называются прямыми указателями;
• один одиночный косвенный указатель. Этот указатель указывает на блок прямых указателей, хранящих данные файла;
• один двойной косвенный указатель. Указывает на блок одиночных косвенных указателей;
• один тройной косвенный указатель. Указывает на блок двойных косвенных указателей.

Чтобы вышеописанное было проще понять, взгляните на иллюстрацию, взятую с Википедии:

На рисунке выше вы можете видеть прямые, одиночные косвенные и двойные косвенные блоки. Тройные косвенные блоки одним уровнем глубже двойных.

Заключение

Концепция inode является фундаментальной частью *NIX , а также других ОС. По своей сути смысл inode является очень простым для понимания — это всего лишь метаданные о данных. То есть, он хранит полезную информацию о данных, хранящихся на диске. Такой информацией является, например, идентификатор владельца файла, идентификатор его группы-владельца, права доступа к файлу, а также различные временные штампы. Таким образом, когда вы используете, например, команду 'ls', она извлекает информацию о метаданных файлов и каталогов из их индексных дескрипторов.

Некоторые файловые системы, например Ext3, создают все индексные дескрипторы в момент создания файловой системы. Такой подход может быть не совсем удачным, поскольку вы не сможете создавать новые файлы в случае, если все доступные inode будут использованы, даже если на диске достаточно места. Чтобы избежать подобных ограничений, можно использовать файловые системы вроде Ext4 и XFS, которые создают индексные дескрипторы по мере необходимости.

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

Источник: linux-mag.com

Давно ищете хорошего сотрудника в свой бизнес и уже соврешенно сбились с ног? Подобрать и подготовить хорошего продавца для вас смогут в агенстве «Фрегат». Кстати, тем, кто ищет хорошую работу, тоже будет полезно обратиться в агенство.

pgrep

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

$ pgrep ssh
378
1854

В этом примере pgrep вывела идентификаторы процессов, имеющих в своих именах слово 'ssh'. Для сравнения, пользуясь «традиционным» способом, вам пришлось бы дать команду:

$ ps -ef |grep ssh |grep -v grep | awk '{print $2}'

Также, вы можете указывать дополнительные критерии поиска. Например команда:

$ pgrep -u root sshd

выведет PID всех процессов, в командной строке запуска которых есть слово 'sshd' и эффективный UID которых равен root. Или же, например, при помощи команды

$ pgrep -u root,daemon

вы можете получить список PID процессов, эффективные UID которые равны root или daemon. Дополнительную информацию об утилите pgrep можно получить из её man-страницы.

grepcidr

grepcidr очень удобна в случаях, когда необходимо отыскать вхождения IP-адресов или их диапазонов в формате Classless Inter-Domain Routing (CIDR). Так же, как и grep, grepcidr понимает опцию инвертирования и может производить поиск в файле. grepcidr может производить сравнение с шаблоном тысячи и даже миллионы IP-адресов, используя небольшое количество памяти и делая это быстро.

Формат вызова grepcidr для поиска IP-адресов в файле в общем случае таков:

$ grepcidr шаблон файл

Шаблон может быть определён:

• в CIDR формате: a.b.c.d/xx
• в виде диапазона: a.b.c.d-e.f.g.h
• в виде одиночного адреса: a.b.c.d

Например, найдём наших клиентов, оказавшихся в чёрном списке:

$ grepcidr -f ournetworks blocklist > abuse.log

Следующая команда отыщет все появления loopback-адресов в файле iplog:

$ grepcidr 127.0.0.0/8 iplog

Следующей командой выполняется поиск IP-адресов из диапазона:

$ grepcidr "192.168.0.1-192.168.10.13" iplog

А в этой команде список шаблонов берётся из файла list1:

$ grepcidr -f list1 iplog

Больше информации об использовании grepcidr можно найти на её man-странице.

ngrep

Задачей ngrep является поиск соответствия grep-шаблонов в сетевом трафике. ngrep является pcap-совместимой утилитой, что даёт пользователю возможность использовать шестнадцатиричные строки при определении шаблонов.

Если вы запустите ngrep без параметров, вы увидите весь трафик, проходящий через ваш компьютер. Чтобы сузить полосу поиска вхождений шаблона лучше воспользоваться опцией -d  для определения сетевого интерфейса, который нужно прослушивать. Например, следующая команда будет выводить содержимое пакетов, проходящих через интерфейса eth0 и в которых порт источника или порт получателя равны 80:

# ngrep -d eth0 port 80

А при помощи следующей команды вы получите содержимое пакетов любого интерфейса, содержащих 'error' и в которых порт источника или порт получателя равны 514:

# ngrep -d any 'error' port syslog

Дополнительную информацию об ngrep можно найти в соответствующей man-странице.

pdfgrep

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

$ pdfgrep -in seven SomeBook.pdf

будет выполнять регистронезависимый поиск слова 'seven' в файле SomeBook.pdf с указанием номеров страниц, на которых соответствие шаблону было найдено.

Дополнительную информацию об pdfgrep можно найти в соответствующей man-странице.

taggrepper

taggrepper — это небольшая утилита для grep'а тэгов в медиафайлах. На сегодняшний день она умеет выполнять поиск на основе регулярных выражений в тэгах файлов MP3, Ogg Vorbis и FLAC. Поддерживается рекурсивный обход файлов. Вот некоторые часто используемые опции утилиты, определяющие тип информации для вывода:

• --display-title
• --display-artist
• --display-album
• --display-year
• --display-genre
• --display-comment
• --display-track
• --display-composer
• --display-orig-artist
• --display-copyright
• --display-url
• --display-encoded-by

Например, следующая команда выведет имена всех mp3-файлов 2009 года издания, начиная с текущего каталога:

$ taggrepper -y 2009 -r *.mp3

А эта команда будет выведет список файлов каталога ~/AV/Music_collection/, в тэге исполнителя которых будет найден фрагмент 'Rahman':

$ taggrepper -r -a Rahman ~/AV/Music_collection/

Дополнительную информацию об taggrepper можно найти в соответствующей man-странице.

В заключение

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

Источник: linuxaria.com

Проверка ФС ext2/ext3/ext4 при помощи e2fsck

Утилита e2fsck является потомком известной UNIX-утилиты fsck, предназначенной для проверки файловых систем. При помощи e2fsck вы можете проверять на наличие ошибок и выполнять восстановительные работы в файловых системах ext2/ext3/ext4.

Одним из наиболее важных моментов в работе с e2fsck является то, что при помощи неё работы можно проводить только на отмонтированной файловой системе, в противном случае вы можете получить себе ещё больше головной боли, о чём и предупреждает сама утилита при попытке запуска её для работы на смонтированной ФС. Если проверяемая ФС не является корневой, то вы можете завершить работу всех пользователей, переключиться в однопользовательский режим (init 1), отмонтировать ФС и работать с ней.

Однако автор всё же рекомендует воспользоваться каким-нибудь live-дистрибутивом и, загрузившись с него, выполнять все работы. Используя этот метод вы получите в своё полное распоряжение несмонтированные ФС без необходимости выполнять какие-то дополнительные действия.

Если же вы по каким-то причинам выбираете первый вариант, то после того, как перейдёте в однопользовательский режим:

# init 1

отмонтируйте нужную для работы файловую систему:

# umount /dev/sdb1

и после успешного размонтирования запускайте  e2fsck:

# e2fsck -y /dev/sdb1

Опция '-y' сообщает утилите e2fsck о том, что мы заранее согласны со всеми её вопросами и уходим пить кофе, в надежде что она самостоятельно всё сделает. В зависимости от размера файловой системы проверка и восстановление могут занять некоторое время. После окончания проверки вы всегда можете запустить тест ещё раз, чтобы убедиться в том, что не в ФС не возникло новых ошибок, что может быть вызвано аппаратными проблемами накопителя.

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

Восстановление удалённых файлов при помощи /proc и lsof

Теперь давайте рассмотрим процесс восстановления удалённых файлов. Вообще, причиной тому что вы можете восстановить удалённый файл является тот факт, что «файл» — это лишь ссылка на индексный дескриптор файла (inode). Именно в inode хранится информация о физическом размещении файла. Когда вы удаляете файл, фактически вы просто удаляете ссылку на inode, в то время как сам дескриптор ещё какое-то время будет существовать: до тех пор, пока процесс, ранее открывший этот файл не освободит соответствующий дескриптор для записи. Таким образом, есть какое-то время, пусть и короткое, в течение которого можно восстановить содержимое удалённого файла. Ключом в этом процессе является файловая система /proc, содержащая среди всего прочего информацию обо всех выполняющихся в системе процессах и открытых ими файлах. Каждый процесс, работающий в системе имеет соответствующий его PID каталог в /proc. Зная PID процесса, всё ещё держащего открытым удалённый файл, мы всегда можем восстановить его содержимое из каталога /proc/[pid]/ открывшего его процесса. Давайте на простом примере посмотрим, как это делается.

Сперва давайте создадим какой-нибудь файл:

$ echo 'Очень важные данные' > ~/myfile.txt

Теперь у нас есть файл myfile.txt с важными данными, расположенный в домашнем каталоге. Давайте попробуем удалить его и затем восстановить следующим образом. Сначала мы откроем файл для просмотра командой less, после чего приостановим её работу, оставив таким образом нужный нам файл открытым. Итак, пошагово.

Откройте файл командой less для просмотра

$ less ~/myfile.txt

После того, как файл будет открыт и вы увидите его содержимое, нажмите Ctrl+z , чтобы приостановить выполнение less.

Удалите файл:

$ rm ~/myfile.txt

Убедитесь в том, что файла больше нет

$ ls -l ~/myfile.txt

Поскольку работа ранее запущенной нами less ещё не завершена, то файл остаётся для неё открытым и фактически не удалён. Давайте восстановим его.

Для начала необходимо узнать PID процесса, открывшего файл и номер файлового дескриптора. Сделать это можно при помощи программы lsof:

$ lsof | grep myfile.txt
less      2675      ashep    4r      REG    8,1      37 294478 /home/ashep/myfile.txt (deleted)

Во втором поле вывода lsof содержится PID — 2675, а в четвёртом номер дескриптора — 4. Теперь можно приступать к восстановлению:

$ cp /proc/2675/fd/4 ~/recovered.txt

Проверьте, то ли содержимое находится в файле, которое нам нужно:

$ cat ~/recovered.txt
Очень важные данные

Как видим, всё прошло успешно и нам удалось восстановить удалённый файл.

Восстановление удалённых файлов при помощи Scalpel

После того как процесс, открывший файл, завершится, восстановление файла становится задачей потруднее, поскольку индексный дескриптор освобождается и всякая связь между данными в блоках на диске и файловой системой потеряна. До тех пор, пока данные физически не будут перезаписаны на диске, существует возможность их восстановления при помощи утилиты Scalpel. Этот инструмент последовательно, блока за блоком, обходит содержимое диска и анализирует его содержимое, пытаясь найти признаки существования там файлов. Для поиска Scalpel использует шаблоны из последовательности байт, присущих определённым типам файлов. Например, PNG-файлы содержат в заголовке последовательность байт \x50\x4e\x47.

Scalpel вы найдёте в репозиториях большинства современных дистрибутивов. После установки утилиты первым делом нужно определиться с тем, какие файлы программа будет искать при работе. Определения шаблонов для поиска находятся в файле /etc/scalpel/scalpel.conf. По умолчанию содержимое файла целиком закомментировано и прежде чем начать работу вам необходимо раскомментировать нужные шаблоны и/или добавить свои. Формат описания шаблона довольно прост:

extension  case_sensitive  size  header  [footer]

где

• extension определяет расширение файла, которое Scalpel будет дописывать при восстановлении;
• case_sensitive указывает утилите, имеет ли значение регистр символов в шаблоне поиска;
• при помощи size определяется максимальный размер восстанавливаемых файлов;
• в header и необязательном footer описываются последовательности заголовка файла и нижней его части соответственно.

Например, определение шаблона для JPG-файлов может выглядеть так:

jpg  y  200000000  \xff\xd8\xff\xe0\x00\x10  \xff\xd9

После того, как внесёте необходимые изменения в конфигурационный файл Scalpel и подготовите пустую (обязательно!) директорию для сохранения найденных файлов, можно запускать процесс поиска и восстановления:

# scalpel -o ~/recovered /dev/sdb1

где при помощи опции '-o' определяется путь к каталогу для сохранения найденных файлов. Процесс работы утилиты как правило очень долгий, поскольку она сканирует всё устройство целиком, поэтому воспользуйтесь моментом и сходите прогуляться на улицу, свежий воздух ещё никому не мешал ;)

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

Заключение

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

По материалам с linux.com

Решились наконец распрощаться со своим старым-добрым-верным мобильным помощником и приобрести ему достойную современную замену? Интернет-магазин мобильных телефонов Euroteka.Com.Ua рад предложить вам огромнейший ассортимент мобильных телефонов на любой вкус и бюджет, по адекватным ценам с доставкой по Украине.

/proc/[pid]

Внутри каталога /proc вы обнаружите множество каталогов, имена которых состоят из цифр. Имя каждого такого каталога соответствует PID (идентификатору процесса) работающего в системе процесса.

• /proc/[pid]/cmdline. В этом файле хранится командная строка, которой был запущен данный процесс;
• /proc/[pid]/cwd. Этот файл представляет собой символическую ссылку на текущий рабочий каталог процесса;
• /proc/[pid]/exe представляет собой символическую ссылку на исполняемый файл, который инициировал запуск процесса;
• /proc/[pid]/status содержит информацию о состоянии процесса, его имени, родительском процессе, а также различную статистическую информацию, например об используемой памяти.

/proc/cmdline

В этом файле содержатся все аргументы, переданные ядру в момент старта системы.

/proc/cpuinfo

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

/proc/filesystems

Этот файл содержит перечень всех поддерживаемых ядром типов файловых систем. Строки, начинающиеся с 'nodev', указывают на то, что ФС не является «физической». Например, такими системами являются сетевые  файловых системы, вроде NFS, или, например, псевдо-ФС, например /proc.

/proc/loadavg

Хранит информацию о загрузке системы. Первые три поля хранят ту же информацию, которую вы получаете о средней загрузке системы при помощи команды uptime.

Четвёртое поле состоит из двух значений, разделённых слэшем. Первая часть значения поля показывает количество выполняющихся в данный момент процессов/потоков. Это значение не может быть больше количества присутствующих в вашей системе CPU. Вторая часть поля отображает количество процессов присутствующих в системе.

Значение пятого поля содержит ID последнего запущенного в системе процесса. Обратите внимание, что если вы просматриваете содержимое /proc/loadavg при помощи, например, cat, то вы увидите значение PID именно программы cat.

/proc/meminfo

В этом файле хранится информация об использовании памяти системой. Именно отсюда программа free берёт информацию для вывода.

/proc/net

В этом каталоге хранится информация, касающаяся работы сетевых устройств и протоколов:

• /proc/net/arp содержит ARP-таблицу;
• /proc/net/dev для каждого сетевого интерфейса хранит статистические данные, такие как количество принятых/переданных пакетов, ошибок и т. п.;
• /proc/net/route содержит таблицу маршрутизации в шестнадцатиричном виде;
• /proc/net/wireless хранит статистические данные о работе беспроводных интерфейсов.

/proc/swaps

В этом файле вы найдёте информацию обо всех используемых в системе разделах/файлах подкачки, их приоритетах, объёме и используемом пространстве.

/proc/sys/kernel/hostname

Этот файл содержит хостнейм вашей системы. Вы можете изменить его, просто записав в этот файл другое значение при помощи echo.

/proc/sys/kernel/threads-max

Из этого файла вы можете узнать, какое максимальное количество процессов к одновременному существованию допускается в вашей системе. Сравните это значение со значением четвёртого поля из файла /proc/loadavg.

/proc/sys/vm/swappiness

Как это уже освещалось в одной из статей, значение в этом файле регулирует поведение системы относительно частоты сброса данных из оперативной памяти в своп. Чем выше это значение — тем активнее система будет свопиться.

/proc/uptime

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

$ echo `cut -d ' ' -f 2 /proc/uptime` / `cut -d ' ' -f 1 /proc/uptime` '* 100' | bc -l

/proc/vmstat

Содержит информацию об использовании виртуальной памяти.

/proc/sys/net/ipv4/conf/default/forwarding

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

Источник petur.eu

Если вы проводите какое-то количество времени в оболочке, то скорее всего знаете о том, что существует «история» команд, которые вы выполняли, аналогично тому, как ваш веб-браузер помнит историю посещённых вами веб-страниц. Хотя, конечно, история команд в оболочках появилась гораздо раньше истории посещённых страниц в браузерах.

Многие пользователи знают о том, что доступ к истории команд можно получить при помощи команды history или же при помощи клавиатурных комбинаций Ctrl+p (предыдущая команда) и Ctrl+n (следующая команда). Это очень полезные и часто используемые приёмы работы с историей, однако при помощи них не задействуете все возможности Bash для работы с историей. Давайте рассмотрим несколько трюков работы с историей Bash, пользуясь командой history или другими способами.

Использование номеров

Если вы дадите команду history, вы получите список последних введённых команд с порядковым номером перед каждой из них. Вы можете повторно запустить любую команду из истории при помощи конструкции

$ !n

где n — номер записи в истории. То есть, например, инструкция

$ !50

выполнит пятидесятую команду из истории. Также вы можете использовать конструкцию

$ !-n

если вам нужно выполнить n-ю по счёту команду, начиная с конца списка. Например, ваш вывод history выглядит так:

1  sudo su
2  exit
3  sudo apt-get update

тогда инструкция

$ !-3

запустит команду sudo su.

Вызов последней команды

Как часто вы вводите какую-то команду, а затем видите, что вы, намереваясь предварить её sudo, забыли это сделать? У меня такое происходит постоянно. Можно исправить это, вернувшись к последней команде при помощи клавиши «стрелка вверх» или при помощи комбинации Ctrl+p, затем, перейдя в начало строки при помощи клавиши Home или Ctrl+a вписать пропущенное sudo. Есть и более простой способ:

$ sudo !!

Это запустит последнюю команду (!!) при помощи sudo. Неплохо?

Вы, вероятно, знаете конструкцию !command, которая запустит последнюю команду из истории, которая начинается с command. Таким образом, если вы недавно запускали очень длинную команду и помните с чего она начиналась, такой способ запуска из истории может вам пригодиться. А знаете ли вы, что Bash  в этом случае ищет не команду, а ищет подстроку? То есть, вам не нужно после восклицательного знака вписывать всю команду целиком, достаточно лишь первых символов. Допустим, вы запускали что-то вроде:

$ git commit -a -m "Various and sundry notes"

Многие пользователи введут

$ !git

чтобы повторить команду, однако зачатую вполне достаточно выполнить

$ !g

конечно же, при условии, что после искомой команды вы больше не выполняли команд, начинающихся с «g».

Если вам вдруг понадобится выполнить поиск не сначала строки, а в любой её части, воспользуйтесь конструкцией «!?string?». Например:

$ !?commit?

Вызов последнего параметра команды

Используя комбинацию «Esc+.» (Escape с точкой), вы можете вызывать из истории последнее слово, переданное команде в качестве аргумента. Например, вы запускали:

$ cp filename1 filename2

Теперь, если вы нажмёте «Esc+.», то вы получите «filename2». Попробуйте самостоятельно поиграть с этой функцией — очень полезная штука!

А что, если вам нужно не последнее слово, а скажем, второе? Или вообще все? Например, у вас в истории есть команда:

$ ls file1.txt file2.txt file3.txt file4.txt

и вам понадобилось вытащить два слова из середины? Легко!

$ ls !:2-3

Если же вам вдруг понадобились вообще все аргументы, переданные команде, вы можете воспользоваться такой конструкцией:

$ ls !:*

Поиск

Ещё одна полезная функция — это поиск при помощи «Ctrl+r». Нажмите «Ctrl+r» и в появившемся приглашении начните вводить часть какой-нибудь ранее ведённой команды. По мере ввода символов Bash будет пытаться найти в истории последнюю команду, содержащую указанные вами символы. После того, как найдёте, можете начать «Ctrl+r» ещё раз и Bash выведет более раннюю команду, если таковая имеется. После того, как вы отыщете нужную команду, просто нажмите «Enter» и она появится в вашей командной строке.

Если вам необходимо отредактировать команду, прежде чем запускать, воспользуйтесь традиционными «стрелкой влево» и «стрелкой вправо», чтобы переместить курсор в нужное место команды для исправления.

Безопасность

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

Давайте посмотрим, каким способом можно управлять хранением команд в истории.

Первый способ — это определить в .bashrc переменную окружения со следующим значением:

HISTCONTROL=ignorespace:ignoredups

Опция ignorespace заставляет Bash игнорировать команды, начинающиеся с пробела. Если вам нужно, чтобы Bash не сохранил в истории команду, содержащую секретную информацию — просто предварите её пробелом.

Опция ingoredups исключает хранение в истории дубликатов команд, что часто помогает значительно разгрузить историю команд.

Вообще, некоторые дистрибутивы «из коробки» имеют эти опции установленными. Если это не ваш случай — просто добавьте строку в ваш ~/.bashrc.

Вы также можете заставить Bash игнорировать некоторые команды. Допустим, вы не хотите хранить в истории команды, содержащие имя какого-нибудь сервера. Просто определите значение переменной окружения HISTIGNORE и можете чувствовать себя спокойно:

HISTIGNORE="*myserver*"

Да, по поводу «спокойствия». На разделяемых системах некоторые пользователи могут видеть команды, запущенные вами при помощи утилит top и ps. Поэтому, если вы не уверены на 100% в надёжности системы, с которой работаете — не стоит запускать там какие бы то ни было команды, содержащие секретные данные.

Заключение

Очень надеюсь, что рассмотренные здесь приёмы пригодятся вам в повседневной работе и сделают её выполнение чуточку приятнее. Однако, это далеко не всё. Обязательно посмотрите man-страницу по history в вашей системе. Уверен, вы сможете найти для себя ещё массу полезного!

Источник linux.com

Сегодня, чтобы создать успешный бизнес, необходимо обеспечить надёжную информационную поддержку. Обслуживание компьютеров юр. лиц на абонентской основе — лучшее решение для тех, кому не требуется постоянный ИТ-специалист в штате. Быстро, надёжно, удобно.

Обычно в своей работе я пользуюсь Dropbox, однако как быть с конфиг-файлами, хранящимися в /etc и в домашнем каталоге? Можно, конечно, придумать какое-нибудь извращение и приспособить Dropbox для хранения этих файлов, однако здесь возникает ещё одна проблема: как заставить Dropbox закачивать на новую систему только определённые файлы, а не все сразу?

Ещё одним решением может быть использование rsync, Duplicity или Unison, однако они не позволяют сохранять версионность файлов, и хранят лишь одну-единственную копию файла с самыми последними изменениями. Короче, Git (или другая система контроля версий) в моём случае подходит лучше всего, а может быть отлично сгодится и для вас.

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

Вкратце опишем перечень шагов, которые нам предстоит сделать в процессе изучения данного материала:

• создать ключи SSH, чтобы не приходилось авторизоваться паролем;
• установить Git на всех системах где будем его использовать;
• создать «голый» (bare) репозиторий на удалённой системе;
• создать репозиторий в локальной системе, файлы с которой будем синхронизировать;
• добавить файлы в локальный репозиторий;
• сделать слепок (commit) добавленных файлов;
• отправить (push) изменения в удалённый репозиторий;
• сделать изменения в локальных файлах и сделать слепок изменений;
• клонировать репозиторий на другую систему.

Начнём

Первое, что нам понадобится — это система, которая будет хранить наш Git-репозиторий. У вас должна быть возможность подключаться к ней по SSH. Это может быть как компьютер в вашей локальной сети, так и система, расположенная в Интернет. Вы даже можете использовать онлайн-сервис GitHub, если у вас нет подходящего компьютера.

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

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/ashep/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ashep/.ssh/id_dsa.
Your public key has been saved in /home/ashep/.ssh/id_dsa.pub.
The key fingerprint is:
f0:59:19:5d:69:c7:4c:62:d0:c1:38:fe:f1:2b:2d:2c ashep@adesktop
The key's randomart image is:
+--[ DSA 1024]----+
|          ...*=*.|
|           o+.=.+|
|      .   o. o . |
|       o o  . .  |
|        S    . o |
|              . .|
|            . . .|
|           E + o |
|            . o  |
+-----------------+

После того, как пара ключей создана, закрытый ключ будет размещён в в ~/.ssh/id_dsa, а открытый — в ~/.ssh/id_dsa.pub. Теперь, чтобы удалённая система аутентифицировала  вас на основе ключа, а не пароля, необходимо скопировать содержимое локального файла ~/.ssh/id_dsa.pub в файл ~/.ssh/authorized_keys на удалённой системе. В Debian/Ubuntu для этих целей есть специальный shell-скрипт ssh-copy-id, им и воспользуемся:

$ ssh-copy-id ashep@aserver
ashep@aserver's password:
Now try logging into the machine, with "ssh 'ashep@aserver'", and check in:

  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Пользователи же других систем, в которых ssh-copy-id отсутствует, могут воспользоваться старой-доброй scp:

$ scp /home/ashep/.ssh/id_dsa.pub ashep@aserver:/home/ashep/.ssh/authorized_keys

Будьте внимательны и если в ~/.ssh/authorized_keys на удалённой системе у вас уже имеются какие-то ключи, то добавьте вручную открытый ключ к существующим, поскольку приведённая выше команда затрёт существующий файл.

Ну и, само-собой разумеется, в ваших системах, которые будут участвовать в работе, должен быть установлен Git. На сегодняшний день Git присутствует в репозиториях всех современных дистрибутивов, а также в коллекции портов FreeBSD, так что у вас не должно возникнуть сложностей с его установкой. Я использую Ubuntu и в ней Git установился «лёгким движением руки»:

$ sudo apt-get install git-core

Создание репозиториев

Пришло время создавать репозитории. Начнём с создания репозитория на удалённой системе, затем создадим локальный, в который и добавим файлы. Подключитесь к удалённой системе по SSH:

$ ssh ashep@aserver

создайте каталог для хранения репозитория:

$ mkdir project

и создайте в это каталоге «голый» Git-репозиторий:

$ cd project && git init --bare
Initialized empty Git repository in /home/ashep/project/

Просто, не так ли? Теперь в вашей локальной системе необходимо создать репозиторий для хранения отслеживаемых файлов. Обычно, если вы работаете над каким-то проектом, каталог репозитория .git хранится в каталоге проекта. В нашем же случае необходимо будет хранить файлы из разных мест, поэтому лучшим вариантом будет создать репозиторий в корне домашнего каталога:

$ cd ~/ && git init
Initialized empty Git repository in /home/ashep/.git/

Репозиторий успешно создан и прежде, чем мы продолжим работу, давайте минимально настроим Git, а точнее определим имя и email, которые будут упоминаться к истории коммитов (слепков):

$ git config --global user.name "Alexander Shepetko"
$ git config --global user.email "ashep@ashep.org"

Теперь добавим что-нибудь в репозиторий, указывая Git отслеживать изменения:

$ git add .vim
$ git add .vimrc

И сделаем слепок состояния добавленных файлов, указав при помощи опции -m комментарии к слепку:

$ git commit -m 'Первый слепок'
[master (root-commit) f4c5dcf] Первый слепок
 4 files changed, 90 insertions(+), 0 deletions(-)
 create mode 100644 .vim/.netrwhist
 create mode 100644 .vim/spell/ru.utf-8.spl
 create mode 100644 .vim/spell/ru.utf-8.sug
 create mode 100644 .vimrc

Отлично, файлы и каталог успешно добавлены, теперь можно «слить» локальный репозиторий в удалённый. Для начала необходимо в локальном репозитории определить один или несколько  удалённых, с которыми Git сможет производить синхронизацию. Добавим ранее созданный удалённый репозиторий project на удалённой системе aserver, доступ к которой у нас настроен от имени пользователя ashep:

$ git remote add origin ashep@aserver:project

И отправим изменения из локального репозитория:

$ git push origin master
Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 2.37 MiB | 462 KiB/s, done.
Total 8 (delta 0), reused 0 (delta 0)
To ashep@aserver:project
 * [new branch]      master -> master

Отслеживание изменений

После того, как вы сделали свой  первый слепок и отправили изменения в удалённый репозиторий, самое время разобраться с тем, как отслеживать изменения в файлах. Сделайте какое-нибудь незначительное изменение, например, в файле .vimrc и сделайте после этого слепок состояния всех отслеживаемых файлов:

$ git commit -a -m 'Изменён .vimrc'
[master 0d6096f] Изменён .vimrc
 1 files changed, 0 insertions(+), 1 deletions(-)

Теперь вы можете отправить изменения в удалённый репозиторий:

$ git push origin master
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 317 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To ashep@aserver:project
   f4c5dcf..0d6096f  master -> master

Копирование файлов на другие системы

Пришло время «размножить» наши конфигурационные файлы на тех системах, где это нам нужно. Авторизуйтесь в нужной системе и создайте в своём домашнем каталоге новый  Git-репозиторий, как это мы делали ранее:

$ cd ~/ && git init
Initialized empty Git repository in /home/ashep/.git/

И теперь скопируйте файлы удалённого репозитория на диск:

$ git pull ashep@aserver:project
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From aserver:project
 * branch            HEAD       -> FETCH_HEAD

На это всё! Если вы сделаете изменения в каком-то из отслеживаемых файлов на любой системе, просто воспользуйтесь командами git commit и git push, как это было показано выше и изменения будут доставлены в удалённый репозиторий, после чего вы сможете из загрузить во все локальные репозитории систем, в которых эти версии файлов вам необходимы, при помощи команды git pull.

Обратите внимание на то, что мы используем git pull, а не git clone, поскольку нам нужно получать именно изменения в файлах, а не весь репозиторий целиком.

Управление версиями

По ходу работы вы можете добавлять в репозиторий новые файлы для отслеживания при помощи команд git add и удалять ненужные при помощи git rm. Если вам необходмо узнать, какие файлы находятся в состоянии «отслеживаемых», воспользуйтесь командой git ls-files:

$ git ls-files
.vim/.netrwhist
.vim/spell/ru.utf-8.spl
.vim/spell/ru.utf-8.sug
.vimrc

Что делать, если вы сделали ненужные изменения в локальном файле и хотите восстановить версию, находящуюся в последнем слепке? Для этого существует команда git checkout. Например, следующая команда восстановит последнюю версию файла .vimrc:

$ git checkout .vimrc

Просмотреть историю слепков можно при помощи команды git log:

$ git log
commit 0d6096f96c647e8b1bdfb6a217cbae967b16a5cd
Author: Alexander Shepetko
Date:   Fri Apr 22 02:46:15 2011 +0300

    Изменён .vimrc

commit f4c5dcf1f5c55ab8b495c6e16afb1eee73b8380a
Author: Alexander Shepetko
Date:   Fri Apr 22 01:54:14 2011 +0300
    Первый слепок

Обратите внимание на 40-битное значение хэша слепка. Оно уникально идентифицирует каждый коммит, так что вы можете обращаться к нему. В частности иногда бывает полезно восстановить не отдельный файл а весь слепок целиком. Для этого достаточно команде git revert передать хэш-значение нужного слепка:

$ git revert 0d6096f96c647e8b1bdfb6a217cbae967b16a5cd
Finished one revert.
[master 933c16f] Revert "Изменён .vimrc"
 1 files changed, 1 insertions(+), 0 deletions(-)

Резюме

Хотя Git далёк от определения дружественной пользователям утилиты, разобраться с основами его использования не так уж и сложно. Данная заметка никоим образом не претендует на описание принципов работы Git, а лишь рассказывает об идее применения этой очень мощной утилиты для нужд рядовых пользователей и системных администраторов. Git обладает огромными возможностями и если вам это интересно, и вам хотелось бы подробней узнать о них, советую вам начать с замечательной книги Pro Git, в большей части уже доступной на русском языке.

По мотивам linux.com

ClusterSSH — это обёртка к XTerm и клиенту SSH, написанная на Perl/Tk. Таким образом, ClusterSSH может работать в любой POSIX-совместимой ОС, где есть необходимые программные компоненты — Perl с модулями Tk и X11::Protocol, XTerm и OpenSSH Автор успешно запускал утилиту в системах под управлением Linux, Solaris и Mac OS X.

Установка

Установка ClusterSSH в Debian и Ubuntu не представляет какой-либо сложности и заключается в выполнении команды:

$ sudo apt-get install clusterssh

Также существуют готовые пакеты для Fedora и порты в FreeBSD. Пользователи систем Apple могут установить ClusterSSH из MacPorts. Ну и, конечно же, вы можете собрать утилиту из исходников.

Настройка

ClusterSSH может настраиваться как из глобального файла конфигурации расположенного в /etc/clusters, так и из локального для каждого пользователя файла ~/.csshrc. Автор предпочитает хранить настройки в локальном файле конфигурации. Формат файла конфигурации ClusterSSH очень прост. В документации ClusterSSH используется термин «кластер». Кластер — это группа систем, которые вам необходимо администрировать, используя один интерфейс. В файле конфигурации вы можете сперва объявить несколько кластеров, а после определить набор систем, входящих в кластер.

Например, давайте представим, что нам нужно настроить два кластера, содержащие по два хоста каждый. «cluster1» будет содержать системы «test1» и «test2», а «cluster2» — системы «test3» и «test4». Описать это в файле конфигурации, как уже говорилось, очень просто:

clusters = cluster1 cluster2
cluster1 = test1 test2
cluster2 = test3 test4

Также вы можете создавать метакластеры, т. е. кластеры, которые включают в себя другие кластеры. Например, если вам нужен кластер, содержащий все машины (назовём его «all»), вы можете создать его таким образом:

clusters = cluster1 cluster2 all
cluster1 = test1 test2
cluster2 = test3 test4
all = test1 test2 test3 test4

или же использовать метакластер:

clusters = cluster1 cluster2 all
cluster1 = test1 test2
cluster2 = test3 test4
all = cluster1 cluster2

Такой способ объединения систем более удобен, поскольку в случае изменений в одном из кластеров «cluster1» или «cluster2» изменения автоматически коснуться и метакластера «all», и вам не придётся изменять содержимое последнего вручную. Это может сэкономить вам массу времени, особенно в случаях, когда ваш .csshrc станет заметно больше в размерах.

Использование

Запуск ClusterSSH подобен запуску клиента SSH. Например, чтобы подключиться ко всем системам кластера «cluster1» от имени пользователя «vasya» выполните следующую команду:

$ cssh -l vasya cluster1

Как и в случае с использованием клиента OpenSSH, параметр -l вместе с его значением можно опустить, тогда будет использоваться имя пользователя, из-под учётной записи которого вы запустили ClusterSSH.

На скриншоте в начале статьи запечатлено подключение к двум системам. Маленькое окошко с заголовком "CSSH [2]" — это консоль ClusterSSH. Всё, что вы будете вводить в текстовом поле этого окошка. будет отправлено в открытые сессии, в данном случае — системам «test1» и «test2».

Вы также можете подключаться к системам, которых нет в конфигурации кластеров. Для этого просто перечислите их имена вместо указания имени кластера:

$ cssh -l vasya machine1 machine2 machine3

Если вам необходимо отправить команду какому-то определённому хосту, а не всем сразу, тогда просто сделайте активным окно XTerm с нужной SSH-сессией и отправьте необходимую команду.

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

Крайне полезна бывает функция «Retile Windows», которая выполняет автоматическое размещение окон с учётом свободного пространства экрана. «Add host (s) or Cluster (s)» позволяет пользователю добавлять новые хосты и/или кластеры не покидая текущей сессии работы с ClusterSSH. Также обратите внимание на имена хостов, перечисленные в нижней части меню и на чекбоксы слева от них. Включая и отключая чекбоксы вы можете выбирать хосты, которые будут получать команды, вводимые в консоли ClusterSSH. Очень удобная возможность, если вам необходимо отправить команду всех хостам, исключив пару-тройку ненужных.

Ещё одна интересная возможность спрятана в элементе меню «Send — Hostname». Выбрав это меню, ClusterSSH отправит во все активные сессии имя хоста, к которому каждая сессия подключена. Довольно полезная штука, когда вы сочиняете командную строку, в которой используются имена хостов и, естественно, являются разными для каждой сессии.

Предостережение

Как и множество UNIX-утилит, ClusterSSH может принести больше вреда, чем пользы, в случае неправильного или необдуманного применения. Будьте очень осторожны при работе с этой утилитой. Подумайте над тем, чего вам может стоить критическая ошибка допущенная сразу на нескольких десятках/сотнях серверов. Трижды проверяйте всё, что вводите в консоли, прежде, чем давить на «Enter».

Заключение

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

Оригинал статьи на Linux.Com

X-сессия через SSH-туннель

Иногда бывает необходимо запустить X-приложение на удалённом хосте, при этом графический ввод-вывод перенаправить на локальный. Кроме традиционных вариантов с использованием XDMCP существует многим известный способ перенаправить ввод-вывод X-сессии в SSH-туннель.

Первым делом убедитесь, что в конфигурации вашего демона SSH включена опция  X11Forwarding, разрешающая перенаправление X-сессии. В файле, расположенном обычно в /etc/ssh/sshd_config, раскомментируйте или добавьте строку:

X11Forwarding yes

Имейте ввиду, что включение этой опции снизит потенциальный уровень защищённости вашего сервера, так что не стоит включать её без необходимости.

После того, как будет изменено содержимое конфигурационного файла SSH-сервера, его необходимо перезапустить:

$ sudo service ssh restart

Теперь со стороны клиента можно инициировать SSH-подключение с перенаправлением X-сессии:

$ ssh -X user@host

И после того, как авторизуетесь, можно запускать любые X-приложения, например:

$ gnome-terminal

Или, как вариант, можно запустить приложение в «фоновом режиме», т. е. не оставаясь подключённым к удалённой оболочке:

$ ssh -Xf user@host gnome-terminal

Поиск фалов на удалённом компьютере

Очень полезно бывает иногда найти файлы на удалённом компьютере, получив результаты поиска в локальном терминале. Сделать это очень просто. Например:

$ ssh user@host "find /home/user -iname '*.mp3'"

Само-собой, подобным образом вы можете выводить локально результаты работы любой удалённой команды.

Редактирование удалённых файлов в Vim

Вовсе необязательно подключаться к удалённой оболочке и редактировать файл непосредственно на сервере. Некоторым нравится делать это локально. Следующая команда запустить Vim, безопасно скопирует удалённый файл при помощи scp и после выхода из редактора обновит изменения на сервере, если таковые будут:

$ vim scp://user@host//etc/samba/smb.conf

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

Воспроизведение музыки с удалённого сервера

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

$ ssh user@host "cat /home/user/music/artist/*.mp3" | mpg123 -

Воспроизведение видео с удалённого сервера

Смысл тот же, что и в случае с воспроизведением звука, только здесь речь идёт о видеофайлах и вместо mpg123 используется всем известный vlc, умеющий воспроизводить видеопоток в том числе и из стандартного ввода:

$ ssh user@host "cat /home/user/video/movie.mp4" | vlc -

По материалам go2linux.org

Сегодня уже ни для кого не секрет, что своевременная и грамотная поисковая оптимизация сайта — залог успешности бизнеса. Качественное продвижение сайтов по приемлемым ценам и во вменяемые сроки для вас с радостью выполнит команда профессионалов из seo-dream.ru.

alias создана для того, чтобы делать сложные вещи простыми (или простые — ещё проще). Вместо того, чтобы использовать длинную и/или сложную команду вы можете создать простой псевдоним для неё и затем использовать его в своё удовольствие. Общий формат определения псевдонима при помощи alias таков:

alias псевдоним="команда"

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

Делаем простые команды ещё проще

Возьмём, например, часто многими используемую команду 'ls -l', отображающую список файлов в каталоге в т. н. «длинном» формате. Можно упростить ввод этой чатсо используемой команды. Например, так:

alias ll="ls -l"

Теперь вместо 'ls -l' вы можете вводить 'll' и получать список файлов в «длинном» формате.

Ещё пример. Иногда впопыхах или после пары банок пива усталые пользователи начинают вводить 'sl'  вместо 'ls' и очень нервничают по этому поводу. Исправим эту неприятность:

alias sl="ls"

Вот ещё более простой пример, используя который, можно ускорить ввод команды exit:

alias x="exit"

Следующие три примера делают популярные команды более интерактивными по умолчанию:

alias cp="cp -iv"
alias mv="mv -iv"
alias rm="rm -iv"

Упрощаем управление пакетами

Почти во всех современных дистрибутивах имеется система управления пакетами, а также набор программного обеспечения для работы с ней. Ниже, на примере менеджера управления пакетами APT, используемом в Debian и его потомках, автор демонстрирует способ упрощения работы с ним.

Для того, чтобы установить какой-то пакет в Debian/Ubuntu, обычно используется команда:

sudo apt-get install имя_пакета

Эта длинная команда отбирает много времени, сил и энергии. Давайте упростим её при помощи alias;

alias Install="sudo apt-get install"

Теперь устанавливать пакеты стало проще:

Install имя_пакета

Таким же образом можно упростить остальные часто используемые моменты при управлении пакетами:

alias Update=”sudo apt-get update”
alias Upgrade=”sudo apt-get upgrade”
alias Search=”apt-cache search”
alias Autoremove=”sudo apt-get autoremove”
alias Autoclean=”sudo apt-get autoclean”
alias Purge=”sudo apt-get remove –purge”

Псевдонимы для «неудобных» клавиш

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

alias .=”cd ..”
alias ..=”cd ../..”
alias ...=”cd ../../..”
alias ....=”cd ../../../..”

Сёрфинг в терминале

Если вы часто пользуетесь lynx, то и дело вводя URL часто посещаемых сайтов из командной строки, попробуйте облегчить себе жизнь за счёт использования псевдонимов:

alias Google=”lynx http://www.google.com/”
alias Yahoo=”lynx http://www.yahoo.com/”
alias asheporg=”lynx http://www.ashep.org/”

Упрощаем сложные команды

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

Например, чтобы отыскивать десятку самых больших файлов в вашей системе одной командой, можно создать следующий псевдоним:

alias top10files=”find . -type f -exec ls -sh {} \; | sort -n -r | head -10”

Если вы частенько подключаетесь к серверу с IP-адресом 1.2.3.4 по SSH, висящем на порту 22, от имени пользователя vasya, вам может оказаться полезным подобный псевдоним:

alias my_server="ssh vasya@1.2.3.4 -p 22"

Также вы можете создавать псевдонимы для ваших bash-сценариев, например:

alias clc="bash /home/vasya/bin/calc.sh"

Заключение

Посмотреть список созданных псевдонимов можно при помощи команды alias, введённой без параметров. Если какой-то из псевдонимов вам уже не нужен, вы всегда можете удалить его при помощи команды unalias. Например:

unalias Google

или же удалить вообще все псевдонимы, если нужно:

unalias -a

Да, чуть не забыл. Все созданные вами псевдонимы автоматически удалятся сразу же после завершения сеанса работы с терминалом. Если же вы хотите всегда иметь под рукой нужные сокращения, просто добавьте нужные команды в ваш ~/.bashrc.

Оригинал статьи на linux-blog.org

В условиях никак не покидающего и отчётливо ощущаемом многими финансовом кризисе очень важно не потерять работу. Тем же, кого сие несчастье настигло и кого интересуют вакансии в Караганде и Карагандинской области, приглашаю посетить раздел вакансий на slando.kz!