Проект книги "Инструменты Linux для Windows-программистов"

Предлагаю черновой проект книги "Инструменты Linux для Windows-программистов"
Это не рассчитано на начинающих, но может быть интересно программистам с некоторым опытом программирования в языке С, но в других ОС (чаще всего это Windows).
http://rus-linux.net/nlib.php?name=/MyLDP/BOOKS/Linux-tools/index.html

Olej написал:

Предлагаю черновой проект книги "Инструменты Linux для Windows-программистов"

Текст сильно исправлен и расширен: то, что было раньше выложено на 117 стр. (OpenOffice страниц А4) - стало теперь 150 стр.
Новый вариант выложен здесь: версия 2.60 в формате ODT (редаакция от 4 декабря 2011, размер файла 355 Кбайт).

P.S. жаль, что этот текст не получил откликов... там многое (особенно ко 2-й половине) - на уровне тонких вещей, и даже спорных ... на которые интересны бы были мнения профессионалов (несмотря на кажущуюся простоту, лоху начинающему там как-раз делать нечего wink ).

- Slackware подобные дистрибутивы. Это дистрибутивы серверной ориентации, традиционно установка пакетов в них практиковалась из архивов исходных кодов формата .tgz, но и в них стали применяться пакетные инсталляторы slapt-get (вариант apt) и slackpkg. Сторонники этих дистрибутивов считают, что это «самый чистый» Linux. В этом семействе около 11 дистрибутивов

войдя в файловый менеджер (командный интерпретатор) как root, вот так:
$ sudo mc
# whoami
root

Ссылки в Linux могут быть жёсткими (hard) и мягкими (soft), главное различие между ними в том, что первые могут ссылаться только на имена в пределах поддерева, размещённого на одном физическом устройстве хранения (диске)

(например, при загрузке с Live CD): на диске не будет никаких каталогов /dev, /proc, или /sys

Порядок (последовательность) использования механизмов разрешения сетевых имён:
$ cat /etc/host.conf

bormant написал:

- Slackware подобные дистрибутивы. Это дистрибутивы серверной ориентации, традиционно установка пакетов в них практиковалась из архивов исходных кодов формата .tgz, но и в них стали применяться пакетные инсталляторы slapt-get (вариант apt) и slackpkg. Сторонники этих дистрибутивов считают, что это «самый чистый» Linux. В этом семействе около 11 дистрибутивов

Жуть какая. Откуда, простите, нафантазировалось подчёркнутое?

1. там источник, должон быть, указан ... не там сразу, так в конце, в "источники информации".

2. откуда? из этого источника ... ну, ещё из своих собственных воспоминаний wink , поскольку начинал свой опыт году в 1994 или 1995 с Slackware ... больше к нему не возвращался.

3. если у вас есть более точное мнение (но не IMHO, а мотивированное и со ссылками на другие подкрепляющие мнения), то в его предложите - я заменю wink

P.S. за вопросы-замечания спасибо ... но я, главным образом, просил замечания по 2-й половине .... ну, хоть начиная с 1/3 и далее wink
Потому как на ЛОР прямо гвалт стоял, как словоблудить и обсуждать стали .... но дальше 1/3 никто не дощёл в замечаниях, потому как они просто перестали понимать вещи, которые обсуждаются :o ...

bormant написал:

войдя в файловый менеджер (командный интерпретатор) как root, вот так:
$ sudo mc
# whoami
root

почему не стандартное:[console]$ sudo -i
# whoami
root
[/console]

Потому, что я просто не знаю такого способа wink (сейчас проверю).
... и что значит "стандартное"? каким это стандартом оговорено? wink
Но, поскольку (особенно в POSIX OS) любую вещь можно сделать миллионом способов, то и указанного мной способа - достаточно wink

bormant написал:

Ссылки в Linux могут быть жёсткими (hard) и мягкими (soft), главное различие между ними в том, что первые могут ссылаться только на имена в пределах поддерева, размещённого на одном физическом устройстве хранения (диске)

Всё верно...
Но это - общеизвестные вещи...
Ещё можно дописать, что софтовые ссылки появились исторически гораздо позже, чтобы восполнить недостатки хардовых, а хардовые были когда "Земля ещё была тёпленькая и по ней бродили полчища динозавров" wink ...

Но я же не учебник взялся писать ... Для этого Робачевского пусть читают, которого я и поместил №1 в библиографии wink

bormant написал:

(например, при загрузке с Live CD): на диске не будет никаких каталогов /dev, /proc, или /sys

/dev явно лишний в этом списке, несмотря на моду на udev.

А здесь придётся детально вернуться к рассмотрению размонтированной файловой системы.
Совершенно не уверен.

bormant написал:

Порядок (последовательность) использования механизмов разрешения сетевых имён:
$ cat /etc/host.conf

Не согласен!
/etc/host.conf - механизм, существующий в UNIX от момента рождения (>40 лет) + во всех UNIX.
Так что соизмеримы они ну никак не могут быть.

1) $ man sudo
2) "в пределах поддерева, размещённого на одном физическом устройстве" чаще не соответствует истине, чем наоборот. На самом деле "в пределах одной файловой системы".
3)
[console]# mount /dev/sda2 /mnt
# ls -1 /mnt/dev | wc -l
2604
[/console]И только попробуйте при переносе на другой диск забыть /dev ;-)
4)
а) "серверность"
http://slashdot.org/story/00/03/17/1120205/replies-from-slackware-founder-patrick-volkerding

Slackware's Direction as a Linux Distribution
(Score:5, Insightful)
by dee^lOts

I've always viewed Slackware as the all purpose workhorse of the Linux distributions. It's always done things better and faster in the server role. Now as everyone is pushing to get Linux on the desktop, I'd like to know what Slackware's Direction in this area. Will it remain focused on playing the server role, or will the distribution splinter into different job roles, or will it follow the crowd and push for the desktop?

Patrick:

While we're not really trying to be one-size-fits-all, it seems like by not focusing on some niche that we've ended up being the most flexible.

One of the fortune quotes I like is "A successful tool is one that was used to do something undreamed of by its author. -- S. C. Johnson"

Anyway, I think the more you try to second guess the user, the more you put up barriers. So we like to keep things uncomplicated as much as possible. I think this leads to a system that makes a good server (where you aren't even required to install X if you don't want it), or a good desktop workstation if you do a full installation with KDE or Gnome. It all depends on what you install, and we like to keep that open-ended, and give you the options for whatever you might have in mind at install time. We are talking about making a higher priced retail version that would bundle some commercial tools and office applications, since we're asked about that quite a lot. This will probably also take the swiss-army-knife approach, as some of the add-ons will probably be server oriented, and some will be for the desktop.

Полагаю, мистеру Фолькердингу мы вплне можем доверять в этом вопросе.
Slackware поставляется с ванильным ядром, сконфигурированном преимущественного для десктопа, без серверных оптимизаций. Да, руками можно сделать всё что угодно, но в дистрибутиве этого по умолчанию не сделано.
В конце концов, если на клетке с тигром написано "буйвол", не верь глазам своим. (q)

б) "сборка из исходников" и "стали применяться"
http://www.slackbook.org/html/introduction-slackware.html

... This private distribution quickly gained popularity, so Volkerding decided to name it Slackware and make it publicly available. Along the way, Patrick added new things to Slackware; a user friendly installation program based on a menuing system, as well as the concept of package management, which allows users to easily add, remove, or upgrade software packages on their systems.

Slackware поставляется в виде бинарных пакетов формата tgz и исходников и сценариев, которыми эти пакеты собраны. Но ставится из бинарных пакетов. Пакетный менеджер pkgtools, включает в себя утилиты pkgtool, installpkg, removepkg, upgradepkg, explodepkg, makepkg.

Главный журнал системы /var/log/messages, доступен для доступа только с правами root

bormant написал:

Главный журнал системы /var/log/messages, доступен для доступа только с правами root

Ок, спасибо, это место взял на заметку.

bormant написал:

Slackware поставляется в виде бинарных пакетов формата tgz и исходников и сценариев, которыми эти пакеты собраны. Но ставится из бинарных пакетов. Пакетный менеджер pkgtools, включает в себя утилиты pkgtool, installpkg, removepkg, upgradepkg, explodepkg, makepkg.

pkgtools это не их пакетный менеджер, это pkgsrc заимствованный из NetBSD, который используют и QNX, и Open Solaris, и MINIX, ... и волен использовать всяк кто вздумает wink
С таким же успехом можно сказать, что Slackware использует свой компилятор gcc :O ... (к которому, по большому счёту, и Linux вообще не имеет никакого касательства wink ).

Olej написал:

pkgtools это не их пакетный менеджер, это pkgsrc заимствованный из NetBSD

Приехали. Уже даже не смешно.
http://www.netbsd.org/docs/pkgsrc/introduction.html#why-pkgsrc

pkgsrc provides the following key features:
Easy building of software from source as well as the creation and installation of binary packages. The source and latest patches are retrieved from a master or mirror download site, checksum verified, then built on your system. Support for binary-only distributions is available for both native platforms and NetBSD emulated platforms.

Только простые ключи (односимвольные, начинающиеся с однократного '-') могут иметь значения, «длинные» опции (многосимвольные, начинающиеся с 2-х '-') значений не имеют:
$ gcc --help

Например,
[console]
$ grep -R --include \*.po --regexp=^msg ./
[/console]

- установка sticky-бита - 1;
Последний атрибут устарел, и используется редко.

Рассмотрите sticky-бит на каталоге, назвать редким такое использование у меня язык не повернётся.

Навигация в дереве имён

$ cat > newfile
...
Ctrl+C

Команды с потоками и конвейерами:

Есть пример, но не описана разница между > и >>.

$ tar -zxvf abs-guide-flat.tar.gz
$ tar -jxvf ldd3_pdf.tar.bz2
- это показано создание разархивирование из форматов .zip и .bz2, соответственно.

Не стоит смешивать .zip и .gz и провоцировать ошибки. Так повелось, что .zip -- это формат архива, zip/unzip архиватор/компрессор/декомпрессор. А вот gzip/gunzip -- только компрессор/декомпрессор.

bormant написал:

Только простые ключи (односимвольные, начинающиеся с однократного '-') могут иметь значения, «длинные» опции (многосимвольные, начинающиеся с 2-х '-') значений не имеют:
$ gcc --help

Например,
[console]
$ grep -R --include \*.po --regexp=^msg ./
[/console]

bormant, вы слишком придирчивы :lol:

- мы с вами всё время говорим о разных вещах.... аж смешно, право wink

- я сказал, что этот текст писался только и исключительно для программистов-разработчиков (вы название не пропустили? wink ), которым нужно быстро доквалифицироваться до проектов под Linux (у них, предположительно, хороший опыт программных проектов в С, и 10 лет и более ... это не пыонэры со студенческой скамьи)... часто это реально: перенос (портирование) того, что уже написано и работает в другом окружении в Linux.

- текст этот не представлялся как учебник (там написано), и не рассчитан, скажем, на администраторов системы Linux... сам я, к большому счастью wink - никогда не был профессиональным системным администратором, а много-много лет был практическим разработчиком и системотехником... и мне чужды чаяния администраторов, каюсь wink

- так вот, относительно программистов и опций wink : программисту понятно, что когда программа написана с использованием POSIX API getopt() & getopt_long() (если вам это что-то говорит), то она ведёт себя ровно так, как я написал, и делает это не только в системе Linux, но и в любой другой системе использующей POSIX API ("... и в Африке...") ... и подавляющее большинство утилит работают именно так (в частности и gcc, который использует то, что называется в API "зарезервированной POSIX опцией -W...")...

- но редкое меньшинство утилит можно написать (и я тоже могу wink , но нужно ли?) с ручным разбором параметров командной строки ... и здесь я могу учудить хоть опцию, начинающуюся с 3-х '-' + хоть 5 параметров у такой опции ... но это - не правило, а исключение!

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

bormant написал:

Команды с потоками и конвейерами:

Есть пример, но не описана разница между > и >>.

Тем, у кого 10-летний опыт программной разработки это и без описаний понятно (ещё с MS-DOS wink ), это вспоминается только в качестве напоминания...

Я не придирчив, а объективен.
Пишете поверхностный обзор -- замечательно, только не надо допускать заведомо ложных утверждений, вот и всё.
Пишете про длинные опции, сделайте оговорку "как правило", "библиотекой getopt", etc., тем более, что grep не самая бесполезная для разработчика команда.

Если для вас подобные "мелочи" норма, извините, не буду дальше отвлекать...

bormant написал:

Если для вас подобные "мелочи" норма, извините, не буду дальше отвлекать...

Да нет, что вы ... премного заинтересован :(

Читайте, читайте ... мне страшно интересно как вы начнёте пробуксовывать после первой 1/3 :lol:

Olej написал:

[quote=bormant]

войдя в файловый менеджер (командный интерпретатор) как root, вот так:
$ sudo mc
# whoami
root

почему не стандартное:[console]$ sudo -i
# whoami
root
[/console]

Потому, что я просто не знаю такого способа wink (сейчас проверю).
... и что значит "стандартное"? каким это стандартом оговорено? wink
Но, поскольку (особенно в POSIX OS) любую вещь можно сделать миллионом способов, то и указанного мной способа - достаточно wink[/quote]

То, что таким sudo можно создать новую оболочку shell - знал, но что это сработает в Ubuntu? oO ... не предполагал (я редко бываю в Ubuntu, только для проверки отличий от других дистрибутивов).
Но если так элементарно просто в Ubuntu получить shell с правами root, то как же быть со всей идеологией и разговорами о "дистрибутивах с отключенным локальным входом root" ... столь много обсуждаемые в сообществах Ubuntu и еже с ней? Тогда не нужно об этом и шума подымать? Чем это отличается от: su - ?
bormant, какое ваше собственное мнение (IMHO) на этот счёт? ... потому, что в подобных вопросах может быть только мнение (преференс wink ), не более...

Идеология -- для влияния на умы, а на железе работают вполне конкретные технические решения. Так что, идеология в данном случае -- только "типичный сценарий использования", не более того.
Отключенный локальный вход рутом -- это всего лишь невозможность залогиниться под известным именем root, только подбирая пароль. А после логина лицо авторизовано, что можно или нет опеделяется системой, в т.ч. /etc/sudoers

Olej,
в последующих двух третях достаточно неточностей, явных ошибок, упущений. Например,

text

   char *error = dlerror();
   if( error != NULL ) {
      printf( "ERROR: %s\n", dlerror() );
      return 4;
   }

Не ошибка, но непоследовательно -- завели переменную для исключения повторного вызова dlerror(), но не используете по назначению. В результате те же 2 вызова dlerror(). Логичным было бы

   if( NULL != dlerror() ) {
      printf( "ERROR: %s\n", dlerror() );
      return 4;
   }

или

   char *error = dlerror();
   if( NULL != error ) {
      printf( "ERROR: %s\n", error );
      return 4;
   }

text

typedef int (*my_func)( char* );
...
my_func func = dlsym( dl_handle, "put_my_msg" );
...
int res = (*func)( messg );

Примечание: Отметим важное малозаметное обстоятельство: вызов функции библиотеки (*func)(messg) по имени происходит без какой-либо синтаксической проверки на соответствие тому прототипу, который объявлен для типа функции my_func. Соответствие обеспечивается только «доброй волей» пишущего код. С таким же успехом функция могла бы вызываться с 2-мя параметрами, 3-мя и так далее. На это место нужно обращать пристальное внимание при написании реальных плагинов.

Возвращаясь к утверждению и последующей его аргументации

Только простые ключи (односимвольные, начинающиеся с однократного '-') могут иметь значения, «длинные» опции (многосимвольные, начинающиеся с 2-х '-') значений не имеют

Olej написал:

- так вот, относительно программистов и опций  : программисту понятно, что когда программа написана с использованием POSIX API getopt() & getopt_long() (если вам это что-то говорит), то она ведёт себя ровно так, как я написал, и делает это не только в системе Linux, но и в любой другой системе использующей POSIX API ("... и в Африке...") ... и подавляющее большинство утилит работают именно так (в частности и gcc, который использует то, что называется в API "зарезервированной POSIX опцией -W...")...

Интересное рассуждение, и даже весьма правдоподобное...
Вот только
1) getopt_long(), getopt_long_only() являются расширением GNU и не определены в POSIX.
2)

"man 3 getopt" написал:

getopt_long() and getopt_long_only()
The getopt_long() function works like getopt() except that it also accepts long options, started with two dashes. (If the program accepts only long options, then optstring should be specified as an empty string (""), not NULL.) Long option names may be abbreviated if the abbreviation is unique or is an exact match for some defined option. A long option may take a parameter, of the form --arg=param or --arg param.

3) В POSIX.2 действительно для getopt предусмотрена опция -W. Она зарезервирована для реализации расширений (суть -- выходящих за рамки POSIX). Возможность интерпретировать "-W;foo" как длинную опцию --foo является расширением GNU, а не частью стандарта POSIX.


Продолжите настаивать на сказанном или признаете, что немного нафантазировали?

bormant написал:

Возвращаясь к утверждению и последующей его аргументации

Только простые ключи (односимвольные, начинающиеся с однократного '-') могут иметь значения, «длинные» опции (многосимвольные, начинающиеся с 2-х '-') значений не имеют

Olej написал:

- так вот, относительно программистов и опций  : программисту понятно, что когда программа написана с использованием POSIX API getopt() & getopt_long() (если вам это что-то говорит), то она ведёт себя ровно так, как я написал, и делает это не только в системе Linux, но и в любой другой системе использующей POSIX API ("... и в Африке...") ... и подавляющее большинство утилит работают именно так (в частности и gcc, который использует то, что называется в API "зарезервированной POSIX опцией -W...")...

Интересное рассуждение, и даже весьма правдоподобное...
Вот только
1) getopt_long(), getopt_long_only() являются расширением GNU и не определены в POSIX.
2)

"man 3 getopt" написал:

getopt_long() and getopt_long_only()
The getopt_long() function works like getopt() except that it also accepts long options, started with two dashes. (If the program accepts only long options, then optstring should be specified as an empty string (""), not NULL.) Long option names may be abbreviated if the abbreviation is unique or is an exact match for some defined option. A long option may take a parameter, of the form --arg=param or --arg param.

3) В POSIX.2 действительно для getopt предусмотрена опция -W. Она зарезервирована для реализации расширений (суть -- выходящих за рамки POSIX). Возможность интерпретировать "-W;foo" как длинную опцию --foo является расширением GNU, а не частью стандарта POSIX.


Продолжите настаивать на сказанном или признаете, что немного нафантазировали?

1. http://www.books.ru/books/unix-professionalnoe-programmirovanie-503720/

стр. 1014 (алфавитный указатель)

getopt, функция, 727, 802, 883, 887, 931

Или Стивенс ... не? :D

2. http://pubs.opengroup.org/onlinepubs/9699919799/

The Open Group Base Specifications Issue 7
IEEE Std 1003.1-2008
Copyright © 2008 The IEEE and The Open Group, All Rights reserved.

NAME
getopts - parse utility options
SYNOPSIS
getopts optstring name [arg...]
DESCRIPTION
The getopts utility shall retrieve options and option-arguments from a list of parameters. It shall support the Utility Syntax Guidelines 3 to 10, inclusive, described in XBD Utility Syntax Guidelines .
...

Так что, пожалуй wink , лучше настаивать...
Но эти обсуждения и аргументацию, на чём я настаиваю - в текст включу :lol: