Pull to refresh

Comments 204

chatgpt, напиши статью про 5 полезных команд в linux.

Да, это база... но я вот живу в Винде, и навскидку не назову аналоги этих команд. Кроме разве что cd \ в корень или стрелочек для пролистывания истории. Когда мне надо сделать что-то выходящее за рамки файл-менеджера, я пишу bat-ник, а затем в редакторе размножаю и правлю "тупые" команды. Все лучше, чем набирать их вручную.. однако я бы не отказался от подобной "шпаргалки для чайников". Когда комстрока нужна раз в два месяца, курить справку впрок не слишком-то продуктивно (все равно все забудешь). Если же она вдруг срочно понадобилась, проще обычно использовать привычные инструменты, чем гуглить что-то более оптимальное. И вот в этот момент такая заметка-ликбез в закладках вполне может оказаться не лишней. Например, несмотря на массу материалов по регуляркам (которых я тоже не знаю, т.к. они мне нужны раз в полгода), я обращаюсь за справкой не к поисковым системам, а к прочитанным ранее хабростатьям.

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

В винде есть прекрасный PowerShell.

UFO landed and left these words here

Нет, всего-то Copy-Item. И, к слову, cp там тоже, внезапно, работает.

Нет, там есть все привычные короткие алиасы. Не понимаю ваш скептецизм. PowerShell на голову выше любого шелла из мира Линукса (а я их хорошо знаю), в PS через пайп идут объекты, а не строки, что в корне меняет правила игры.

Я их тоже отлично знаю (не все, их реально много). Согласен, PowerShell крут, но у него под капотом считайте весь дотнет.

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

PowerShell это продукт другого класса, это практически отдельный язык программирования, естественно он будет на голову выше линуксовых шеллов (кстати говоря, сам PS под линуксом работает не хуже, чем под виндовс, у меня на нем кросс-платформенные пайплайны для кросс-платформенного кода на сишарпе). Там много удобств, мне тоже нравится, те же объекты в пайпах (напоминает мне стримы в джаве, но подозреваю, что там может быть просто Linq под капотом, исходники не читал), и насколько просто работать с JSON и писать REST API клиентов, но тащить все это ради десятистрочника я бы не стал. Если у меня контейнер со стабом SMTP сервера на баше (со всеми зависимостями) укладывается в 4.5-5 мегабайт, один дистрибутивный пакет PS для Дебиана больше 68 мегабайт, после установки еще больше.

Мощнее инструмент - больше ресурсов требуется для его использования. Практически все линуксовые шеллы предполагали малое использование ресурсов с самого начала, что места на диске, что зависимостей для работы, отсюда и ограниченные возможности. Я не думаю, что сравнивать PS с линуксовыми командными оболочками будет честно, у них изначально другая задача, более простая, они сильны настолько, насколько сильны программы, которые вы из них вызываете.

А можно ли в действительности почувствовать разницу между ps и *sh с точки зрения производительности? Я честно не могу придумать какой-то сценарий. Сам использую windows и wsl как шелл, просто потому что привык, при этом ps в его последних вариациях - это прямо чудо

Могу из своего опыта навскидку сказать один сценарий, где может быть какая-то заметная разница - билд и деплой докер-контейнера с чем-то на *sh и с чем-то на PS. Контейнер с дотнетом и PS будет дольше собираться (если кэша слоёв нет) и дольше качаться для выполнения, потому что он просто больше по размеру. В остальных случаях не думаю, что будет настолько значительная разница в работе, чтобы это прям в глаза бросалось, накладные расходы в других местах. Билд, запуск тестов, работа вызываемых программ.

Чтобы протестировать производительность самих скриптов изолированно, надо много думать, чтобы выполнять одну и ту же задачу и там, и там. И тут может быть сложно, учитывая, что большинство более или менее сложных задач при использовании линуксовых шеллов выполняют другие программы (и именно так это и задумывалось), а PS может многое выполнять сам, потому что у него есть доступ к библиотекам дотнета. Всё может скатиться к сравнению библиотек с библиотеками, что никак не поможет сравнить именно скорость выполнения скриптов. Производительность скриптера для обоих вариантов при написании скриптов - субъективный фактор, у кого-то займет много времени, у кого-то мало, тут скорее вопрос опыта.

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

думать вредно, мысли пачкают мозги.
задача 1: пустой цикл миллион раз.
задача 2: A=A+1 миллион раз.
эксперты опеннета помнят, эксперты швабра не знают.

Это не задачи, это операции. Ну, выясните вы, что пустой цикл в, допустим, повершелле или арифметическое действие на 5 наносекунд быстрее, как вам это поможет? Вы будете это экстраполировать на всё остальное? Это какие-то тупые тесты, учитывая, насколько они нерелевантны практике реального использования.

Производительность powershell и shell сложно грамотно посчитать, поскольку shell сам по себе - весьма легковесная штука, которая запустится на минимальном компе где линукс едва запускается.
Но по своей сути, в shell нет внутренних либ и крайне ограниченный набор внутренних команд и конструкций. Причем значительная часть из них напрямую связана с устройством и архитектурой ОС и консоли (те же перенаправления, которые являются важнейшим аспектом работы в shell - они то часть терминала)
Поэтому в среднем, в shell идет много запусков внешних команд, на что уходит много ресурсов. Можно искать оптимизации, и выполнять часть функций прямо в других командах (awk/sed/bc имеют весьма развитый программируемый язык) и др.

В PS все делается внутренними библиотеками и мощью объектов .net, но командлеты вроде бы как уже в памяти, поэтому после того как powershell уже запустился, внутри операции наверное могут быть быстрее.

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

В целом да - сравнивать чисто оболочки - смысла мало, большие ограничения всегда будет давать или железо, или ОС, или реализации конкретных библиотек под конкретные платформы. Я сейчас перечитал сообщение выше - видимо не правильно понял посыл изначально, показалось как будто там утверждается, что PS хуже, потому-что тяжелее.

Для PS, кстати, есть что-то типа IDE (PS ISE) - вдруг кто-то наткнется на этот комментарий и возымеет пользу.

UFO landed and left these words here

Он написал хорошо, но ваше добавление лишнее. PS вполне хорош как шелл. Почему вы решили, что он неудобен? Используйте сокращённый синтаксис, там его много.

UFO landed and left these words here

В первой же версии ко всем нужным командам были алиасы и даже к целым операциям, вроде цикла. Вы путаете неудобное и непривычное.

UFO landed and left these words here

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

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

UFO landed and left these words here

Мои тезисы соответствуют действительности. Я хорошо знаю bash, много и часто на нём пишу. При этом в своё время я для интереса выучил PS1 (первую версию) и написал на нём несколько программ.

Так что я ел те и те устрицы, знаю о чём говорю.

Не понимаю ваш скептецизм. PowerShell на голову выше любого шелла из мира Линукса (а я их хорошо знаю)

судя по всему как раз нехорошо. Для меня повершелл это вообще не шелл, а еще один скриптовый язык программирования, как VB / JS/ lua.
Но никак не человеческий универсальный шелл, который отлично работает и как скрипт и как интерактивная консоль

Попробуйте написать однострочник по обработке скриптов на VB/JS/Lua, а потом — на PS и почувствуете, что это вполне себе шелл.

в PS через пайп идут объекты, а не строки, что в корне меняет правила игры.

И как связать через пайп различные программы, типа git, ffmpeg, keygen, openssl и др?
Внезапно оказывается что приходится снова разбирать строчки?

Да, PS так умеет, один раз разберёте, преобразуете в объект и работаете дальше с объектом.

преобразовать в объект что? зачем? Я понимаю, что все можно сделать, но это неудобно и переусложнено, по сравнению с линукс шелл, который и был задуман именно как шелл для работы с ОС и другими программами.
А повершелл - с объектами.

Разница между все есть файл и все есть объект в том, что в шелле объектное программирование - оверхед.

У нас что контекст потерялся? Вроде нет.

Разобрать строку, преобразовать в объект и дальше в пайпе работать с объектом.

> Разница между все есть файл и все есть объект в том, что в шелле объектное программирование — оверхед.

Вы путаете ООП и объект в пайпе. Перечитайте наш с вами диалог.

Я не путаю.

Практически любой bash или shell скрипт, который делает простые задачи, любой среднезнакомый с программированием сходу может прочитать и поправить, не зная shell

А с powershell так не выйдет, его надо специально учить. Простейшие конструкции в powershell выглядят переусложненно.

Именно этим мне и не нравится синтаксис ps - он изначально задуман неудобным для рядового пользователя.

В то время как bash это вполне комфортная оболочка и для новичков и для профи.

Если бы любой bash-скрипт (на чисто шелле я не пишу, так что знаком с ним меньше) мог бы поправить любой человек, не было бы справочников, вида «Pitfalls in bash» и иже с ними. Так буквально на ровном месте можно запутаться — как вывести «!», как вложить одни кавычки в другие, почему «… && … || …» не эквивалент «… ? … : …», почему «.… | read var; echo $var» не присваивает ничего в мою переменную и так далее, чего там только нет.

Баш — поистине эзотерический язык программирования. Сравнивать с ним простой и понятный PS1 просто странно.

Баш — поистине эзотерический язык программирования.

Это шелл (оболочка), который еще и умеет исполнять скрипты. Как ЯП он не очень.

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

Уже готовый скрипт поправить - можно просто на интуиции.
в PS надо конкретно гуглить каждую команду, каждое преобразование, разбираться с типами данных. Интуиция не работает, надо учить и читать. Причем зачастую ты даже не предполагаешь как может называться та или иная команда, потому что не copy и не cp, как ранее всем известным оболочкам, а Copy-Item, обязательно с дефисом и заглавными. Откуда это -Item, зачем??
И такое в Каждой-Конструкции

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

Если бы любой человек мог поправить исходники ядра на си, не было бы справочников по UB. Хотя язык проще некуда (пока не начнете работать с динамической памятью, сетевыми сокетами, прерываниями, и так далее). И, честно говоря, хз, что бы я делал в повершелле без MSDN, я вроде человек неглупый, но он простой и понятный только когда ты его немного изучил и понял концепции, которые в него заложены при создании. Порог входа не нулевой и в ПШ, и в баше.

Баш — поистине эзотерический язык программирования. Сравнивать с ним простой и понятный PS1 просто странно.

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

Статей пишут много потому, что никто не читает маны. Там расписано всё, многое с примерами и объяснениями. Возможно, он просто слишком большой для многих, и это пугает. Но там есть поиск. Опять же, есть внутренняя команда help, которая печатает полный список команд с кратким описанием, который не факт, что длиннее, чем в CMD (он же command.com из доса), и вы крайне редко будете использовать половину из них.

Несколько лет назад я преподавал линейку собственных курсов, которые логически проводили студентов к профессинальному баш-скриптингу. Это написание простых утилит для командной строки в Си, потом курс администрирования линукса по программе LPIC-1, и потом курс баш-скриптинга. Результаты были хорошие, потому что в итоге это всё складывается в одну картинку.

Хотя бы этот пример взять - переменная = (условие)?если-верно:если-неверно. Тут возвращается значение в переменную, потому что код оперирует значениями. "... && ... || ..." работает с кодами возврата и контролирует последующее выполнение (execution flow). Если вы развернёте оба варианта в if с переменными, станет сразу понятнее.

Смотрите:

int a = (b == 1) ? 0 : 1;
//--------------   ^------ значение
int a;
if (b == 1) {
  a = 0;
} else {
  a = 1;
}
# Пример, который сработает во многих шеллах
[ $b -eq 1 ] && a=0 || a=1
# ------------  ^-- операция целиком
if [ $b -eq 1 ]
then
  a=0
else
  a=1
fi
# --- второй пример
[ $b -eq 1 ]
result=$?
# переменная result содержит результат выполнения,
# в данном случае то, что при использовании
# оболочки, отличной от bash, будет скорее всего
# "return 0;" в методе int main() программы
# test/[

Ну и, если помнить, что точка с запятой отделяет команду или цепочку команд, то получается логично. Правильнее, естественно, будет как-то так - "... | (read; echo $REPLY)".

Просто другая парадигма. К ней не надо подходить как к языкам программирования общего назначения c сишным синтаксисом.

@3vi1_0n3

Тоже читаю вводные курсы по баш собственного производства =).
Все так. Многие считают баш/шелл настолько примитивным, что вообще не читают документацию, сразу пытаются писать, поэтому и идут простейшие ошибки. Никак не потому, что шелл скриптинг сложный или эзотерический.

Что же касается башизмов, их реально очень немного по сравнению с POSIX shell. Я навскидку могу вспомнить только про [[ ]] и более развитый variable expansion, остальные вещи больше относятся к интерактивному использованию (всякие внутренние переменные и опции), а не скриптингую.

shell скрипты связаны с операционной системой глубже, чем сторонние языки, тот же exit code 0 / не ноль. вместо true / false. Прямая работа с stdout/stderr/stdin. И это правильно и естественно.

Вот первый же пример
Get-Help -CommandType Cmdlet

почему в первом случае camelcase через дефис, во втором camelcase без дефиса, в третьем вообще сокращенно и не camelcase, официальная документация?
Хорошо что можно регистр опускать в некоторых случаях, но это просто пример того, что очень неудобно, потому что все это надо запоминать наизусть.
Просто так справку посмотреть даже неудобно.
Посмотреть версию какой-то команды можно только раком.
Написать собственную простую утилиту/скрипт для обработки результатов сложно, потому что или надо сразу свою утилиту/скрипт писать непростой, а который умеет работать с объектами, или предварительно данные, которые хочешь в него послать преобразовывать в текст.

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

Именно так. Башизмов совсем немного, но в основном они довольно круто работают. У меня есть отличный пример

#!/bin/bash

# This script converts IP address and netmask from a network interface (e.g. 192.168.1.123 255.255.255.0)
# to a network address (e.g. 192.168.1.0/24) in pure bash without external programs.

if [ -z $1 ] || [ -z $2 ]; then echo -e "Usage: $0 <IP> <long-mask>\nExample: $0 192.168.1.14 255.255.255.0"; exit 1; fi

BARRAY=({0..1}{0..1}{0..1}{0..1}{0..1}{0..1}{0..1}{0..1})
BINARY_IP_ADDRESS=$(for octet in ${1//./ }; do echo -n ${BARRAY[octet]}; done)
BINARY_NETMASK=$(for octet in ${2//./ }; do echo -n ${BARRAY[octet]}; done)
BITS=${BINARY_NETMASK%%0*}
BITS_COUNT=${#BITS}

NETWORK_ADDRESS=${BINARY_IP_ADDRESS:0:BITS_COUNT}${BINARY_NETMASK:BITS_COUNT}
NEW_ADDRESS="${NETWORK_ADDRESS:0:8} ${NETWORK_ADDRESS:8:8} ${NETWORK_ADDRESS:16:8} ${NETWORK_ADDRESS:24:8}"
DECIMAL_ADDRESS=`echo $(for octet in $NEW_ADDRESS; do echo $((2#$octet)); done)`
DECIMAL_ADDRESS=${DECIMAL_ADDRESS// /.}

echo $DECIMAL_ADDRESS/$BITS_COUNT

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

Прямая работа с stdout/stderr/stdin. И это правильно и естественно

Не холивара ради, а любопытства для - тоже считаю, прямую работу с потоками in/out/err удобной, но тут недавно пришлось конкретно так сломать голову (еще и безрезультатно), чтобы просто (а именно читаемо, понятно и без создания временных файлов) сделать вывод stdout и stderr от одной команды в разные переменные. В pwsh это делается в одну строку:

$err = $( $out = & $command ) 2>&1

но при этом аналогичные "трюки" на bash:

err=$($out=$($command) 2>&1)

не работают, хотя казалось бы

в баш для stderr нет синтаксиса для перенаправления в переменную. Можно вывести в два разных файла и потом их прочитать. Или вывести все как одну строку, и потом распарсить

out=$(mycommand 2>err.file)
err=$(cat err.file)


tmp=$(mycommand 2>&1)
read out err <<< "$tmp"

так вы, собственно, сейчас пишете ровно то же, что и комментаторы, с которыми вы дискутируете.
bash — хороший шелл, но плохой ЯП.
poswershell — хороший ЯП, но плохой шелл.

bash хороший шелл и хороший ЯП для универсальных скриптов автоматизации и интеграции

Разобрать строку, преобразовать в объект

Не преобразовывать - проще.

Это скорее минус чем плюс. Тащить монструозную систему объектов и командлетов ради типичных задач скриптов линукс это выглядит крайне неэффективно.

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

PowerShell на голову выше любого шелла из мира Линукса

nushell такой - ну да, ну да, пошел я нафиг

вы уже заткнули слив телеметрии из ps наглухо и прицельно ?

если да, то прошу поделиться методикой.
у меня без удаления дефолтного маршрта ничего не вышло, используемый NGFW это не распознает (просто неклассифицируемый https трафик), для old-gen fw слишком долго готовить данные и гонять стенды.

если нет, то вы не имеете права голоса в этом вопросе.

ps: поверщельщиков травить не бросим, один-четыре-восемь-восемь.

Разве "To opt-out of this telemetry, set the environment variable $env:POWERSHELL_TELEMETRY_OPTOUT to true, yes, or 1" не работает?

Или при установке

был issue на github - кто-то не смог отключить, ему советовали откровенное шаманство, ничего не помогло, issue закрыт не был.
точно помню что ссылка была на опеннете 2-3 года назад, сейчас найти не могу.

а все очень просто:

$ sudo apt install ack
$ git clone "https://github.com/PowerShell/PowerShell"
$ ack -i telemetr PowerShell/

-- сколько вариантов ? сколько времени на аудит всех участков кода ? а это точно ВСЕ участки кода ?

Смотрите в сторону powershell. Много ресурсов с хитростями

кроме "прекрасного" powershell из комментариев выше, есть например nushell.

Очень неплох, хотя до fish по дружелюбности не дотягивает

Да, это база... но я вот живу в Винде

Лайвхак:
ставишь git for windows, и получаешь рабочий git-bash и рабочие shell скрипты.
Или вообще запускаешь WSL и там скрипты еще и работают почти также по перформансу.

Заметки бездарные, потому что это блин ну вообще первичная основа.
Проблема винды в том, что изначально она не разрабатывала командную строку вообще, а bat/cmd был просто ужасно простой по сравнению со всеми другими консольными оболочками тех лет.
А потом резко перешла на обратно несовместимый монструозный powershell.
В результате нет истории наработок за 30-40-50 лет, как в shell

Лучшая ком.строка в винде - это FAR :)

Так и в Linux он так же неплох (давно уже пересел на него с mc).

использую для этого Excel

Например, мне надо создать 100 пользователей, можно наколдовать хитрый PowerShell с импортом из файла, а можно просто в Excel сделать конкатенацию столбца с пользователями со столбцом с командой создания + столбец паролей, shift+d, ctrl+c, ctrl+v

3 минуты и тупой скрипт из 100 строчек готов

Особенно нереальный лайфхак про history 5, у вас что, кнопку вверх забанили?

хех, не работали вы с некоторыми системами )

бывает, что и забанили кнопку, не работает она. Тогда еще tail/head приходится вспоминать

хех, не работали вы с некоторыми системами )

На всякий случай, если "кнопки вверх/вниз забанили":

~/.inputrc

$if Bash
	"\e[A":	history-search-backward		# Cursor Up
	"\e[B":	history-search-forward		# Cursor Down
$endif

Тоже так подумал) Даже я знаю history и даже в сочетании с grep, а не просто hisory 5

Очевидно, что Вы еще в текущей сессии не переходили в другой каталог

Да, действительно, спасибо. Правда, ценность этой команды для меня все равно сомнительна: если я перехожу в каталог не "прыжком", а последовательно, то "cd -" ведет себя аналогично "cd ..". Возможно, это полезно для переключения между двуме ветками.

Между ветками тоже работает

git branch

prod

git checkout test1

git checkout -

Есть еще замечательная кнопка TAB:

cd pro-TAB-jects/wo-TAB-rk_directory/-TAB-[images,scripts]-i-TAB-mages/....

И в одну команду переходите куда надо. А потом возвращаетесь в одну команду.

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

тогда проще cd ../../.. , гдавное с количеством точек и слешей не напутать))

Попробуйте dd if=/dev/zero of=/dev/sda bs=512 count=1 для полноты ощущений ;)

Вспомнился древний 128-байтовый троян времён DOS, зацикливавший таблицу разделов.

Зачем нам вирус? Мы сами как вирус!

Да ничего в принципе страшного, MBR сейчас не особо-то и нужен. Вот если бы bs=512M ...

gpt дублируется в конец диска, а вот полгига данных после неё это да

rm -Rf /

он же "универсальный патч"

Патч Бармина же был универсальным.

Забыли ключ --no-preserve-root или /× хотя бы )

уже нет, в некоторых шеллах уже переспрашивает

Тогда "/bin/rm" что бы не переспрашивал глупости. Кто на этом хосте хозяин, в конце-концов?

Просмотр логов с -f лучше запускать с флагом -n0, чтобы не показывало последних 10 строк

tail -fn0 error_file.log

а еще можно -f заменить на -F, тогда он не отвалится если файл был в процессе удален и заново создан

Если tail -f error_file.log | grep "ERROR" то grep c параметром --line-buffered для работы с потоком.

ещё можно дописать | ccze -A чтобы использовать разноцветное отображение

нужно вводить тег "нейросетевая статья"
и добавлять его в черный список

А как вы понимаете, что это нейросетнвая статья? (На всякий случай, с автором статьи я ни как не связан. Просто ML инженер)

  1. Уровень человека увидевшего линукс впервые.

  2. Есть два варианта. или вы каждый день создаете вложенные папки и тогда вы давно уже знаете как это делать ( написал свой скрипт, разобрались в баше, что вам угодно ) либо вам эта задача не нужна вовсе ( а один раз в год можно сделать руками допустим ).

  3. Заголовок уровня бульварных газет, контент уровня "я выучил команду man".

  4. Что общего у этих команд ( опций). Почему именно их объединили вместе? Почему бы не сказать "пиши скрипт на любую задачу и твоя жизнь не станет прежней"? или там "Устройся менеджером и тебе не придется заниматься вот этим всем"? или "переходи на винду и делай все мышкой"

Больше похоже на урок «Все основы Linux» из курса «”Что-то там компьютерное” для тестировщиков».

"я выучил команду man"

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

Как узнать, что этот комментарий написан человеком?

  • Типичные ошибки пятиклассника с тройкой по русскому (в частности, пунктуация)

  • Типографика ни в Красную Армию (пробелы вокруг скобок, новое предложение не с загалавной и т.п.)

серьёзно. Я пока ещё не видел вывода LLM, в котором был бы правдоподобно имитировано безграмотное написание. Если её просят, то она вносит ошибки рандомно, а не логично с точки зрения двоечника.)

а не логично с точки зрения двоечника

Прям себя в школе вспомнил, когда пытался учительнице объяснить свою интерпретацию правил, но был, конечно же, послан. )))

логично с точки зрения двоечника

А какова логика с точки зрения двоечника? Я специальных наблюдений не вёл, но на первый-второй взгляд, там какой-то псевдо-рандом.

Ну, например, считать, что запятая рядом с союзом «и» не нужна никогда.

То есть предположим человек бы рассказал "Смарите пацаны, есть короче zsh и там все в разы удобнее чем в баше", ну ок.

Или хотябы рассказал про Ctrl-R обратный поиск команды. Но рассказывать про history и обещать что это изменит чью-то жизнь это ну совсем слабо. Поэтому ну конечно может и нейросетевая а просто очень низкий уровень, который сейчас привычно ассоциировать с нейросетевыми сборниками бесполезных советов.

  1. группировка по шаблону, который будто бы прямо из промта (в чем проблема, что под капотом, пример, как это работает - и так пять раз)

  2. странное разделение приёмов: фигурные скобки пользователю объяснить надо единожды, а не давать два почти идентичных примера с перечислениями.

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

вы сами мне честно ответьте, ниужели у вас не возникло ощущения?

Каждый пункт разбит на подпункты, причём в них тот-же текст другими словами. Это прям характерно для ответов gpt которые без указания "пиши кратко" в промпте - фичат текст "на все деньги", но занеимением в обучающей выборке большой информации (видимо) повторяют одну и ту же мысль на все лады.

Ну просто в "пример", "что под капотом", "решение" и "применение" (или че там 4) - прям одно и тоже. Да и не будет человек трижды распсавший что touch... сгенерирует диапазон файлов писать это в 4 раз в отдельном блоке.

Напомнило моего препода из универа, который перемножал матрицы 4х4 у доски проговаривая каждую операцию "... 3 элемент второй строки умножаем на 2 элемент третьей строки... 4 элемент второй строкт умножаем на 2 элемент 4 строки..."

повторяют одну и ту же мысль на все лады.

не, это просто такой прием у пиндосов, повторять одну мысль 2-3 раза, чтобы до самого тупого читателя точно дошло

Очень много этакого "текстового бойлерплейта", чатгпт любит подобной воды налить. Никакой уровень владения материалом - начиная от того, что tail -f или cd - слишком уж базовые для такого заголовка. Наконец, человек объединил бы 1 и 3, расширил бы варианты для cd, написал бы про grep по истории, раз уж писал про tail | grep.

Конечно, всё это можно было бы объяснить копирайтером, которому платят по символам и который плавает в теме, но какой в этом практический смысл в наше время, если гпт даст тот же результат?

Я сначала написал комментарий, а потом почитал остальные.

А ведь похоже, очень похоже. Что нибудь из разряда 4о

Скобки "{}" это глоббинг в баше, так что пример с директориями и touch это просто два примера одного и того же. Раскрытие таких скобок происходит до передачи команды на выполнение.

"!125" - man history, там есть другие приколюхи типа поиска в истории по "!?подстрока", который может быть быстрее, чем искать команду глазами в истории. Также man bash описывает некоторые операции с историей команд, например "history -c" для очистки истории команд.

Команда cd при смене директории устанавливает переменную окружения OLDPWD, и если параметр это "-", он заменяется на значение переменной OLDPWD до передачи на выполнение. Ну и можно было описать pushd и popd, раз уж разговор зашел про навигацию по директориям.

Всё выше напрямую связано с bash и описывается практически во всех руководствах как база по работе в командной оболочке. Статья прям для совсем начинающих. Можно было бы заодно упомянуть как "|" работает, если так.

Ей-богу, соберусь когда-нибудь написать цикл статей по башу, чтобы ссылки в камментах к таким статьям постить :-D

Ещё бы статью как многие башизмы реализовывать в POSIX шелле.

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

вы не поверите, какое количество "специалистов по поддержке ПО на Unix системах" не знает что делает команда ls ~/bin

не знает что делает команда ls ~/bin

Выдаёт ошибку, конечно же! /s

(если в домике у пользователя нет каталога bin — а он по умолчанию не создаётся...)

Ну, нельзя исключать варианта, что у него домашником стоит /

Я такое встречал в этой жизни, что озвученное мной даже извращением то называть зазорно.

Ещё можно юзать систему из-под рута.
Я кстати юзал (а кто мне запретит? да и всё равно нужен был рут, а не sudo, емнип, для нормальной работы скриптов).
Правда юзверя таки создавал потом (потому как в DE всё же не всё под ним работает, хотя его я и из-под рута запускал и без DM в системе даже ^_^).

при наличии рута bin может быть где угодно жи =)

ну и я не обратил внимание на то что на домашнюю папку ссылка

Очень странный пример команды, почему вы его привели? Что именно в нём путает "специалистов по поддержке ПО на Unix системах"?

Спасибо, не знал про поиск по истории, всегда делал history | grep что_нужно

Пропишите в ~/.inputrc:

"\e[A": history-search-backward
"\e[B": history-search-forward

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

Т.е. набрав cp и нажав стрелку вверх, вы получите предыдущий cp, который запускался в терминале, за ним еще и еще. Стрелкой вниз можно листать обратно.

А еще перед командой history хорошо поставить пробел, чтобы она не сохранялась в history

Коммент который лучше статьи)

Я такие статьи во многом ради комментов и читаю.

А что мне потом делать с этим чудовищным количеством времени (3 секунды в неделю), которое я экономлю на cd или mkdir?

Спасибо, все знал, кроме фишки с touch {1..10}, давно хотел такое. Оказывается работает и {01..10}. Супер!

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

еще накину мелочи:

cd без параметров перекинет в домашний каталог

история комманд хранится в ~/.bash_history (на случай если вам надо что-то не из недавнего, а старое найти)

видеть обновления файлов в реальном времени можно еще в mc - открыть по f3 файл, нажать и держать end

история комманд хранится в ~/.bash_history

(ехидно:) А нет у меня такого файла!

(а вот .tcshrc — есть!)

У каждого свой любимый шелл.

Во фре tcsh традиционно использует /etc/csh.cshrc и ~/.cshrc.

И тем не менее у меня радостно использует ~/.tcshrc

Все согласно man-у:

Если нет файла ~/.tcshrc, то подгружается ~/.cshrc. Но традиционно ~/.tcshrc во фре отсутствует и пользователям предлагается использовать оригиальный ~/.cshrc и /etc/csh.{cshrc,login,logout}.

Не знаю, у меня традиционно присутствует.

с файлами историй в ~/.profile я делаю так (по соображениям безопастности):

SAVEHIST=0
if [ $SAVEHIST -eq 0 ]; then
  export HISTFILE="/dev/null"
  export LESSHISTFILE="/dev/null"
  LL="$HOME/.history $HOME/.bash_history $HOME/.lesshst $HOME/.dash_history $HOME/.wget-hsts"
  for HH in $LL; do
    if [ -f "$HH" ]; then
        rm -f -- "$HH"
    fi
  done
  unset HH ; unset LL
fi

оно же на диалекте csh в ~/.cshrc

  if ($SAVEHIST == 0) then
    setenv HISTFILE "/dev/null"
    setenv LESSHISTFILE "/dev/null"
    foreach HH ( $HOME/.history $HOME/.bash_history $HOME/.lesshst $HOME/.dash_history $HOME/.wget-hsts )
      if ( -f "$HH" ) then
        rm -f -- "$HH"
      endif
    end
    unsetenv HH
  else
    set history = 1000
    set savehist = (1000 merge)
  endif

а затем что

$ man dash | grep HISTFILESIZE
$ man tcsh | grep HISTFILESIZE
$ man bash | grep -i "bloatware"

Это хитрости, меняющие жизнь? :) Думал прочитать что-нибудь интересное о find, xargs, grep, perl, sed, awk, cut, tr, paste, comm, jq, inotifywatch, strace, screen, в таком духе..

под это уже есть статьи прямо в вашем компьютере, можно почитать набрав команду man <название тулзы> /s

Не всегда, увы.

zuek@stand02:/etc$ man awk
bash: man: команда не найдена
zuek@stand02:/etc$

Ниче ни знаю, works on my machine 😅

AWK(1)                                               General Commands Manual                                              AWK(1)

NAME

       awk - pattern-directed scanning and processing language

SYNOPSIS

       awk [ -F fs ] [ -v var=value ] [ 'prog' | -f progfile ] [ file ...  ]

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

Вообще, я больше к Windows привык, но постоянно на любой работе сталкивался с линуксами - RedHat, Ubuntu, CentOS, Debian, и прочие, время от времени, пишутся какие-то скрипты, докерфайлы, всё такое. Да и на домашних ноутах часто Manjaro ставлю, оно удобное.

И, увидев пару вещей из этой статьи, я буквально, обомлел: "А что, так можно было?" Спасибо авторам подобных статей: на какие-то плюшки если ты случайно не наткнулся, то так и будешь всю жизнь как дурак.

Ну не учил я man всех системных функций наизусть. (

PS: обычно для просмотра обновления логов пользовался watch ... tail

В tail -f можно сразу за несколькими логами следить, команда будет выводить перед каждым блоком новых данных имя файла. Удобно, если отладка требует отслеживать и лог ошибок и специфичный лог:

tail -f app.log error.log custom_feature.log

А я в таких случаях просто несколько окон открываю...

Или можно тупо использовать journalctl -f

)

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

cd ..
cd ..
cd ..
cd ..

Можно выразить в одной команде:

cd ../../../../

В реальности будет две команды:

cd ../../../

Потом такой: "ой не попал!", и еще:

cd ../

Ещё надо было написать про опции -A, -B и -С для grep-а

A также -lnirov и блин, каждый раз забываю ещё какая там буква имена файлов убирает

Я брюзжу, но поехали.

cd - будет работать если вы вводили цельный путь (что логично). А если я шел шаг за шагом, то толку от этого. Это вернёт на уровень ниже. Откровение. cd ~ или cd / и то полезнее, там не нужно думать куда тебя перенесет, ты знаешь конченый результат. Можно и пару назад а одной команде, которым я пользуюсь через ../../../

history - я надеюсь что вы не в серьез, а просто угораете. Ибо перебирать последние 25-50команд в поисках той самой вместо ctrl(cmd) +r и начинать вводить команду - это прям решение. Если мне нужна 3-5 по списку из недавних то банально стрелка вверх помогает.

Вы всерьез это используете, и ещё что-то экономите на этом? И не секунды/минуты, а прям время?

Я прокрастинирую больше, чем сэкономлю на командах

cd - будет работать если вы вводили цельный путь (что логично).

Ну я порой так делаю. Удобно когда нужно несколько раз скакнуть туда/сюда чтобы посмотреть какой-то файл. Но целый путь к часто используемому каталогу стараюсь вбить, чтобы переход отбился в истории и потом можно быстренько было сделать Ctrl+R по этому пути... В принципе с этой связкой получается довольно удобно, но в любом случае это вкусовщина )

ctrl(cmd) +r хорош, когда команды сильно разные и оносительно короткие. Когда команды длинные и различаются парой символов, hystory рулит.

При ротации логов "tail -f" перестанет отслеживать изменения в файле. Чтобы tail продолжал отслеживать лог после ротации, нужно использовать опцию "-F":

tail -F some.log

ИМХО, детский сад, потому что гуглится очень быстро. Скажем, я в bash нулевой, но скрипт по поиску в текущей версии папки проектов Гита быстро переписал на поиск по всем веткам. Такое должен уметь делать любой разраб если хочет долго оставаться в профессии.

`man` - вот что изменит вашу жизнь)

Для начала попробуйте `man man`

"настоящий мужик начинает каждую команду с обращения man"

В мире гнутого софта принято пользоваться командой info.

Debian, имеющий GNU в полном названии дистрибутивов, видимо гнутым софтом не является.

Тузла info по-умолчанию есть в Ubuntu, есть в ALT-е. Даже в не гнутой FreeBSD она тоже есть. Почему нет в Debian-е я не знаю. Видимо пользователи Debian в руководствах не нуждаются. ;)

В Debian по-умолчанию мануалы в качестве документации, а info необязательна даже при наличии доков в соответствующем формате ;)

info была отличной задумкой, к сожалению проект не покрыл все что есть в man, и стал так сказать дополнением, а не заменой ;(

Честно говоря, как приверженец "unix way", я не вижу в чем состояла отличность этой задумки. Во многих линуксовых дистрибутивах часть манов содержит две строки и ссылку на info. Выходит, надо теперь держать две системы документации - man и info. Так как в *BSD очень много гнутого софта, то эта проблема вместе с ним перекочевала и туда. Таким образом гнушники просто взяли и "отравили" систему документации в Unix-подобных ОС - разработчики не понимают в каком формате им теперь писать доку и просто забивают на этот вопрос, отделываясь простейшим README.md. А это еще один, третий, формат.

в man не хватало разметки и перекрестных ссылок. в info их добавили, но проект info появился слишком рано и непродумано. Буквально за пару лет интернет стал настолько доступным и удобным, что проще было писать краткий и доступный man, а красивый и подробный - уже в полном html в инете.

Так на info и забили, ибо красиво оформить все равно проще в инете в html, а простой текст - так и man достаточен.

IMHO было бы правильнее добавить переход по якорям в less, и можно было бы развивать man... не знаю.

Самый явный аргумент в пользу нейросетёвости статьи: это заголовок "Просматриваем недавние команды с помощью history 5". И дальше текст в это разделе, который будто кроме 5 ничего не знает.

>"Команда cd - запоминает предыдущий каталог"
Как эта чушь попала на главную? Куда команда cd это запоминает?

Для меня самым полезным знанием о bash стали шорткаты Ctrl-R и Alt-. Вот они сильно изменили стиль и увеличили эффективность.

Ещё лайфак - стараюсь делать cd всегда по абсолютным путям. Вместо cd ../myanotherrepo - cd ~/git/myanotherepo. Так это можно достать из истории по Ctrl-R и быстро попасть в нужное место независимо от текущей директории.

Ну как без коронки про "!!", вместо которых подставляется последняя запущенная команда ?

Когда забыл "sudo", и как царь "sudo !!"

если что-то забыл в длинной строке, то можно так

$ cho hello
Command 'cho' not found
$ ^cho^echo^
echo hello
hello

touch можно передать и существующие файлы, обновляются только временные метки (тут внезапно раскрывается смысл названия команды).

Да ладно, чё наехали-то? Знать ВСЕ команды и ВСЕ случаи их применения - ну не знаю кем надо быть. Полно всяких нюансов бывает.

Например, загадка для первого класса - как удалить в каталоге все файлы типа imgXXXX.bin, оставив другие?

rm img*.bin

А как сделать то же самое для 1005000 таких файлов? Казалось бы , чего проще...

Выжимка: пять команд Linux для оптимизации рабочего процесса

  • mkdir со скобками одним махом создаёт несколько папок.

  • cd - быстро возвращается в предыдущий каталог.

  • touch с диапазоном чисел создаёт несколько файлов одновременно.

  • tail -f позволяет в реальном времени отслеживать изменения в логах.

  • history 5 вызывает последние команды для повторного выполнения.

Ну камон, коллега. Что из этого разделило вашу жизнь на "до" и "после"? Тут не стоит вопрос по поводу всех команд и всех флагов для этих команд. Вы можете очень просто запустить dash, попытаться выполнить все эти команды, посмотреть на результат и сделать выводы.

А загадка не для первого класса совсем, скорее для пятого со звездочкой, учитывая, что мало кто сходу берет во внимание, во что будет раскрываться "*" ДО передачи команды на выполнение, особенно с учетом пробелов в именах. Если файлов 100500, то после раскрытия командная строка может запросто превысить буфер командной строки. Тут если начинать эксперименты, то уж с "find . -maxdepth 1 -name 'img*.bin' -delete", и дальше смотреть, а не с раскрытия звездочки.

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

Рекомендую освоить команду gdb. После этого Ваша жизнь точно не будет такой как прежде.

А еще dtrace (или strace для линохоидов).

Спасибо, мне было полезно узнать про эти возможности!

А эти опции - стандартные для перечисленных команд? Или же они есть только в реализации GNU ?

Статья совсем для новичков или реально ИИ-шная.
Реальное частое использование {} - в команде:
cp myconfig.config{,.or}
Для создания резервной копии конфига.

После знания о ctrl+r в bash, уж точно ваша жизнь перестанет быть прежней и вы забудете про "Решение: history 5" как о страшном сне.

Советую установить:

  • zsh вместо bash. К zsh расширение oh-my-zsh, в которое входят сотни плагинов

  • LSDeluxe вместо ls

  • Bat это как cat, только с подсветкой синтаксиса

  • TailSpin как дополнение или замену tail - F, это логи с подсветкой

  • Dust виесто du, для анализа места на диск

  • Ну и познакомиться с PowerLine10K и установить расширенные шрифты NerdFonts

Вот только после этого ваша консоль никогда не будет прежней.

Давно хотел bat попробовать. В архивах тоже умеет? Мне что-то most полюбился, но там без подсветки конечно. А для места на диске ncdu юазю

Статьи, скорее вредительские. Вот именно эти команды лучше заменить в каком-то файл-менеджере.. Зато есть xrandr в Линукс и подобные вещи в Винде, я их непомню, у меня это в батнике записано. И пользоваться ими гораздо удобнее и быстрее чем путешествовать по куче "интуитивно понятных" выпадающих менюшек и шелчков мыши. Они у меня в одной папке. Ctrl+D в кроссплотферменном DoubleCommander и щелкать на батнике одной кнопкой. К слове, в ДОС также делали.. Командами каталогов пользовались в случае жесткой нехватки памяти.. Но и тогда были вот подобные заумные книги, где было описание сотен малоприменяемых команд. Из-за подобных описаний и победило "пальцетыкание" в экран

Зато есть xrandr в Линукс и подобные вещи в Винде

xrandr -s 1920x1080 ?
а в винде как?

команды Linux сэкономят вам часы рабочего времени. Но если только вы умеете грамотно с ними обращаться.

А как "грамотно" обращать с "командами Linux" расскажете?

А как "грамотно" обращать с "командами Linux" расскажете?

Поставить GUI оболочку поверх них и тыкать мышью, не вникая особенно в man'ы до тех пор, пока не понадобится сделать что-то странное, например запустить не отдельно, а в скрипте, и еще и передать/получить аргументы от разных "участников" скрипта. Впрочем, GUI же этому не помеха.

Поставить GUI-оболочку поверх чего, простите?

в смысле DE с WM и DM на свой вкус

У этой статьи на момент написания этого коммента 94 плюса. Хммммммммммм....

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

UFO landed and left these words here

Вот не люблю это уничижительное "башизмы". bash - давно как стандарт. И только Debian и ему подобные делят их на "dash-для скриптов, bash-для интерактивной работы", и именно от них пошло вот это унизительное "башизм". Как будто это что-то плохое: разработчики и для пользователей и для скриптописателей стараются, а их за это "башистами" обзывают. Хорошо еще без "ф" в первой букве. К слову, пользователи того же Alpine поймут: ash - вот где хардкор, там вам и dash счастьем покажется. Тем не менее и там можно практически все то же, даже динамические массивы (немного костыльно, но все же можно).

А слова "модернизм", "классицизм", "импрессионизм" вас не смущают?

Башизм пошло совсем не от Дебиана. Вы в курсе вообще про юниксы и таймлайн Дебиана, баша, дэша, других командных оболочек? И про совместимость и миграцию скриптов? Или вы начали с Убунты и не интересовались историей? Если уж на то пошло, то Дебиан наоборот сделал очень многое для популяризации баша.

За 20 лет никто ни разу меня не называл башистом, ни единого раза, так что не придумывайте.

Согласен. А про таймлайн - в курсе. Debian и его производные по субъективным причинам недолюбливаю (но уважаю). Начинал я кстати с FreeBSD 4.2, хотя и там пожалуй первое что я ставил из портов был bash.

Ну, имеете право, не обязательно их любить. Я вот Убунту недолюбливаю и её производные :-D А фряха 4 ветки была отличная операционная система. Если бы порты под неё не устарели, я бы ее где-нибудь до сих пор использовал.

А я недолюбливаю Linux Mint :)

Sign up to leave a comment.