Исходный код линукс сколько строк
Обновлено: 01.07.2024
Анализ файлов - неотъемлемая часть работы с ними. Иногда возникает необходимость подсчитать количество строк или слов в тексте. С этой задачей эффективно справляется команда wc Linux.
Утилита устанавливается по умолчанию практически во всех дистрибутивах GNU/Linux. В этой статье рассмотрим её функции и применение на практике.
Синтаксис команды wc
Для запуска утилиты откройте терминал и введите:
Терминал будет ожидать ввода данных. После нажатия комбинации клавиш Ctrl + D командный интерпретатор завершит работу программы и выведет три числа, обозначающих количество строк, слов и байт введённой информации.
Утилита может обрабатывать файлы. Стандартная инструкция выглядит так:
- wc — имя утилиты;
- file — название обрабатываемого файла.
Программа также может принимать параметры для анализа отдельных значений. Наиболее используемые из них приведены в таблице ниже:
| Параметр | Длинный вариант | Значение |
| -c | --bytes | Отобразить размер объекта в байтах |
| -m | --count | Показать количесто символов в объекте |
| -l | --lines | Вывести количество строк в объекте |
| -w | --words | Отобразить количество слов в объекте |
Под объектом следует понимать файл или данные, полученные на стандартный поток ввода.
Команда может обработать несколько файлов, если указать их через пробел или выбрать по шаблону.
Применение команды wc
Обработка стандартного потока ввода с завершением через Ctrl + D:
Согласно анализу, было введено 4 строки, содержащих 5 слов, объёмом в 35 байт.
Перенаправление потока вывода на вход wc:
Обработка всех файлов с расширением .sh в текущем каталоге:
В конце выводится итоговая информация, суммирующая значения для каждого столбца.
Выведем только количество символов и строк двух файлов:
Обратите внимание: порядок указания параметров не влияет на итоговый вид информации. Программа всегда выводит данные в виде СТРОК — СЛОВ — БАЙТ (СИМВОЛОВ) [— ФАЙЛ]. Если какой-то параметр будет отсутствовать, его столбец просто проигнорируется, не задевая остальные. Количество символов будет стоять первым, если в команде содержался и вывод байт.
Вывод
Команда wc Linux является эффективным инструментом при анализе файлов в GNU/Linux. Она может обрабатывать как стандартный поток ввода, так и несколько файлов одновременно. Для извлечения конкретных данных используются параметры командной строки.
Довольно частенько нужно подсчитать количество файлов при выводе в консоли BASH. Хорошо если файлов 10 единиц. Как быть если их сотни и у каждого файла сложное имя. Тут идеально подойдёт команда wc. Её наилучше использовать вместе с фильтром. Например с командой grep команда wc хорошо сочетается. Возможно подсчитать количество слов в документе.
С помощью команды wc вы можете подсчитать количество строк, слов и символов в указанном файле. Если указано более одного файла в инструктивной строке, то программа wc осуществляет подсчет строк, слов и символов в каждом файле и потом выдает общее число. Вы можете с помощью ключей указать либо подсчет лишь строк, или только слов, или символов. Синтаксис команды:
Подсчет строк, слов и знаков с помощью wc
Система отвечает строкой в следующем формате: l w c файл
где l - число строчек в файле;
w - число слов в файле;
c - число символов в файле.
Чтобы подсчитать количество строк, слов и символов в нескольких файлах, используйте следующий формат:
Система говорит следующим образом:
l w c файл1
l w c файл2
l w c total
Число строк, слов и символов для файл1 и файл2 отражается на отдельных строках. На последней строке отображается общее число строк, слов и знаков в двух файлах.
Подсчет данных в документе
wc text.txt
вывод: 40 149 947 text.txt
В первоначальной колонке содержится количество строк, во второй кол-во слов, в третьей кол-во знаков
Подсчёт данных в выводе командной строки Linux
ls -al | grep '.txt' | wc -l
ls -al | grep '.txt' | wc -w
Подсчет количества .txt-файлов в текущем каталоге с помощью wc:
Поиск количества файлов в директории Linux
ls | grep "name" | sort | uniq | wc -l
Подсчет уникальных строк и дубликатов в текстовом файле Linux
Буквально сегодня на работе столкнулся с довольно простой задачей, состоящей из двух подзадач: 1) нужно было подсчитать в текстовом файле количество уникальных строк 2) подсчитать в уже другом файле количество строчек, которые дублируются.
С этими задачами я справился и после этого подумал — по какой причине бы не написать небольшой пост, вдруг кому-нибудь пригодится. Подсчитаем в нём количество уникальных строчек с помощью следующей команды:
$ sort data.txt | uniq -u | wc -l
Всё достаточно просто. Утилита uniq с функцией -u выводит на экран уникальные строки (u—unique, видимо так) и с помощью | результат перенаправляется в утилиту wc , какая просто считает количество строк, т.к. исполняется с опцией -l. В самом начале нам необходимо просортировать входной поток данных (текстовый файл), иначе утилита uniq не сможет правильно подсчитать уникальные строки. Выполняется сортировка с помощью sort и результат, используя |, перенаправляется в uniq. После исполнения такой команды для файла data.txt на экран будет выведено число 5.
Для этого чтобы решить вторую подзадачу, сделаем всё тоже самое, только uniq станет выполнен с опцией -d (видимо d—duplicate):
$ sort data.txt | uniq -d | wc -l
В результате на экран выведено количество 2. Обе подзадачи решены достаточно простым способом. Записал небольшую демонстрацию кому забавно.
Подсчитать количество строк в файле Linux
Нет ничего проще, чем подсчитать количество строчек в файле.
cat filename.txt | wc -l
Подсчитать общее количество строк в файлах (именованная область данных на носителе информации) по шаблону. Если же вам необходимо подсчитать количество строк нескольких файлов, можете использовать шаблон, например:
cloc: подсчитать количество строк исходного кода на разных языках программирования | Linux China
Для полезных ссылок на оригинальный текст, пожалуйста, посетите Оригинальная ссылка "Получайте интерактивные ссылки, полноразмерные оригиналы и соответствующие статьи.
Как разработчику, вам может понадобиться время от времени делиться своими текущими результатами работы и разработки кода с вашими руководителями или коллегами, или ваш лидер хочет провести всесторонний анализ кода. В настоящее время вам нужно использовать некоторые инструменты статистики кода, я знаю, что один из них Ohcount [1] , Сегодня я наткнулся на другую программу, cloc , С помощью cloc вы можете легко посчитать количество строк исходного кода на нескольких языках. Он также может рассчитывать количество пустых строк, строк кода и строк реального кода и выводить результаты через аккуратную таблицу. Cloc - это кроссплатформенная программа с открытым исходным кодом, которая использует Perl Развитие.
Cloc имеет много преимуществ:
Простота установки и использования, никаких дополнительных зависимостей не требуется. Портативный. Поддерживает экспорт в несколько форматов результатов, включая: простой текст, SQL, JSON, XML, YAML, CSV. Может подсчитывать количество коммитов в git. По количеству строк кода в папке можно рассчитать сжатый файл, например: tar, zip, Java.ear и т. Д. Открытый исходный код, кросс-платформенный
Установочный пакет cloc находится в библиотеке программного обеспечения по умолчанию в большинстве Unix-подобных операционных систем, поэтому его нужно установить только с помощью менеджера пакетов по умолчанию.
Я понимаю поддержку архитектуры процессора, безопасность и виртуализацию, но не могу представить, что это более 600 000 строк или около того.
Какие исторические и текущие причины драйверы включены в базу кода ядра?
Включают ли эти 15 с лишним миллионов строк каждый драйвер для каждого компонента оборудования? Если это так, то возникает вопрос, почему драйверы встроены в ядро, а не в отдельные пакеты, которые автоматически определяются и устанавливаются из идентификаторов оборудования?
Является ли размер базы кода проблемой для устройств с ограниченным хранилищем или памятью?
Кажется, это увеличило бы размер ядра для устройств ARM с ограниченным пространством, если бы все это было встроено. Много ли строк отбраковано препроцессором? Назовите меня сумасшедшим, но я не могу представить себе машину, требующую столько логики для запуска, как я понимаю, роли ядра.
Есть ли доказательства того, что размер будет проблемой через 50 с лишним лет из-за его, казалось бы, постоянно растущей природы?
Включение драйверов означает, что оно будет расти по мере изготовления оборудования.
РЕДАКТИРОВАТЬ : Для тех, кто думает, что это природа ядер, после некоторых исследований я понял, что это не всегда. Ядро не обязательно должно быть таким большим, так как микроядро Карнеги-Меллона было приведено в качестве примера «обычно под 10000 строк кода».
Да, я написал код для компилятора, лексического анализатора и генератора байтового кода для языка, и он был полностью завершен плюс рекурсия, и он не занимал 10 000 строк. Вы должны скачать и настроить, make menuconfig чтобы увидеть, сколько кода можно включить / отключить до сборки. @JonathanLeaders: Я закончил тестирование полных компиляторов для языков, подобных LISP, менее чем в 100 строк, с тестовыми программами, отображающими Мандельброта. Всегда зависит.Драйверы поддерживаются в ядре, поэтому, когда изменение ядра требует глобального поиска и замены (или поиска и изменения вручную) для всех пользователей функции, это делает человек, который вносит изменения. Обновление вашего драйвера людьми, вносящими изменения в API, является очень хорошим преимуществом, вместо того, чтобы делать это самостоятельно, когда он не компилируется в более новом ядре.
Альтернатива (то, что происходит с драйверами, поддерживаемыми вне дерева), заключается в том, что патч должен быть повторно синхронизирован его сопровождающими, чтобы не отставать от любых изменений.
Быстрый поиск вызвал дискуссию по поводу разработки драйверов внутри дерева и вне дерева .
Широкое использование Linux во встраиваемых системах привело к лучшей поддержке отказа от вещей, чем Linux имел годы назад, когда дерево исходных текстов ядра было меньше. Супер-минимальное ядро 4.0, вероятно, меньше супер-минимального ядра 2.4.0.
Теперь ЭТО имеет смысл для меня, почему логично собрать весь код вместе, это экономит человеческие часы за счет ресурсов компьютера и чрезмерных зависимостей. @JonathanLeaders: да, это позволяет избежать гниения для водителей с не очень активным обслуживанием. Также возможно полезно иметь весь код драйвера при рассмотрении изменений ядра. Поиск во всех вызывающих программах какого-либо внутреннего API может привести к тому, что драйвер будет использовать его так, как вы и не думали, что может повлиять на изменение, о котором вы думали. @JonathanLeaders приходят на xd, как будто эти дополнительные строки занимают намного больше места, в современных измерениях установки его на ПК. @Junaga: вы понимаете, что Linux очень переносим и масштабируем, верно? Потеря 1 МБ постоянно используемой памяти ядра во встроенной системе 32 МБ является большой проблемой. Размер исходного кода не важен, но размер скомпилированного двоичного файла все еще важен. Память ядра не выгружается, поэтому даже с пространством подкачки вы не сможете ее вернуть. @ Рольф: Это большой, но это не спагетти. В настоящее время он достаточно хорошо спроектирован без двусторонних зависимостей между основным кодом и драйверами. Драйверы могут быть оставлены без нарушения ядра ядра. Когда внутренняя функция или API подвергается рефакторингу, поэтому драйверы должны использовать его по-другому, драйверы могут нуждаться в замене, но это нормально для рефакторинга.Согласно Cloc, работающему против 3.13, Linux содержит около 12 миллионов строк кода.
- 7 миллионов LOC в драйверах /
- 2 миллиона LOC в арке /
- всего 139 тыс. LOC в ядре /
lsmod | wc на моем ноутбуке Debian показано 158 модулей, загруженных во время выполнения, поэтому динамическая загрузка модулей - это популярный способ поддержки аппаратного обеспечения.
Надежная система конфигурации (например make menuconfig ) используется для выбора кода для компиляции (и, более того, какой код не компилировать). Встраиваемые системы определяют свои собственные .config файлы только с помощью аппаратной поддержки, которая им нужна (включая поддержку аппаратного обеспечения, встроенного в ядро или в виде загружаемых модулей).
подсчета модулей недостаточно, многое может быть встроено в конфигурацию Я думаю, что из этого мы можем сделать вывод, что ядро Linux огромно, потому что оно поддерживает всевозможные конфигурации устройств, а не потому, что оно чрезвычайно сложно. Мы видим здесь, что очень мало из 15-метровых линий фактически используется. Хотя, как и почти все, это может быть слишком сложно, по крайней мере, мы можем спать по ночам, зная, что это разумно @JonathanLeaders: Да, а также модули для странных устройств, есть модули для скрытых файловых систем, сетевых протоколов и т. Д. @JonathanLeader Я помню, когда Linux запускался - даже заставить установщик работать (если у него даже был установщик!) Было огромной болью - все еще есть некоторые дистрибутивы, где вам нужно выбрать драйвер мыши вручную. Создание таких вещей, как создание сетей или, не дай бог, X-Window, работа, было обрядом обряда. При первой установке Red Hat мне пришлось написать собственный графический драйвер, потому что было доступно только три (!) Драйвера. Работа с базовыми компонентами по умолчанию является признаком зрелости, и, очевидно, вы можете позволить себе гораздо больше настроек встроенной системы, в которой всего несколько комбинаций HW. @JonathanLeaders Как я думаю, вы поняли, что LOC в источнике более или менее не имеет значения. Если вы хотите узнать, сколько памяти использует ядро, есть гораздо более прямые способы .Для любого любопытного, вот разбивка строки счета для зеркала GitHub:
drivers вносит большой вклад в количество строк.
Это интересно. Еще более интересны потенциально слабые места в коде, где программисты были недовольны: grep -Pir "\x66\x75\x63\x6b" /usr/src/linux/ | wc -l @jimmij '\ x73 \ x68 \ x69 \ x74' может быть более распространенным явлением в соответствии с этим новаторским (если немного датированным) исследованием . Случайный факт: документация находится в папке, которая ближе к 600 000 LOC, оцененных ОП. @ drewbenn Я понял это больше как "документация не пуста?"Пока что ответы кажутся «да, кода много», и никто не решает вопрос с наиболее логичным ответом: 15M +? И ЧТО? Какое отношение имеет 15 миллионов строк исходного кода к цене рыбы? Что делает это таким невообразимым?
Linux явно многое делает. Гораздо больше, чем что-либо еще . Но некоторые ваши очки показывают, что вы не уважаете то, что происходит, когда он построен и используется.
Не все скомпилировано. Система сборки Kernel позволяет быстро определять конфигурации, которые выбирают наборы исходного кода. Некоторые экспериментальные, некоторые старые, некоторые просто не нужны для каждой системы. Посмотрите на /boot/config-$(uname -r) (на Ubuntu), make menuconfig и вы увидите, сколько исключено.
И это настольный дистрибутив с переменной целью. Конфигурация для встроенной системы будет включать только то, что ей нужно.
Не все встроено. В моей конфигурации большинство функций ядра построены в виде модулей:
Чтобы было ясно, они все могли быть встроены . Так же, как они могли быть распечатаны и превращены в гигантский бумажный бутерброд. Это просто не имело бы смысла, если бы вы не выполняли пользовательскую сборку для отдельной аппаратной работы (в этом случае вы бы уже сократили количество этих элементов).
Модули загружаются динамически. Даже когда в системе есть тысячи доступных ей модулей, система позволит вам загружать именно то, что вам нужно. Сравните результаты:
Почти ничего не загружается.
Микроядра не одно и то же. Всего 10 секунд просмотра ведущего изображения на странице Википедии, на которую вы ссылаетесь , покажут, что они созданы совершенно по-другому.
Драйверы Linux являются внутренними (в основном динамически загружаемыми модулями), а не пользовательским пространством, и файловые системы также являются внутренними. Почему это хуже, чем использование внешних драйверов? Почему микро лучше для вычислений общего назначения?
Комментарии снова подчеркивают, что вы не получаете это. Если вы хотите развернуть Linux на дискретном оборудовании (например, в аэрокосмическом пространстве, TiVo, планшете и т. Д.), Вы конфигурируете его для сборки только необходимых вам драйверов . Вы можете сделать то же самое на вашем рабочем столе с make localmodconfig . В итоге вы получите крошечную сборку ядра с нулевой гибкостью.
Для таких дистрибутивов, как Ubuntu, допустим один пакет ядра размером 40 МБ. Нет, откажитесь от этого, на самом деле, это предпочтительнее сценария массового архивирования и загрузки, в котором хранится более 4000 плавающих модулей в виде пакетов. Он использует меньше дискового пространства для них, легче упаковывать во время компиляции, легче хранить и лучше для своих пользователей (у которых есть система, которая просто работает).
Будущее тоже не проблема. Скорость процессора, плотность диска / цены и пропускная способность кажутся намного быстрее, чем рост ядра. Пакет Kernel 200 МБ за 10 лет не станет концом для мира.
Это также не улица с односторонним движением. Код выгоняется, если он не поддерживается.
Читайте также: