Яка мета команди, яка нічого не робить, будучи лише лідером коментарів, але насправді оболонкою, яка вбудована сама по собі?

Це повільніше, ніж вставляти коментар у свої сценарії приблизно на 40% за виклик, що, ймовірно, сильно різниться залежно від розміру коментаря. Єдині можливі причини, які я бачу в цьому, це:

# poor man's delay function
for ((x=0;x<100000;++x)) ; do : ; done

# inserting comments into string of commands
command ; command ; : we need a comment in here for some reason ; command

# an alias for `true' (lazy programming)
while : ; do command ; done

Я думаю, що я справді шукаю - це те, яке історичне застосування воно могло б мати.

Історично снаряди Борна не мали trueі falseяк вбудовані команди. trueзамість цього просто псевдонім :, а falseщо - щось на зразокlet 0 .

:трохи краще, ніж trueдля переносимості давніх раковин Борна. Як простий приклад, розгляньте відсутність ні !оператора трубопроводу, ні ||оператора списку (як це було у випадку з давніми оболонками Борна). Це залишає elseпункт ifтвердження як єдиний засіб для розгалуження на основі статусу виходу:

if command; then :; else ...; fi

Оскільки ifвимагає незаповненого thenпункту, а коментарі не вважаються непорожніми,: .

У наш час (тобто в сучасному контексті) зазвичай можна використовувати або :або true. Обидва визначені POSIX, а деякі вважають trueлегшими для читання. Однак є одна цікава відмінність: :це так званий POSIX спеціальний вбудований , тоді trueяк це звичайний вбудований .

• В оболонку потрібно вбудувати спеціальні вбудовані; Регулярні вбудовані вбудовані лише "типово", але це не суворо гарантується. Зазвичай не повинно бути звичайної програми, названої :з функцією trueв PATH більшості систем.

• Мабуть, найважливіша відмінність полягає в тому, що за допомогою спеціальних вбудованих програм будь-яка змінна, встановлена ​​вбудованим - навіть у середовищі під час простої оцінки команд - зберігається після завершення команди, як це демонструється за допомогою ksh93:

  $ unset x; ( x=hi :; echo "$x" )
  hi
  $ ( x=hi true; echo "$x" )
  
  $

  Зауважте, що Zsh ігнорує цю вимогу, як і GNU Bash, за винятком випадків, коли вони працюють в режимі сумісності POSIX, але всі інші основні "POSIX sh похідні" оболонки дотримуються цього, включаючи тире, ksh93 та mksh.

• Ще одна відмінність полягає в тому, що регулярні вбудовані модулі повинні бути сумісні з exec- продемонстровано тут за допомогою Bash:

  $ ( exec : )
  -bash: exec: :: not found
  $ ( exec true )
  $

• POSIX також чітко зазначає, що це :може бути швидше true, хоча це, звичайно, конкретні деталі реалізації.

Я використовую його для легкого включення / відключення змінних команд:

#!/bin/bash
if [[ "$VERBOSE" == "" || "$VERBOSE" == "0" ]]; then
    vecho=":"     # no "verbose echo"
else
    vecho=echo    # enable "verbose echo"
fi

$vecho "Verbose echo is ON"

Таким чином

$ ./vecho
$ VERBOSE=1 ./vecho
Verbose echo is ON

Це робить чистим сценарій. Це неможливо зробити за допомогою "#".

Також,

: >afile

- це один із найпростіших способів гарантувати, що "afile" існує, але він дорівнює 0.

Корисна програма для: - якщо вам цікаво тільки розширення параметрів для їх побічних ефектів, а не фактичне передавання їх результату команді. У такому випадку ви використовуєте PE як аргумент або: або false, залежно від того, чи потрібно вихідний статус 0 або 1. Приклад може бути : "${var:=$1}". Так :як це вбудований, він повинен бути досить швидким.

:також може бути для блокування коментарів (схоже на / * * / на мові C). Наприклад, якщо ви хочете пропустити блок коду в своєму сценарії, ви можете зробити це:

: << 'SKIP'

your code block here

SKIP

Якщо ви хочете обрізати файл до нуля байтів, корисного для очищення журналів, спробуйте:

:> file.log

Це схоже на passPython.

Одним із застосувань було б заглушити функцію, поки вона не запишеться:

future_function () { :; }

Ще два способи використання, не вказані в інших відповідях:

Ведення журналів

Візьмемо цей приклад сценарію:

set -x
: Logging message here
example_command

Перший рядок, set -xзмушує оболонку роздрукувати команду перед її запуском. Це досить корисна конструкція. Мінусом є те, що звичайний echo Log messageтип оператора тепер друкує повідомлення двічі. Метод товстої кишки обходить це. Зауважте, що вам все одно доведеться уникати спеціальних символів так само, як і раніше echo.

Назви роботи Cron

Я бачив, як він використовується в роботі з cron, як ось такий:

45 10 * * * : Backup for database ; /opt/backup.sh

Це робота з крон, яка виконує сценарій /opt/backup.shщодня о 10:45. Перевага цієї методики полягає в тому, що вона дозволяє покращити вигляд предметів електронної пошти, коли /opt/backup.shдрукується деякий вихід.

Ви можете використовувати його спільно з backticks ( ``) для виконання команди, не показуючи її вихід, наприклад:

: `some_command`

Звичайно, ви могли просто зробити some_command > /dev/null, але :-версія дещо коротша.

Попри це, я не рекомендую насправді робити це, оскільки це просто заплутає людей. Це просто прийшло в голову як можливий випадок використання.

Це також корисно для поліглот-програм:

#!/usr/bin/env sh
':' //; exec "$(command -v node)" "$0" "$@"
~function(){ ... }

Це тепер і виконуваний скрипт оболонки і програма JavaScript: це означає ./filename.js, sh filename.jsі node filename.jsвся робота.

(Очевидно, трохи дивного використання, але, тим не менш, ефективного.)

Деякі пояснення на вимогу:

• Сценарії оболонок оцінюються по черзі; і execкоманда, коли виконується, припиняє оболонку і замінює її процес результативною командою. Це означає, що для оболонки програма виглядає так:

  #!/usr/bin/env sh
  ':' //; exec "$(command -v node)" "$0" "$@"

• Поки в слові не відбувається розширення чи згладжування параметрів, будь-яке слово в оболонці-скрипті може бути загорнуте в лапки без зміни його значення; це означає, що ':'це еквівалентно :(тут ми лише обернули це цитатами для досягнення описаної нижче семантики JavaScript)

• ... і як описано вище, перша команда в першому рядку є неоперативною (це означає : //, або якщо ви віддаєте перевагу цитувати слова ':' '//'.) Зауважте, що тут //не має особливого значення, як це робиться в JavaScript; це просто безглузде слово, яке викидається.)

• Нарешті, друга команда в першому рядку (після крапки з комою) - це справжнє м'ясо програми: це execвиклик, який замінює виклик скрипту оболонки , а процес Node.js викликається для оцінки решти сценарію.

• Тим часом, перший рядок у JavaScript розбирає як string-literal ( ':'), а потім коментар, який видаляється; Таким чином, для JavaScript програма виглядає так:

  ':'
  ~function(){ ... }

  Оскільки рядок-літерал знаходиться на рядку сам по собі, він є неоперативним оператором, і таким чином вилучається з програми; це означає, що весь рядок видалено, залишивши лише ваш код програми (у цьому прикладі function(){ ... }корпус.)

Функції самодокументування

Ви також :можете вбудувати документацію у функцію.

Припустимо, у вас є бібліотечний сценарій mylib.sh, що забезпечує різноманітні функції. Ви можете або джерело бібліотеки ( . mylib.sh) і викликати функції безпосередньо після цього ( lib_function1 arg1 arg2), або уникати захаращування простору імен і викликати бібліотеку аргументом функції (mylib.sh lib_function1 arg1 arg2 ).

Чи не було б непогано, якби ви також могли набрати mylib.sh --helpта отримати список доступних функцій та їх використання, не потребуючи вручну підтримувати список функцій у тексті довідки?

#! / бін / баш

# усі "загальнодоступні" функції повинні починатися з цього префікса
LIB_PREFIX = 'lib_'

# "публічні" функції бібліотеки
lib_function1 () {
    : Ця функція робить щось складне з двома аргументами.
    :
    : Параметри:
    : 'arg1 - перший аргумент ($ 1)'
    : 'arg2 - другий аргумент'
    :
    : Результат:
    : " це складно"

    # фактичний код функції починається тут
}

lib_function2 () {
    : Функціональна документація

    # код функції тут
}

# довідкова функція
--help () {
    echo MyLib v0.0.1
    відлуння
    Використання відлуння: mylib.sh [function_name [args]]
    відлуння
    echo Доступні функції:
    оголосити -f | sed -n -e '/ ^' $ LIB_PREFIX '/, / ^} $ / {/ \ (^' $ LIB_PREFIX '\) \ | \ (^ [\ t] *: \) / {
        s / ^ \ ('$ LIB_PREFIX'. * \) () / \ n === \ 1 === /; s / ^ [\ t] *: \? ['\' '"] \? / / ; s / ['\' '"] \?; \? $ //; p}}'
}

# основний код
if ["$ {BASH_SOURCE [0]}" = "$ {0}"]; тоді
    # сценарій був виконаний замість джерела
    # викликати запитувану функцію або відобразити допомогу
    if ["$ (type -t -" $ 1 "2> / dev / null)" = функція]; тоді
        "$ @"
    ще
        - допомогти
    фі
фі

Кілька коментарів щодо коду:

1. Усі "загальнодоступні" функції мають однаковий префікс. Тільки вони призначені для виклику користувачем та перелічені у довідковому тексті.
2. Функція самодокументування покладається на попередній пункт і використовує declare -fдля перерахування всіх доступних функцій, потім фільтрує їх через sed, щоб лише функції відображення з відповідним префіксом.
3. Це гарна ідея укласти документацію в єдині лапки, щоб запобігти небажаному розширенню та видаленню пробілів. Вам також потрібно бути обережними, використовуючи апострофи / цитати в тексті.
4. Ви можете написати код, щоб інтерналізувати префікс бібліотеки, тобто користувач повинен лише набрати, mylib.sh function1і він буде внутрішньо переведений в lib_function1. Це вправа, залишена читачеві.
5. Функція довіри називається "--help". Це зручний (тобто лінивий) підхід, який використовує механізм виклику бібліотеки для відображення самої довідки, не потребуючи коду додаткової перевірки $1. У той же час він буде захаращувати ваше простір імен, якщо ви джерело бібліотеки. Якщо вам це не подобається, ви можете або змінити ім’я на щось на зразок, lib_helpабо фактично перевірити параметри аргументу --helpв головному коді та викликати довідкову функцію вручну.

Я бачив це використання в сценарії і вважав, що це хороша заміна для виклику базового імені в сценарії.

oldIFS=$IFS  
IFS=/  
for basetool in $0 ; do : ; done  
IFS=$oldIFS  

... це заміна коду: basetool=$(basename $0)