Тогда вопросы:
1. Почему ?
2. Как правильно ?
1. потому-что уже писал здесь раз 5. вкратце: вредная привычка, как палец сосать. вред тоже есть.
2. grep 'условие' file
LinuxForum.Fans
Как узнать включен ли HyperThreading?
Автор: XliN
39 сообщений
10082 просмотров
откуда видно, что у вас 2 процессора, на каждом из них 4 ядра(cpu cores), но каждое ядро видится как 2, из-за HT.
не вникнув в суть вопроса на всех кипятком писаете... ноги у темы растут отсюда: Очередной speedtest (memory)
ЗЫЖ за cat file | grep 'условие' скоро начну минусовать.
да ладно... тут он вполне логично смотрится: сделал cat - много букаф... нажал вверх, дописал grep - всё равно много... ну итд...
К чему тут core id - совершенно непонятно, кстати.
а это похоже ошибка с моей подачи... думал, что core id - уникален для ядра... или поэтому и не использовал sort изначально (у меня "HT'шные версии" идут сразу за обычными)... не помню уже...
в любом случае общее кол-во ядер можно как-то так посчитать:
text
grep 'processor\|core id\|physical id' /proc/cpuinfo | sed -re 'N;N;s/[^:]*: (.*)\n[^:]*: (.*)\n[^:]*: (.*)/\1 \2 \3/' -e 's/[^ ]* //' | sort -u | wc -lКстати, а как его выключить?
обычно в биосе
вот буду я всякий бред в толксах читать...не вникнув в суть вопроса на всех кипятком писаете... ноги у темы растут отсюда: Очередной speedtest (memory)
зачем мне ваша очередная пиписькомерка? я нужный мне параметр в нужных мне условиях и так за 5 минут проверю. а такое "ПО" годится только пиписьками мерится.
да ладно... тут он вполне логично смотрится: сделал cat - много букаф... нажал вверх, дописал grep - всё равно много... ну итд...
а grep 'условие' $! как оно вам? многобукв в упор не вижу.
в любом случае общее кол-во ядер можно как-то так посчитать:
facepalm
или это вы так хотите всех запутать? ага. А потом я удивляюсь, откуда новички такой бред неграмотный берут? Ну с LF же!
Даже комментировать не буду.
ЗЫЖ что касается wc -l, то она применяется в двух случаях:
1. аффтор хочет доказать, что 4 строчки, но не хочет их показывать (сам-то он их видит, в отличие от наших новичков)
2. строчек Over9000 - мимо кассы.
PS:
обычно в биосе
ну ваще-то cpu cores даёт ответ про HT. Я имел ввиду, где оно в OS отключается? Да и зачем оно нужно, если к BIOS'у доступа всё равно нет?
или это вы так хотите всех запутать? ага. А потом я удивляюсь, откуда новички такой бред неграмотный берут? Ну с LF же!Даже комментировать не буду.
да уж будьте добры, просветите, что тут не так... что s можно покрасивее оформить? дык наверно можно...
ЗЫЖ что касается wc -l, то она применяется в двух случаях:
3. мне влом писать "посчитайте количество строчек"
4. в скриптах
ну ваще-то cpu cores даёт ответ про HT. Я имел ввиду, где оно в OS отключается?
[fixme] а на уровне ОС оно вроде не отключается... ЕМНИП для HT есть отдельный планировщик в ядре... можно его выпилить...
Да и зачем оно нужно, если к BIOS'у доступа всё равно нет?
это как?
а grep 'условие' $! как оно вам? многобукв в упор не вижу.
дык порядок: сделал cat, подумал, нажал вверх дописал grep, не то... ещё подумал, исправил выражение итд... (если файл на конце, то нужно сильно назад стрелками отбивать... а если у него ещё и имя большое...) в итоге выделил в консоли, вставил сюда...
да уж будьте добры, просветите, что тут не так...
grep 'processor\|core id\|physical id' /proc/cpuinfo | sed -re 'N;N;s/[^:]*: (.*)\n[^:]*: (.*)\n[^:]*: (.*)/\1 \2 \3/' -e 's/[^ ]* //' | sort -u | wc -l
ну во первых, тут та же беда, что и с 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 "код" будет затачивать под свои нужды или поддерживать...
3. мне влом писать "посчитайте количество строчек"
4. в скриптах
3. см пункт №2.
4. мимо кассы. Кстати, IRL в скриптах я что-то эту команду очень редко юзаю. Просто потому, что IRL надо либо получить строчку с результатом, и её юзать, либо получить список строк, и обрабатывать их отдельно. wc -l, как побочный результат (если это нужно), во втором случае можно и посчитать, если оно конечно надо.
Да и зачем оно нужно, если к BIOS'у доступа всё равно нет?
это как?
два варианта:
1. доступа к BIOS нет(злой одмин не включает). Ну нет, и нет. Зачем узнавать то, что не изменить? Может у злого одмина какие-то свои резоны.
2. доступ есть (добрый одмин) - можно спросить, и при желании включить.
Ну конечно можно придумать третий случай, когда сервер свой, в соседней комнате, идти лениво. Ну дык пусть пока так работает... :)
дык порядок: сделал cat, подумал, нажал вверх дописал grep, не то... ещё подумал, исправил выражение итд..
см. выше про маздайный метод. ИЧСХ, клавиш вам нажимать не меньше(с маздайным методом), если не больше. Правда нужно немного думать, но это полезно.
Однострок - тоже программа, и писать его можно вообще говоря тремя способами (как и программу)
1. каждый раз с нуля
2. добавляя костыли и подпорки
3. изменяя некоторые части, полностью или частично.
Какой способ лучше? Конечно №3. Но вы используете №2.
(вообще говоря, формально №1 и №2 это терминальные стадии №3, где вы видели IRL терминальные стадии??)
если файл на конце, то нужно сильно назад стрелками отбивать... а если у него ещё и имя большое...
я вам зря что-ли про $! рассказывал?! Это очень сильное колдунство. Попробуйте.
(правда на grep 'xx' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|sed ''|ещё 100500 команд данное колдунство уже не действует, если надо grep 'xx' поменять)
ну во первых, тут та же беда, что и с cat: зачем две команды-то? когда и sed это просто навороченная grep. Что, "удобнее"?
скажите как это в одном sed скрипте сделать, учитывая наличие N. простым способом у меня с ходу не получилось...
Во вторых, с core id разобрались? Зачем оно? Что-бы потом отсортировать, в предположении, что у процессоров на одно физическое ядро обязательно приходится уникальное core id? А почему это так? А что это вообще такое? Сама логика скрипта построена на единственном частном случае.
ну да.... ничего лучшего пока не придумал... доков по сабжу не видел, код ковырять - не хочется... к тому же, если --=XliN=-- не обманул всех со злым умыслом, то пример вполне достоверен.
В третьих, а что так любят использовать sed с опцией -e? Да ещё и с двумя скриптами? Очевидно, что про точку с запятой вы знаете, но почему-то всё равно бьёте скрипт на две части? Опять-таки - зачем? Осложнить жизнь читателю?
две логические части: первая - выстроить в одну строчку три числа, вторая - удалить одно из них.
В четвёртых, вы бьёте строку на три поля, потом выводите поля №1, №2 и №3, и затем поле №1 стираете. Какой в этом смысл? Легче писать? Бред полный, просто-бы стёрли \1 в прошлой команде, и тогда первое поле не пропечатолось.
мда... согласен... это выглядит нелогично... но см. п.3
В пятых, для работы с полями уместнее gawk, а не эта ваша sed.
ну не знаю я awk, и пока не испытываю потребности в его изучении... и что мне теперь? не предлагать альтернативные варианты? лизнуть розетку? повеситься?
Она ещё и считать умеет, и смогла-бы просто посчитать число ядер, и поделить его на число cpu. (см. во вторых. На sed это сделать очень сложно)
для этого уже предполагается использовать bash...
Но самое главное конечно это маздайный метод тыка:
1. написать какую-то НЁХ
2. т.к. это работает совсем не так как надо, дописать чего-то для исправления/доделывания
3. goto 2, до тех пор, пока не получится верный ответ.
это всеобщий метод и он вполне имеет право на существование. т.к. самое главное. чтобы что-то работало, работало без ошибок и имело очевидный интерфейс, а уж красота - это второй план.
я вам зря что-ли про $! рассказывал?! Это очень сильное колдунство. Попробуйте.
я вообще не понял, причём тут это... подумал опечатка...
!
Expands to the process ID of the most recently executed background (asynchronous) command.
или что не так?
Однострок - тоже программа, и писать его можно вообще говоря тремя способами (как и программу) .
только вот в этой программе важна скорость написания... и т.к. размер не большой, то количество костылей не выходит за рамки разумного.
кроме того мастдай конкатенацией костылей уж точно не славится... там что ни костыль, то комбайн...
скажите как это в одном sed скрипте сделать, учитывая наличие N. простым способом у меня с ходу не получилось...
text
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-скрипта потребуется использовать команду с параметром типа "строка", ну например
text
sed -e 'W имя_файла' -e 'ещё_команды'тут точка с запятой будет считаться как часть "имя_файла" внутри скрипта, а если -e не написать, то вторая часть скрипта будет считаться за имя входного файла. Правда можно разделять команды переводом строки, а не только точкой с запятой, если ваша оболочка конечно на такое способна. Однако, команды с параметрами в одностроках - большая редкость. Следует подумать о sed-скрипте в виде файла.
у нас этот пример ЕДИНСТВЕННЫЙ. Найдите хотя-бы штук 10, а то у меня вот тоже нет под рукой многоядерных и многопроцессорных систем. Я доки видел, но таки не вдавался. Потому не помню.ну да.... ничего лучшего пока не придумал... доков по сабжу не видел, код ковырять - не хочется... к тому же, если --=XliN=-- не обманул всех со злым умыслом, то пример вполне достоверен.
чёрт его знает, что это за НЁХ.
две логические части: первая - выстроить в одну строчку три числа, вторая - удалить одно из них.
эх... Ваще-то задача: выделить второе и третье число. Вы зачем-то выделяете ещё и первое. Если так рассуждать, то что вы [^:]* в начале не выделяете? Не число? Кстати вот ещё одна грубая ошибка: условие должно быть как можно более жёстким. Если в поле ТОЛЬКО ЦИФРЫ, то так и пишите: [0-9]+, скрипты и так опасные, потому всегда надо думать, и если условие не выполнилось, то либо выдавать ошибку и её проверять, либо эту ошибку обрабатывать как-то. Вот у вас только цифры, а вы пишите .* => злоумышленник сможет скормить вашему скрипту любую НЁХ. Да, это конечно в данном случае не важно, но... Зачем вам оставлять лишнюю дыру? Тут и не только в безопасности дело - если попадётся что-то не то, то поведение скрипта станет непредсказуемым. Оно может и не опасно, или безопасность вас не волнует, просто скрипт сработает хрен знает как, и выдаст хрен знает что. А дальше вы кормите конвейер хрен знает чем, и в итоге получаете не только хрен знает какую ошибку или хрен знает что, но ещё и хрен знает где. Естественно, исправлять тоже хрен знает как. Проще выкинуть скрипт в мусорку, как и всю вашу работу по созданию костылей и подпорочек. Уж поверьте мне, я такого быдлокода повыкидывал немало (ИЧСХ своего). Впрочем: наступать на грабли - ваше священное право. А если кто вам говорит "не ходи туда, грабли", то можете его и послать, а чё - вы свободны.
ну не знаю я awk, и пока не испытываю потребности в его изучении... и что мне теперь? не предлагать альтернативные варианты? лизнуть розетку? повеситься?
нет. Продолжать забивать шурупы молотком, ибо - работает. Ненадёжно, криво, сложно и долго; ну и хрен с ним. Разве это повод учится пользоваться отвёрткой? :p
для этого уже предполагается использовать bash...
дык 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. Вот и всё.
я вообще не понял, причём тут это... подумал опечатка...
ага. очепятка.
Word Designators
Word designators are used to select desired words from the event. A : separates the event specification from the word designa-
tor. It may be omitted if the word designator begins with a ^, $, *, -, or %. Words are numbered from the beginning of the
line, with the first word being denoted by 0 (zero). Words are inserted into the current line separated by single spaces.
0 (zero)
The zeroth word. For the shell, this is the command word.
n The nth word.
^ The first argument. That is, word 1.
$ The last argument.
% The word matched by the most recent `?string?' search.
x-y A range of words; `-y' abbreviates `0-y'.
* All of the words but the zeroth. This is a synonym for `1-$'. It is not an error to use * if there is just one word in
the event; the empty string is returned in that case.
x* Abbreviates x-$.
x- Abbreviates x-$ like x*, but omits the last word.
If a word designator is supplied without an event specification, the previous command is used as the event.
естественно !$ :)
только вот в этой программе важна скорость написания... и т.к. размер не большой, то количество костылей не выходит за рамки разумного.
верно. но верно только для одноразовых одностроков. А зачем вы тут использованную туалетную бумагу выложили? ;)
однако, даже одноразовые одностроки быстрее и проще писать именно так, как я говорю, а не тупо дописывая в конец разные костылики. Иначе это получается (на практике) многострочный однострок, разобраться в котором нет уже никакой возможности, и костыли уже не помогают - ошибка где-то посередине, но даже добираться до этой середины жутко долго. А вот используя мой метод вы получаете компактный sed-однострок, к которому достаточно добавить ваше любимое wc -l, и получить профит.
кроме того мастдай конкатенацией костылей уж точно не славится... там что ни костыль, то комбайн...
ну если рискнуть, и заглянуть внутрь маздайного приложения, мы и увидим знакомые костыли :p
что, кстати, сильно облегчает их взлом. Что до скриптов, так они в маздае вообще не работают. Да и смыла в них нет никакого: какой смысл делать bat файл из одной команды? А две туда уже и не вставить (точнее, вставить можно, но только если они несвязанные, а просто 2 команды). В принципе, в bash тоже имеется эта проблема. За то только в bash нативно вставляются shell команды, в любом другом ЯП (не shell) эти команды вставляются костыльно, потому нормально работать там можно только со встроенными функциями. Дилемма...
Я доки видел, но таки не вдавался. Потому не помню.чёрт его знает, что это за НЁХ.
тогда хоть подскажите тогда, где они? в /usr/src/linux/Documentation/ про это нет...
нет. Продолжать забивать шурупы молотком, ибо - работает. Ненадёжно, криво, сложно и долго; ну и хрен с ним. Разве это повод учится пользоваться отвёрткой?
я просто завинтил крестовой шуруп плоской отвёрткой... может не так удобно, как крестовой, но шуруп в стене...
т.е. в нашем случае нужно grep и sed записать одним скриптом, причём так, что-бы в этом скрипте было как можно меньше структурных единиц, например команд s, ну а потом нам придётся решить
кстати... ну и как же это всё записать в один sed-скрипт?
по вашему, правильный ответ в ЕДИНСТВЕННОМ случае это значит "работает"?
ИМХО можно условно считать программу рабочей, пока не будет найден контрпример. на многоядерных системах оно тоже работает правильно... ИМХО должно и на остальных SMP работать...
Программа может быть "рабочей и удобной", и "нерабочей и неудобной".
только вот "удобная" это точно такой же НЁХ
тогда хоть подскажите тогда, где они?
если б нашёл - то я бы их процитировал хотя-бы. :(
кстати... ну и как же это всё записать в один sed-скрипт?
что, всё? с sort -u таки попроще. И уже можно сделать, если прочитать прошлые сообщения. Можно и без sort -u, это сложнее, и интереснее.
ИМХО можно условно считать программу рабочей, пока не будет найден контрпример
я не физик. да и физики тоже так не считают.
только вот "удобная" это точно такой же НЁХ
ага. хорошо, пусть будет
очевидный интерфейс
что, всё? с sort -u таки попроще. И уже можно сделать, если прочитать прошлые сообщения. Можно и без sort -u, это сложнее, и интереснее.
вы покажите хоть как без grep'а сделать... болей-менее простым способом, чтобы это не уменьшило читаемость, которая, приходится признать, и так не на высоте.
я не физик. да и физики тоже так не считают.
я их как раз думал упомянуть их тут аль нет =)
очевидный интерфейс
да... забыл дописать, что под интерфейсом тут понимаю не пользовательский, а программный, ну чтоб точки над "и" расставить...
вы покажите хоть как без grep'а сделать... болей-менее простым способом
sed '/условие/{скрипт;}'
чтобы это не уменьшило читаемость, которая, приходится признать, и так не на высоте.
Оно и читается легче, теми кто с sed знаком (кто не знаком всё равно не распарсит).
да... забыл дописать, что под интерфейсом тут понимаю не пользовательский, а программный, ну чтоб точки над "и" расставить...
ага.
ну если рискнуть, и заглянуть внутрь маздайного приложения, мы и увидим знакомые костыли tongue
что, кстати, сильно облегчает их взлом.
потому как в логически разрозненные кусочки намного проще вставить свою букашку. Вы это называете "хорошим программным интерфейсом", я это называю глючащим и тормозным РЕШЕТОМ.
sed '/условие/{скрипт;}'
дурачком прикидываетесь или и правда не понимаете? итак, почему это тут не работает, если тупо записать:
на входе:
text
processor : 0
vendor_id : GenuineIntel
cpu family : 6
...как скрипт работает:
text
/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"
} # и так три раза.
если тупо записать:
ну а если подумать?
Понятное дело, что у вас прочитается не та строчка. И разве не ясно, как это исправить?
Можно конечно начать разбор с "processor", а потом ждать "physical id", ну и потом ждать "core id", загружая в цикле строчки... Но есть способ лучше - использовать команду H вместо N, и произвести парсинг после получения "core id". Разве это не очевидно? Не? Ну тогда зачем вы вообще используете sed? Сложно выучить такой примитивный ЯП на половину... Проще него разве что BrainFuck, но он и придуман как "простой", а sed придумана для обработки текстов. И свою задачу вополняет хорошо, не нуждаясь в дополнительных костылях (grep в данном случае - костыль, ибо никто не просил нас фильтровать строчки, это просто первое, что пришло вам в голову. Однако первое - почти всегда худшее.)
Fat-Zer, чё я взъелся-то так? А всё потому, что вы _одноразовый_ не протестированный и недоделанный однострок предложили в качестве общего решения. Типа - тупо скопипастил, и получил результат. Подход правильный, вот только этот однострок должен быть далеко не одноразовым, и написанным человеком, который прекрасно понимает значение входных данных, и используемый ЯП. Ну а значение входных данных мы, к сожалению не понимаем :(
мда... чего-то меня переклинело, что с H намного сложнее будет - хотел сначала читать N'м, а потом парсить и добавлять в холд... в общем путь какая-то...
пара вариантов:
text
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'
ну или итоговые варианты:
text
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ну или итоговые варианты:
text
sed -rne '/core id|physical id/{s/.*: (.*)/\1 /;H};/^$/{x;s/\n//g;p}' /proc/cpuinfo | wc -lну не так уж и сложно в итоге получилось ;)
Войдите или зарегистрируйтесь, чтобы ответить.
