Внутри VS Code расширение ShellCheck может быть настроено с необязательными аргументами; из настроек:
откройте settings.json
и добавьте что-то вроде
"shellcheck.customArgs": ["-x"],
(Спасибо муру за подсказку.)
Существует несколько способов использования -x
вне зависимости от вызываемого инструментаshellcheck
:
вы можете установить параметры по умолчанию вSHELLCHECK_OPTS
:
export SHELLCHECK_OPTS='-x'
вы можете заменить свой двоичный файл:
mv ~/.cabal/bin/shellcheck{,-real}
printf '#!/bin/sh\nshellcheck-real -x "$@"\n' > ~/.cabal/bin/shellcheck
chmod 755 ~/.cabal/bin/shellcheck
В Linux /dev/null
реализуется рядом функций, включаяwrite_null
:
static ssize_t write_null(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
return count;
}
Как видите, буфер полностью игнорируется, и все, что делает функция, — это возвращает количество байтов, которое было запрошено для записи.
Эта функция может быть вызвана любое количество раз, и каждый вызов связан с небольшой стоимостью (стоимости вызова ядра ). Если вы запустите
cat /dev/zero > /dev/null
эта стоимость, вероятно, будет преобладать. cat
читает со своего входа (или из файлов, которые ему дали ), и записывает на свой выход неоднократно, пока либо не закончатся данные для чтения, либо не перестанет записываться. Однако при чтении из /dev/urandom
чтение более сложное , и я ожидаю, что они будут доминировать. В обоих случаях весь «ввод-вывод» управляется ЦП -, и cat
в конечном итоге будет использовать изрядное количество ЦП (100% одного логического ЦП )— в конечном итоге вызов ядра write_null
как можно быстрее, который продолжает ничего не делать как можно быстрее.
В более типичных обстоятельствах, когда /dev/null
используется, например, для отбрасывания информационного вывода программы, операций записи будет гораздо меньше, а их общая стоимость будет незначительной по сравнению с тем, что делает программа.
(Кстати, вы найдете реализацию /dev/zero
сразу после /dev/null
в приведенном выше коде.)