Два из основных основных принципов философии UNIX
и ожидайте, что вывод каждой программы станет входом другому, как
все же неизвестный, программа.
Использование каналов позволило, Вы усилить эффекты этих двух разрабатываете
основные принципы для создания чрезвычайно мощных цепочек команд для достижения желаемого результата.
Большинство программ командной строки, которые воздействуют на файлы, может также принять вход по стандарту в (вход через клавиатуру) и произвести к стандарту (печать на
экран).
Некоторые команды разработаны, чтобы только работать в канале, не может воздействовать на файлы непосредственно.
например, tr
команда
ls -C | tr 'a-z' 'A-Z'
cmd1 | cmd2
Отправляет STDOUT cmd1 к STDIN cmd2 вместо экрана.
STDERR не передается через каналы.
Короче говоря Pipes is character (|)
может соединить команды.
Любая команда, которая пишет в STDOUT, может быть использоваться на левой стороне канала.
ls - /etc | less
Любая команда, которая читает из STDIN, может использоваться на правой стороне канала.
echo "test print" | lpr
Традиционный канал "без имени", потому что он существует анонимно и сохраняется только столько, сколько процесс работает. Именованный канал является персистентным системой и существует вне жизни процесса и должен быть удален, после того как это больше не используется. Процессы обычно присоединяют к именованному каналу (обычно появляющийся как файл) для выполнения межпроцессного взаимодействия (IPC).
источник: http://en.wikipedia.org/wiki/Named_pipe
Существует несколько возможных ответов в зависимости от того, что точно Вы хотите знать (я не знаю который один AIX bootinfo
соответствует).
Вы видите, является ли ЦП 64-разрядным, 32-разрядным, или способным к обоим путем проверки flags
строка в /proc/cpuinfo
. Необходимо знать возможные флаги на семействе архитектуры. Например, на i386/amd64 платформах, lm
флаг определяет amd64-способные центральные процессоры (центральные процессоры, которые не имеют того флага, i386-только).
Вы видите, является ли ядро 32-разрядным или 64-разрядным путем запросов архитектуры с uname -m
. Например, i[3456]86
являются 32-разрядными в то время как x86_64
является 64-разрядным. Обратите внимание, что на нескольких архитектуре, 64-разрядное ядро может запустить 32-разрядные программы пространства пользователя, поэтому даже если uname -m
показывает 64-разрядное ядро, нет никакой гарантии, что 64-разрядные библиотеки будут доступны.
Вы видите то, что доступно в пространстве пользователя путем запросов поддержки LSB с lsb_release
команда. Более точно, lsb-release -s
печать a :
- разделенный список поддерживавших функций LSB. Каждая функция имеет formm module-*version*-architecture
. Например, доступность библиотеки ix86 C обозначается core-2.0-ia32
, в то время как core-2.0-amd64
аналог для amd64. Не каждое распределение объявляет все доступные модули LSB, хотя, таким образом, больше может быть доступным, чем обнаруживаемо таким образом.
Можно узнать предпочтительный размер слова для разработки (предполагающий, что компилятор C доступен) путем компиляции программы C с 5 строками, которая печатает sizeof(void*)
или sizeof(size_t)
.
Обычно uname -m
должен добиться цели, как должен arch
.
Вывод обеих из этих команд скажет Вам архитектуру, для которой было создано ядро. Является ли это 32 или 64 битами, обычно довольно ясно (x86_64, и ia64 являются двумя возможной 64-разрядной архитектурой). Однако обратите внимание, что у Вас могло быть 32-разрядное ядро при работе 64-разрядных аппаратных средств. Если Вы действительно хотите знать об аппаратной попытке смотреть также
less /proc/cpuinfo
если строка "флагов" имеет 'lm' в ней, то это - 64 бита.
Или, если Вы имеете lshw
lshw -class processor
и посмотрите на строку "ширины".
Для обеих из этих опций, grep
может использоваться для быстрого получения ответа, не смотря на вывод.
uname -m
говорит Вам архитектуру, для которой было создано ядро. Например, существует несколько систем там с amd64 ядром, но 32-разрядным пространством пользователя. Точное замечание Gilles
– Gilles 'SO- stop being evil'
11.10.2010, 21:57