Это задокументировано в документации let
, прямо под тем местом, где говорится, что он принимает выражение.
Встроенная функция let позволяет выполнять арифметические действия с переменными оболочки. Каждое выражение оценивается в соответствии с правилами, приведенными ниже в Арифметика оболочки . Если последнее выражение дает результат 0, let возвращает 1; в противном случае возвращается 0.
Арифметика оболочки включает операторы присваивания =
, * =
, / =
, % =
, + =
, - =
, ,
>> =
, & =
, ^ =
и | =
. Это, как правило, не связано с обычными операторами присваивания, которые не применяют никакой дополнительной обработки.
и не показывать содержимое при размещении файла в каталоге.
Отсутствие вывода cat
для файла не означает, что файл пуст, как показывает следующий эксперимент:
$ truncate -s 1M foo
$ ll foo
-rw-r----- 1 user users 1048576 Nov 15 19:28 foo
$ file foo
foo: data
$ cat foo
$
cat
действительно выводит NUL-символов на 1 МБ, но эти символы случаются быть невидимым в терминале.
Ваш вопрос о пустых файлах несколько неоднозначен. Подходит ли foo
выше? Если «пустой» означает нулевую длину, тогда find
может вам помочь:
find dir -type f -empty
перечисляет все файлы нулевой длины в dir
. Если ваш find
не поддерживает -empty
, вы можете использовать вместо него -size 0
.
В сценариях оболочки вы можете использовать выражение -s file
, которое истинно, если файл
существует и не является пустым. Чтобы проверить, является ли файл пустым (при условии, что он существует), используйте что-то вроде
if [ \! -s file ] ; then ... ; fi
. В качестве альтернативы вы можете использовать stat (1)
. Здесь с вариантом GNU:
$ stat --format=%s foo
1048576
, который вы можете использовать в дальнейшем для сравнений.
Из ваших подсказок:
ls -l
cat
ing их, похоже, ничего не показывает wc -l
возвращает 0. Мы можем сказать:
wc -l
подсчитывает символы новой строки) Несмотря на то, что существует большое количество символов, которые невидимы в терминале, такие как большинство управляющих символов и некоторые расширенные символы Unicode, для многих различных поврежденных файлов, чтобы показать, что поведение заставляет меня думать, что это, вероятно, быть символом NUL.
Поврежденный файл можно рассматривать как все нули, если все ссылки на блоки данных были удалены из него, а атрибут size в индексном дескрипторе остался нетронутым. Это полностью разреженные файлы.
Если поле счетчика блоков в inode также не повреждено, вы можете обнаружить их с помощью (при условии, что GNU find
и awk
):
find . -size +0 -printf '%b%p\0' | awk -v RS='\0' '
/^0/{print substr($0, 2)}'
То есть find файлы, размер которых не равен нулю, но использование диска равно нулю.
Мой самый большой вопрос заключается в том, есть ли способ более низкого уровня для проверки содержимого эти файлы будет намного быстрее, чем простой поиск.
Попробуйте du
:
$ truncate -s 4G my4g
$ ls -l my4g
-rw-rw-r-- 1 tange tange 4294967296 Mar 4 15:34 my4g
$ cat my4g
$ du my4g
0 my4g