file + grep

Как-то сложно всё, но тебе похоже нужно

if $(echo $value | grep -i '\.doc')

if $(echo $value | grep -i '\.doc')

Не работает - «File name to long»

потому что на самом деле надо

if echo "$value" | grep -i '\.doc'

if $(echo $value | grep -i '\.doc')

Не работает. Находит вообще все файлы. Насколько я слабо знаю bash, но думаю, что происходит тупо подстановка пути. Как заставить его обработать строку, а не путь к файлу?

Можно, конечно полезть в python, но из-за многократных вызовов внешней программы file, что-то не хочется.

В цикле ... grep-ом:

case $value in *.ext) ... ; esac

case $value in *.ext) ... ; esac

Оно самое. Спасибо ув. anonymous

pod> if $(echo $value | grep -i '\.doc')
f1u77y> if echo "$value" | grep -i '\.doc'

Ужас какой. Где вы такое подцепили?

Ужас какой

Кавычки должны быть двойными, кстати.

Где вы такое подцепили?

Есть другое решение (кроме использования case)?

Нужно проверить, содержит ли путь к определенным файлам определенные значения (напр. doc). Вывод команды file содержит строки, разделенные двоеточием и состоящие из: полный путь к файлу; описание файла. В цикле, с помощью awk выводим в переменную только путь к файлу.

Нахрена тут awk?

Что вы вообще делаете? Скармливаете список файлов утилите file(1), чтоб не вызывать ее многократно, я так понимаю? В целом разумно, однако:

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

Выравнивание по колонкам отключить почему-то нельзя, но можно поменять разделитель, возьмем хотя бы табуляцию (тоже, разумеется, допустимую в именах, но это уже экзотика):

#!/bin/bash

while IFS=$'\t' read file type; do
    read type <<< "$type"
    if [[ $file == *.txt ]]; then
        ...
    fi
done < \
     <(file --separator $'\t' *)

read type <<< "$type" — это обрезка (trim) пробелов, тех самых, что нельзя убрать.

Но вообще аккуратнее получается, если считать, что file(1) вовсе не умеет выводить имена файлов:

#!/bin/bash

files=(*)
readarray -t types < <(file --brief "${files[@]}")

for (( i = 0; i < ${#files[@]}; i++)); do
    if [[ ${files[$i]} == *.txt ]]; then
        printf '%s is a(n) %s\n' "${files[$i]}" "${types[$i]}"
    fi
done

Нахрена тут awk?

Из-за слабых знаний баш.

В целом разумно, однако:

Ух ты. Постараюсь разобраться за вечер ( Кстати, решается проблема - в именах файлов допустимы двоеточия.

bash:

shopt -s nocasematch; if [[ $value == *.doc ]] ... shopt -s nocasematch; if [[ $value =~ [.]doc$ ]] ... ext=${value##*.}; if [[ ${ext,,} == doc ]] ...

или если предположить, что файлы не содержат ни [:blank:], ни ":"

file --mime-type dir/* \
 | awk -F': +' '$0=$2" "$1' \
 | awk -F. '{printf "%s %s\n", (NF>1) ? tolower($NF): "none", $0}' \
 | while read -r ext mime path
do
	[ "$ext" = ext ] && echo "$mime $path"
done

аккуратнее получается

ага, особенно если содержимое директории изменится (между 3 и 4 строками)

аккуратнее получается

ага, особенно если содержимое директории изменится (между 3 и 4 строками)

Да нет, прошлый вариант тоже беспроблемен по этой части.

причем тут прошлый вариант?

или если предположить, что файлы не содержат ни [:blank:], ни ":"

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

причем тут прошлый вариант?

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