ну или итоговые варианты:

sed -rne '/core id|physical id/{s/.*: (.*)/\1 /;H};/^$/{x;s/\n//g;p}'  /proc/cpuinfo | wc -l

ну не так уж и сложно в итоге получилось

sed -rne '/processor|core id|physical id/{s/.*: (.*)/\1 /;H};/^$/{x;s/\n//g;p}'
sed -rne '/processor|core id|physical id/{s/.*: (.*)/\1 /;H};x;/.*\n.*\n.*\n/{s/\n//g;p;s/.*//};x'

ну или итоговые варианты:

sed -rne '/core id|physical id/{s/.*: (.*)/\1 /;H};/^$/{x;s/\n//g;p}'  /proc/cpuinfo | wc -l
sed -rne '/core id|physical id/{s/.*: (.*)/\1 /;H};x;/.*\n.*\n/{s/\n//g;p;s/.*//};x' /proc/cpuinfo | wc -l

если тупо записать:

ну а если подумать?
Понятное дело, что у вас прочитается не та строчка. И разве не ясно, как это исправить?
Можно конечно начать разбор с "processor", а потом ждать "physical id", ну и потом ждать "core id", загружая в цикле строчки... Но есть способ лучше - использовать команду H вместо N, и произвести парсинг после получения "core id". Разве это не очевидно? Не? Ну тогда зачем вы вообще используете sed? Сложно выучить такой примитивный ЯП на половину... Проще него разве что BrainFuck, но он и придуман как "простой", а sed придумана для обработки текстов. И свою задачу вополняет хорошо, не нуждаясь в дополнительных костылях (grep в данном случае - костыль, ибо никто не просил нас фильтровать строчки, это просто первое, что пришло вам в голову. Однако первое - почти всегда худшее.)

sed '/условие/{скрипт;}'

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

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
...

как скрипт работает:

/processor|core id|physical id/{ # на первой строке срабатывает, в буфере: "processor       : 0"
    N # читаем вторую строку, в буфере "processor       : 0\nvendor_id       : GenuineIntel"
    N # читаем вторую строку, в буфере "processor       : 0\nvendor_id       : GenuineIntel\ncpu family      : 6"
    s/[^:]*: (.*)\n[^:]*: (.*)\n[^:]*: (.*)/\1 \2 \3/ # на выходе "0 GenuineIntel 6"
} # и так три раза.

вы покажите хоть как без grep'а сделать... болей-менее простым способом

ага.

потому как в логически разрозненные кусочки намного проще вставить свою букашку. Вы это называете "хорошим программным интерфейсом", я это называю глючащим и тормозным РЕШЕТОМ.

что, всё? с sort -u таки попроще. И уже можно сделать, если прочитать прошлые сообщения. Можно и без sort -u, это сложнее, и интереснее.

вы покажите хоть как без grep'а сделать... болей-менее простым способом, чтобы это не уменьшило читаемость, которая, приходится признать, и так не на высоте.

я их как раз думал упомянуть их тут аль нет =)

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

тогда хоть подскажите тогда, где они?

если б нашёл - то я бы их процитировал хотя-бы.

что, всё? с sort -u таки попроще. И уже можно сделать, если прочитать прошлые сообщения. Можно и без sort -u, это сложнее, и интереснее.

я не физик. да и физики тоже так не считают.

ага. хорошо, пусть будет

Я доки видел, но таки не вдавался. Потому не помню.чёрт его знает, что это за НЁХ.

тогда хоть подскажите тогда, где они? в /usr/src/linux/Documentation/ про это нет...

я просто завинтил крестовой шуруп плоской отвёрткой... может не так удобно, как крестовой, но шуруп в стене...

кстати... ну и как же это всё записать в один sed-скрипт?

ИМХО можно условно считать программу рабочей, пока не будет найден контрпример. на многоядерных системах оно тоже работает правильно... ИМХО должно и на остальных SMP работать...

только вот "удобная" это точно такой же НЁХ

я вообще не понял, причём тут это... подумал опечатка...

ага. очепятка.

естественно !$

верно. но верно только для одноразовых одностроков. А зачем вы тут использованную туалетную бумагу выложили?
однако, даже одноразовые одностроки быстрее и проще писать именно так, как я говорю, а не тупо дописывая в конец разные костылики. Иначе это получается (на практике) многострочный однострок, разобраться в котором нет уже никакой возможности, и костыли уже не помогают - ошибка где-то посередине, но даже добираться до этой середины жутко долго. А вот используя мой метод вы получаете компактный sed-однострок, к которому достаточно добавить ваше любимое wc -l, и получить профит.

ну если рискнуть, и заглянуть внутрь маздайного приложения, мы и увидим знакомые костыли :p
что, кстати, сильно облегчает их взлом. Что до скриптов, так они в маздае вообще не работают. Да и смыла в них нет никакого: какой смысл делать bat файл из одной команды? А две туда уже и не вставить (точнее, вставить можно, но только если они несвязанные, а просто 2 команды). В принципе, в bash тоже имеется эта проблема. За то только в bash нативно вставляются shell команды, в любом другом ЯП (не shell) эти команды вставляются костыльно, потому нормально работать там можно только со встроенными функциями. Дилемма...

скажите как это в одном sed скрипте сделать, учитывая наличие N. простым способом у меня с ходу не получилось...

doc@dt:~/tmp$ grep 'processor\|core id\|physical id' ci | sed -re 'N;N;s/[^:]*: (.*)\n[^:]*: (.*)\n[^:]*: (.*)/\1 \2 \3/' -e 's/[^ ]* //'
0 0
0 1
0 9
0 10
1 0
1 1
1 9
1 10
0 0
0 1
0 9
0 10
1 0
1 1
1 9
1 10
doc@dt:~/tmp$ grep 'processor\|core id\|physical id' ci | sed -re 'N;N;s/[^:]*: (.*)\n[^:]*: (.*)\n[^:]*: (.*)/\1 \2 \3/;s/[^ ]* //'
0 0
0 1
0 9
0 10
1 0
1 1
1 9
1 10
0 0
0 1
0 9
0 10
1 0
1 1
1 9
1 10
doc@dt:~/tmp$ grep 'processor\|core id\|physical id' ci | sed -r 'N;N;s/[^:]*: (.*)\n[^:]*: (.*)\n[^:]*: (.*)/\1 \2 \3/;s/[^ ]* //'
0 0
0 1
0 9
0 10
1 0
1 1
1 9
1 10
0 0
0 1
0 9
0 10
1 0
1 1
1 9
1 10

м... чем вам N помешала-то? N прибавляет к внутреннему буферу sed следующую строку. Кстати, если команда не туда что-то добавляет (как =), то ваше -e всё равно не поможет, и необходимо ставить вторую sed. Насколько я помню, -e необходима только в ОДНОМ случае: когда вам внутри sed-скрипта потребуется использовать команду с параметром типа "строка", ну например

sed -e 'W имя_файла' -e 'ещё_команды'

тут точка с запятой будет считаться как часть "имя_файла" внутри скрипта, а если -e не написать, то вторая часть скрипта будет считаться за имя входного файла. Правда можно разделять команды переводом строки, а не только точкой с запятой, если ваша оболочка конечно на такое способна. Однако, команды с параметрами в одностроках - большая редкость. Следует подумать о sed-скрипте в виде файла.

у нас этот пример ЕДИНСТВЕННЫЙ. Найдите хотя-бы штук 10, а то у меня вот тоже нет под рукой многоядерных и многопроцессорных систем. Я доки видел, но таки не вдавался. Потому не помню.
чёрт его знает, что это за НЁХ.

эх... Ваще-то задача: выделить второе и третье число. Вы зачем-то выделяете ещё и первое. Если так рассуждать, то что вы [^:]* в начале не выделяете? Не число? Кстати вот ещё одна грубая ошибка: условие должно быть как можно более жёстким. Если в поле ТОЛЬКО ЦИФРЫ, то так и пишите: [0-9]+, скрипты и так опасные, потому всегда надо думать, и если условие не выполнилось, то либо выдавать ошибку и её проверять, либо эту ошибку обрабатывать как-то. Вот у вас только цифры, а вы пишите .* => злоумышленник сможет скормить вашему скрипту любую НЁХ. Да, это конечно в данном случае не важно, но... Зачем вам оставлять лишнюю дыру? Тут и не только в безопасности дело - если попадётся что-то не то, то поведение скрипта станет непредсказуемым. Оно может и не опасно, или безопасность вас не волнует, просто скрипт сработает хрен знает как, и выдаст хрен знает что. А дальше вы кормите конвейер хрен знает чем, и в итоге получаете не только хрен знает какую ошибку или хрен знает что, но ещё и хрен знает где. Естественно, исправлять тоже хрен знает как. Проще выкинуть скрипт в мусорку, как и всю вашу работу по созданию костылей и подпорочек. Уж поверьте мне, я такого быдлокода повыкидывал немало (ИЧСХ своего). Впрочем: наступать на грабли - ваше священное право. А если кто вам говорит "не ходи туда, грабли", то можете его и послать, а чё - вы свободны.

нет. Продолжать забивать шурупы молотком, ибо - работает. Ненадёжно, криво, сложно и долго; ну и хрен с ним. Разве это повод учится пользоваться отвёрткой? :p

дык bash во первых считает через хрен пойми как, так и со строками работает не лучше. Его только как связку, ну или там для _простых_ операций с числами и строками. Ещё он тормооооознооооой. Т.е. в теоретических примерчиках bash всё умеет, вплоть до встроенной СУБД, а на практике... Как морской бой на BrainFuck'е. Т.е. только простенькие задачи можно, вот например Патрег сделал БД в виде простого текствого файла, который потом грузится в bash-массив. Для сетевых интерфейсов, eth0, eth1, и т.д. Всё отлично работает. Вот как у меня. У меня этих eth ровно 3 штуки (на одном из компьютеров, на других вообще по одному).

это с какого такого перепугу он стал "всеобщим"? Всеобщий метод - поделить программу на отдельные модули, и развивать их самостоятельно, до тех пор, пока разработчик сможет этот модуль целиком в голове держать. Как не сможет - делить модуль на отдельные части. Как же вы скрипт пишете, если даже один однострок в голове удержать не в состоянии?? IRL задачки куда как больше. У нас задачка вполне примитивная, и делить её имеет смысл только если у нас нет подходящего инструмента (т.е. в нашем случае нужно grep и sed записать одним скриптом, причём так, что-бы в этом скрипте было как можно меньше структурных единиц, например команд s, ну а потом нам придётся решить, как выделять повторяющиеся строчки, sed'ом делать sort -u довольно костыльно(хоть и можно), потому придётся применить другой инструмент, при этом ещё и придётся подумать, что произойдёт на стыке этих команд, если что-то пойдёт не так. IRL это очень непростая задача, в итоге получится sed через bash-связку sort -u)

по вашему, правильный ответ в ЕДИНСТВЕННОМ случае это значит "работает"? Не... "Работает", это когда строго доказано, что при ЛЮБЫХ входных данных программа выдаст верный ответ, или вменяемое сообщение об ошибке, если входные данные недопустимы. Это конечно идеал, но вашему скрипту до этого идеала как до самой дальней галактики.

в данном случае "интерфейса" в смысле человеко-машинного просто тупо нет. Есть интерфейс с ядром, потому тут проще. Это я про входной. Что касается выходного, то перед wc -l неплохо было-бы выдать удобочитаемый для человека листинг, в котором написано, на основании какой информации из ядра программа сделала такой вывод. Полезно хотя-бы в отладочных целях. Просто cat /proc/cpuinfo на такой листинг не катит, нужно где-то по середине оформить вывод в консоль нужных оформленных строчек. А то к ответу "17" веры у меня никакой нет. Т.ч. с интерфейсом у вас тоже никак.

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

я вам зря что-ли про $! рассказывал?! Это очень сильное колдунство. Попробуйте.

я вообще не понял, причём тут это... подумал опечатка...

или что не так?

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

ну во первых, тут та же беда, что и с cat: зачем две команды-то? когда и sed это просто навороченная grep. Что, "удобнее"?

скажите как это в одном sed скрипте сделать, учитывая наличие N. простым способом у меня с ходу не получилось...

ну да.... ничего лучшего пока не придумал... доков по сабжу не видел, код ковырять - не хочется... к тому же, если --=XliN=-- не обманул всех со злым умыслом, то пример вполне достоверен.

две логические части: первая - выстроить в одну строчку три числа, вторая - удалить одно из них.

мда... согласен... это выглядит нелогично... но см. п.3

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

для этого уже предполагается использовать bash...

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

3. мне влом писать "посчитайте количество строчек"
4. в скриптах

3. см пункт №2.
4. мимо кассы. Кстати, IRL в скриптах я что-то эту команду очень редко юзаю. Просто потому, что IRL надо либо получить строчку с результатом, и её юзать, либо получить список строк, и обрабатывать их отдельно. wc -l, как побочный результат (если это нужно), во втором случае можно и посчитать, если оно конечно надо.

два варианта:
1. доступа к BIOS нет(злой одмин не включает). Ну нет, и нет. Зачем узнавать то, что не изменить? Может у злого одмина какие-то свои резоны.
2. доступ есть (добрый одмин) - можно спросить, и при желании включить.
Ну конечно можно придумать третий случай, когда сервер свой, в соседней комнате, идти лениво. Ну дык пусть пока так работает...

см. выше про маздайный метод. ИЧСХ, клавиш вам нажимать не меньше(с маздайным методом), если не больше. Правда нужно немного думать, но это полезно.
Однострок - тоже программа, и писать его можно вообще говоря тремя способами (как и программу)
1. каждый раз с нуля
2. добавляя костыли и подпорки
3. изменяя некоторые части, полностью или частично.
Какой способ лучше? Конечно №3. Но вы используете №2.
(вообще говоря, формально №1 и №2 это терминальные стадии №3, где вы видели IRL терминальные стадии??)

я вам зря что-ли про $! рассказывал?! Это очень сильное колдунство. Попробуйте.
(правда на grep 'xx'  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|sed ''|ещё 100500 команд данное колдунство уже не действует, если надо grep 'xx' поменять)

да уж будьте добры, просветите, что тут не так...

ну во первых, тут та же беда, что и с cat: зачем две команды-то? когда и sed это просто навороченная grep. Что, "удобнее"? А зачем такое советовать? Если даёте совет, будьте любезны, напишите код грамотно, а не так, как вам это "удобнее", как видите, за вами повторяют, и используют ваши команды для других целей. В данном случае _вам_ не нужно набирать grep, но _читателю_ ведь придётся? А для кого вы это вообще написали? для себя? (кстати, лично вас это не касается, но вообще это замечание важно для любой грамотности, в т.ч. и для русского - слово "карова" прочитать сложнее чем "корова", хотя и так понятно, о чём тут речь).
Т.е. следует заменить grep 'условие' | sed 'скрипт' на sed '/условие/{скрипт;}'. Оно и читается легче, теми кто с sed знаком (кто не знаком всё равно не распарсит).

Во вторых, с core id разобрались? Зачем оно? Что-бы потом отсортировать, в предположении, что у процессоров на одно физическое ядро обязательно приходится уникальное core id? А почему это так? А что это вообще такое? Сама логика скрипта построена на единственном частном случае.

В третьих, а что так любят использовать sed с опцией -e? Да ещё и с двумя скриптами? Очевидно, что про точку с запятой вы знаете, но почему-то всё равно бьёте скрипт на две части? Опять-таки - зачем? Осложнить жизнь читателю?

В четвёртых, вы бьёте строку на три поля, потом выводите поля №1, №2 и №3, и затем поле №1 стираете. Какой в этом смысл? Легче писать? Бред полный, просто-бы стёрли \1 в прошлой команде, и тогда первое поле не пропечатолось.

В пятых, для работы с полями уместнее gawk, а не эта ваша sed. Она ещё и считать умеет, и смогла-бы просто посчитать число ядер, и поделить его на число cpu. (см. во вторых. На sed это сделать очень сложно)

Ну и ещё 100500 мелочей, о которых и вспоминать не хочется...

Но самое главное конечно это маздайный метод тыка:
1. написать какую-то НЁХ
2. т.к. это работает совсем не так как надо, дописать чего-то для исправления/доделывания
3. goto 2, до тех пор, пока не получится верный ответ.
Ну и что вы хотите получить от меня, акромя sage.jpg? Я уж молчу про то, что вы получите от тех, кто этот ваш writeonly "код" будет затачивать под свои нужды или поддерживать...