Команда cut в bash

Ну как можно?! Пять звёзд, а при этом не в курсе походу что такое баш.

cut это не команда баша, это программа. Каждая программа может устанавливать свои правила парсинга аргументов, и шелл (баш - это ОДИН из шеллов, но далеко не единственный) тут ни при чём. Впрочем, поскольку cut это часть пакета утилит GNU coreutils то правила парсинга аргументов у него похожие как у остальных GNU coreutils (например echo, ls или mv).

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

Встроенной какой-то либы нет для парсинга аргументов командной строки. Просто так принято, что с - начинается имя, а далее через = или следующим аргументом идет значение. Для многих «стандартных» утилит применим краткий синтаксис -[a-z]<значение>, но это на усмотрение авторов, а им никто не мешает сделать так как взбредет в голову. Это не краткий синтаксис. Обработка аргументов уникальная для каждой утилиты

Это некое исключение в bash или это нормальный синтаксис для всех команд?

Нормальный в общем вроде, но иногда бывает, что какая-то программа не понимает, а так да, например

ping -c3
tail -n1

и тд.

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

Можно ли сказать, что cut это функция bash?

watch -n3 ls

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

Это некое исключение в bash или это нормальный синтаксис для всех команд?

bash тут не причем. Все зависит от конкретных команд, точнее какой парсер параметров командной строки они используют. Например cut и прочие команды из coreutils используют GNU getopt. В этих библиотечных функциях как раз поддерживается синтаксис без пробела после имени опции. Негнутые программы могут использовать другие библиотеки или вообще самописные парсеры, которые могут требовать обязательный пробел после имени опции. В общем it depends.

Какие ещё подобные исключения вы можете привести, где после опции с одним дефисом не стоит пробел и сразу идёт значение опции?

gcc hello.c -O2 -I/usr/local/include -ohello

И второй вопрос: к какому варианту в cut лучше привыкнуть сразу? К первому или второму?

По мне так читабельнее первый вариант с пробелом. А вообще почитай Google Shell Style Guide. Там в примерах видно, где лучше использовать пробелы, где ставить кавычки и т.д.

Подстава в твоём случае скорее может скрываться не в том, что такое cut и как он себя ведёт, а не окажется ли неэкранированный символ специальным для баша в коде сut -d. -f1 😀

А, даже так. Тогда лучше с пробелами привыкнуть, чтобы сработало и там, и там. Но это всё, конечно, разрыв шаблона, непривычно. Увидел где-то на форуме такую запись и ещё удивился, что никто не поправляет человека, что забыл пробелы поставить))

А ещё такой прикол есть: если при вызове sed’а соединить опции -i и -e <pattern> в слитное -ie <pattern>, то опция -e, в добавок к своему нормальному значению, сработает ещё и как аргумент для -i (т.е. как если бы было написано -i e -e <pattern>), что приведёт к созданию файлов с буквой «e» на конце вместо изменения существующих.

Да ладно тебе, прикольно же, прикинь сколько ты пробелов сэкономишь за всю жизнь!

Фига! Не, ну нафиг, с этим sed-ом шутки плохи :-)

Не, мне с пробелами больше нравится. Это выглядит «по-человечески», не сливается визуально. Меня мантра Python научила наглядности в коде, пускай даже долго печатать.

Это можно сказать стандартный синтаксис для всех команд которые обрабатываются через гнутый getopt_long . Я тоже в своё время на это наткнулся случайно, но ни в одном мане я про это не встречал упоминаний. Т.е. стандарт де факто, но молчаливый. +)

В скриптах пишу по человечески, в командной строке иногда так.

Вот именно! Читаю man’ы, но там про такой вариант записи нет нигде. Возможно, один раз где-то и видел, но подумал, что это ошибка, опечатка, т.к. пояснений к этому не было.

Ну, тут как бы уже этакие привычные выражения наблюдаются в скриптах, например мало кто напишет echo >foo, как-то некрасиво, но все пишут >/dev/null. И когда вырисовывается длинная спагеттина, то всякие -n1 и -с3 очень даже в тему оказываются. Но я не програмист, так, реплика из зала.

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

Увидел где-то на форуме такую запись и ещё удивился, что никто не поправляет человека, что забыл пробелы поставить))

Хехе, никогда не понимал этой кулхацкерской экономии на пробелах. Я всегда ставлю пробелы после опции, кроме некоторых программ, у которых в манах опции пишутся без пробела, ну и соответственно все в интернетах тоже пишут без пробела. Однобуквенные опции использую только в самых общепринятых командах типа cp, mkdir, grep и т.д. В прочих командах стараюсь использовать длинные опции типа --option-name=value. Очень помогает, когда надо через полгода подправить уже написанный скрипт и ты уже в упор не помнишь, что делали всякие флаги -b, -i, -t

Нет, cut вообще никакого отношения к башу не имеет. Это такая же программа как top, Xorg или файрфокс, расположена в /usr/bin/cut обычно.

но все пишут >/dev/null

Не ври, я пробел ставлю, без пробела и /dev/null тоже некрасиво. А вот в опциях, где можно, не ставлю.

Хорошо, уточню. Говоря о bash, подразумеваю shell, и наоборот. Везде так обычно пишут. Да, формально это не так и неправильно. Это как про linux’ы на форумах и в жизни говорят, будто это операционная система, а на самом делел это просто ядро операционной системы, не более.

Можно и без пробела, но надо учитывать, что это не универсально и есть утилиты, которые используют одинарный дефис перед параметром. Например magick (из пакета ImageMagick):

magick -list Kernel
magick --list Kernel  # Ошибка
magick -listKernel    # Ошибка
magick list Kernel    # Ошибка

Это плохая привычка, потому что шеллы бывают разные, а баш это линуксизм вообще, в BSD его обычно нет например. Шелл без уточнений это POSIX шелл /bin/sh.

И второе, ещё раз, cut это не команда никакого шелла, это программа. Это точно так же как сказать что firefox это команда шелла.

заворачивать в пельменно-переменную

Не, \
просто \
нарезать, \
да и всё.

То есть, bash не воспринимает cut как команду? А как он её тогда интерпретирует? В широком смысле слова те же самые фукнции можно воспринимать как команды, хотя это «пачка» команд .. мне кажется, это всё словоблудие, которое может привести в никуда. Вопрос большинству в треде оказался понятен, несмотря на моё косноязычие (тут не спорю).

Ну не знаю, мне кажется, что выражения типа

>/dev/null
2>/dev/null
&>/dev/null

должны просто вылетать как аккорды, и читаться как одно слово, глагол, не?

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

Именно. Команда или программа. Firefox - тоже может быть командой, командой выполнить целую простыню кода … я просто всё это логически масштабирую. Вот, например, с linux’ом так не получится. Хоть ты тресни, ядро - это не операционная система, а операционная система - это не ядро. Хотя … если опять же масштабировать в микромир, может, как раз ядро будет микросистемой (задумался).

Firefox - тоже может быть командой, командой выполнить целую простыню кода

Пожалуйста, в федора-шапках так:

$ file /usr/bin/firefox 
/usr/bin/firefox: Bourne-Again shell script, ASCII text executable

Он ищет бинарник с названием cut где-нить в $PATH. В этом бинарнике может быть, в общем случае, что угодно, хоть патч Бармина, башу всё равно.

Вопрос большинству в треде оказался понятен, несмотря на моё косноязычие (тут не спорю).

Вопрос то и мне понятен (и я на него даже ответил сразу).

Хоть ты тресни, ядро - это не операционная система, а операционная система - это не ядро.

Это ты Столлмана процитировал?

Нет, не считаю /dev/null чем-то особенным в этих редиректах. А третий вариант вообще не использую, понятнее так: >> /dev/null 2>&1

Фига, понятнее…

Он не прав?)) Но если поставить вопрос по-другому, то да, конечно же, операционная система без ядра быть не может, а если и может, то получится монстр как в фильме «Субстанция» (2024). А вот ядро без операционной системы, возможно и сможет, хотя тут сомнения. Зачем ядро само по себе, само в себе? Ядро это некий набор инструкций для аппаратной части компа, его устройств… по сути, «система» нужна для того, чтобы человек мог воспользоваться комфортно компьютером. Технически, если знать код ядра, можно и без системы, наверное, взаимодействовать с аппаратам, но это будет хардкор, на который не согласятся даже бывалые программисты.

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