KOSMOS — сборка комфортненьких shell-скриптов, функций и конфигов системы

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

Статья подразумевают некую законченость, значимость, структуру и обработку формы.

Эй, стопэ. Мы не на первом канале. Это всего-лишь ЛОР, здесь можно и нужно быть проще. И да, топик вполне подходит под твое описание. ИМХО :)

Почему не тред? Там есть обсуждение. Это, по сути, технический блог, в котором предполагаются интересные вещи по поводу онтопика.

Потому что каждая статья — отдельный тред.

Есть общее описание идеи, есть краткое описание некоторых скриптов, есть ссылка на них, есть обсуждение. Что не так?

Зачастую попросту не стоит того. Нечего там расписывать порой.

можно и нужно быть проще.

А для этого есть форум. Но там тоже нужно вести себя прилично.

Можешь рассказать, зачем в коде у тебя везде по 2-5 пустых строк? https://git.org.ru/kosmos/KOSMOS/src/branch/main/S/C

Ты когда-нибудь дважды заглядывал в эту писанину?

зачем в коде у тебя везде по 2-5 пустых строк?

по 5 нету. 2 разделяют условия, циклы (всякие if, for), 1 разделяет назначение переменных, процессы в фоне. 3 разделяют назначение функций (4 кое-где осталось по-старинке, не везде поменял на 3).
так визуально удобнее.

Ты когда-нибудь дважды заглядывал в эту писанину?

сотни раз заглядывал.

git.org.ru/kosmos
Earth, Moscow region

ё-моё, и ты из этих

если изолировать админа локалхоста на 13 лет, то он в 84% случаев напишет подобный КОСМОС

1. Так а что это за ганстастайл с пустыми строками?

2. Если отделить функции для твоего слакварь и убрать всратые алиасы типа ak aw функционально бесполезные, то там полезного будет 10 функций

по 5 нету. 2 разделяют условия, циклы (всякие if, for), 1 разделяет назначение переменных, процессы в фоне. 3 разделяют назначение функций (4 кое-где осталось по-старинке, не везде поменял на 3). так визуально удобнее.

Вангую, что это codestyle sh или какого-то csh. И ты в баш этот всратый стиль тащишь. Более того, ты используешь эти всратые условия [] &&, вместо того, чтобы оформить это в нормальные баш исловия иначинаешь разделять пустыми строками логические блоки и проверки визуально отделять.

Кулхацкер 146lvl

сратые условия [] &&, вместо того, чтобы оформить это в нормальные баш исловия

Это как раз хорошо и правильно.

Это как раз хорошо и правильно.

Потому что позволяет в sh запускать?

Потому что шелл следует использовать как шелл. Тогда удобно будет. Ну, может и не удобно, но наименее неудобно.

Конструкции вида do-something && echo ok || echo fail позволяют использовать преимущества шелла: краткую, читаемую форму записи, для манипуляции процессами. Попытка же с помощью if писать как в нормальном языке программирования, приведёт к тому, что преимущества баша растеряются, а всё равно нормально не выйдет. Лучше уж сразу на настоящем языке и писать.

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

Да как-то в нормальном стиле весь обвес и такого не ощущаю

Японамать… Жесть какя-то :)
Для тех, кто в танке:

			numerate() {

				local c line


				while IFS= read -r line; do

					(( c++ ))

					printf "$c:%s\n" "$line"
				done


			}




		}




		C_command() { eval cat '"$file"' $hide_empty $numerate_lines $use_pager; }




	;;

	*)




		C_command() {


			[[ "$file" =~ .+/ ]] &&{

				dir="$BASH_REMATCH"


				[[ -e "$dir" ]] || mkdir -p -- "$dir" || continue 1


			}


			[[ -e "$file" ]] ||
				printf '%s\n\n' "#!${BIN%%/}/$default_SHELL" >"$file"


			_scripts=$(Ext=1 esc_regex "${KOSMOS_scripts%%/}")


			grep -Eqm1 "^$_scripts/($ignore_files)$" <<<"$file" ||
				chmod -- "$chmod" "$file"


			"${EDITOR[@]}" "$file"
		}

Ну так я ж об том же. Кто тут скажет, что вот так хуже, чем у него?

function numerate () {
    local c line

    while IFS= read -r line; do
	(( c++ ))
	printf "$c:%s\n" "$line"
    done
}

}

function C_command() {
     eval cat '"$file"' $hide_empty $numerate_lines $use_pager;
}

;;
*)

function C_command () {
	 if [[ "$file" =~ .+/ ]] && {
	        dir="$BASH_REMATCH"
	        [[ -e "$dir" ]] || mkdir -p -- "$dir" || continue 1
	    }

	 [[ -e "$file" ]] || printf '%s\n\n' "#!${BIN%%/}/$default_SHELL" >"$file"
	 _scripts=$(Ext=1 esc_regex "${KOSMOS_scripts%%/}")
	 grep -Eqm1 "^$_scripts/($ignore_files)$" <<<"$file" || chmod -- "$chmod" "$file"
	 "${EDITOR[@]}" "$file"
     }
     ..
 }

В код я не смотрел, но читабельнее точно.

Для того, чтобы в код посмотреть - сначала надо весь этот кулхацкерский codestyle убрать. Заморозьте его на неделю - он быстро рефакторинг сделает :)

надо весь этот кулхацкерский codestyle убрать.

делается одной командой.

рефакторинг сделает :)

зачем? или есть способ сделать отступы по определённым условиям в текстовом редакторе? например nano? IDE?

Жесть какая-то. Как читать этот if без then, но с &&, то ли в условии, то ли хз где, я не распарсил. Что за жесть с оторванными от всего ;; и *) перед этим — тоже.

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

Что за жесть с оторванными от всего ;; и *)

;; чтоб визуально заметнее было
*) потому что бывает очень много уровней вложений, если до этого есть ещё несколько if, for, и код сильно съезжает вправо.

Вообще мой вопрос про ;; *) был не к тебе. Но я понял, что это из середины вырванный фрагмент, и там case. Но тогда получается, что у @bryak тело того, что происходит в условиях case, без отступа, что тоже путает.

В общем, по-моему твой код читаемее, если убрать кучу пустых строк, что сделать легко.

Тупо как-нибудь вот так уже проще воспринимать:

#!/bin/env bash

chmod=0755
ignire_files='DESCRIPTION|functions/.*|PM/(DISK|GET_PKG_DEPS|LFS_/env|CONFIG)|TODO'

trap9

GET_ARGS "$@"
GET_OPTS "$@"

[[ -t 2 ]] && noCOL2="$noCOL" RED2="$RED"

declare -i c
unset Ext

_0="${0##*/}"

case "$_0" in
    A|CA)
        for (( c=0; c<${#OPTS[*]}; c++ )); do
            case "${OPTS[c]}" in
                -n) numerate_lines='| numerate';;
                -p) hide_empty='| sed /^$/d'
            esac
        done

        [[ "$_0" == A ]] && use_pager="| $PAGER"

        ea "${numerate_lines[@]}" ||{
            numerate() {
                local c line
                while IFS= read -r line; do
                    (( c++ ))
                    printf "$c:%s\n" "$line"
                done
            }
        }

        C_command() { eval cat '"$file"' $hide_empty $numerate_lines $use_pager; }
    ;;

    *)
        C_command() {
            [[ "$file" =~ .+/ ]] && {
                dir="$BASH_REMATCH"
                [[ -e "$dir" ]] || mkdir -p -- "$dir" || continue 1
            }

            [[ -e "$file" ]] \
                || printf '%s\n\n' "#!${BIN%%/}/$default_SHELL" >"$file"

            _scripts=$(Ext=1 esc_regex "${KOSMOS_scripts%%/}")

            grep -Eqm1 "^$_scripts/($ignore_files)$" <<<"$file" \
                || chmod -- "$chmod" "$file"

            "${EDITOR[@]}" "$file"
        }
esac

for (( c=0; c<${#ARGS[*]}; c++ )); do
    file="${ARGS[c]}"

    [[ "$file" == */ ]] && {
        printf "\n\t$RED2%s$noCOL2\n" "Wrong filename \"$(esc "$file")\"." >&2
        continue 1
    }

    if [[ "$file" == /* || "$file" == ./* ]]; then
        file=$(realpath -m "$file")
        C_command
    else
        cd -- "$KOSMOS_scripts" || exit
        _file=$(esc_regex "$file")
        find=$(find -L -O3 \( -type f -o -type l \) -a \( -name "$_file" -o -wholename "./$_file$" \) 2>"$DEV/null")

        [[ "$find" ]] \
            && file=$(sort --parallel="${JOBS:-1}" -V <<<"$find" | tail -1)

        file=$(realpath -m -- "$file")
        C_command
    fi
done

ну возможно где у меня несколько пустых строк - перебор. на мой взгляд вообще без пустых менее читаемо.

Вообще без пустых строк менее читаемо. С пустыми строками там, где они отделяют отдельные по смыслу фрагменты, как в моём примере — более.

то происходит в условиях case, без отступа, что тоже путает.

Да я просто убрал все эти бестолковые 2-4 пустые строки и проставил function. Понятно, что у логических блоков - 1 пробел, между блоками - 2 пробела

Да я просто убрал все эти бестолковые 2-4 пустые строки и проставил function.

Не только. Вот этой дичи у ТС нет:

	 if [[ "$file" =~ .+/ ]] && {
	        dir="$BASH_REMATCH"
	        [[ -e "$dir" ]] || mkdir -p -- "$dir" || continue 1
	    }

К ней у меня и был основной вопрос.

Тут уж или так:

            [[ "$file" =~ .+/ ]] && {
	        dir="$BASH_REMATCH"
	        [[ -e "$dir" ]] || mkdir -p -- "$dir" || continue 1
	    }

Или так:

            if [[ "$file" =~ .+/ ]]; then
	        dir="$BASH_REMATCH"
	        [[ -e "$dir" ]] || mkdir -p -- "$dir" || continue 1
	    fi

А твой вариант — это какой-то монстр Франкенштейна.

Мне, кстати, первый больше нравится. if без else в шелле не нужен.

делается одной командой.

Прогони через форматер баша

А так-то этот ганстастайл 146% взят из CRUX’a. Смысл в таком стиле нулевой. Из-за этого скрипт в 30 строк разливается на 130 строк. К тому же ты бы перепроверил всё своё барахлишко. А то там куча всего, что не имеет смысла. awk –> ak aw. И там такого навскидку несколько штук

Выкладывая это, ты же в первую очередь хотел получить обратную связь по наработкам? Ну вот тебе и обратная связь

Вот этот стиль - это кулхацкерский стиль

[[ "$file" =~ .+/ ]] && {
    dir="$BASH_REMATCH"
    [[ -e "$dir" ]] || mkdir -p -- "$dir" || continue 1
}

Визуально это:

if [[ "$file" =~ .+/ ]]; then
    dir="$BASH_REMATCH"
    
    if [[ -e "$dir" ]]; then
        mkdir -p -- "$dir" 
    else
        continue 1
    fi
fi

выглядит лучше, чем вот это:

if [[ "$file" =~ .+/ ]]; then
    dir="$BASH_REMATCH"
    [[ -e "$dir" ]] || mkdir -p -- "$dir" || continue 1
fi

Потому что надо всматриваться, к чему относится ||. Оно является дополнительным условием ‘или’ или является заменителем else

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

Мой комментарий был о том, что у тебя в примере и не то и не другое, а некорректный бред — if без then и fi.

Мой комментарий был о том, что у тебя в примере и не то и не другое, а некорректный бред — if без then и fi.

Ну да, я там поставил if и понял, что всю эту синтаксическую конструкцию надо разбирать, чтобы понять, как правильно все эти if else fi выставить. Плюнул и пошел чай пить. Это занятие полезней, чем разбирать всё эти CRUX-based конструкции

Не успел исправить предыдущее:

P.S. Хотя нет, смысл спорить вижу. Тут логика разная. В оригинале варианте continue вызывается, если mkdir завершился с ошибкой, в твоём — нет.

P.P.S. И вообще всё наоборот — у тебя mkdir вызывается, если каталог уже существует. А надо ровно наоборот. Этим первый вариант и лучше — сразу всё видно и не возникает таких вот ошибок нелепых. Спасибо за наглядную демонстрацию :)

Тут логика разная. В оригинале варианте continue вызывается, если mkdir завершился с ошибкой, в твоём — нет.

No problemA:

if [[ "$file" =~ .+/ ]]; then
    dir="$BASH_REMATCH"
    
    if [[ -e "$dir" ]]; then
        mkdir -p -- "$dir" || continue 1
    fi
fi

Зачем мне вникать в логику работы этого куска кода? Я синтаксически вижу фигню. Что это неподдерживаемый стиль написания. Через месяц он сам заходит в это и пол часа вникает «что оно там делает?». Я это говорю из-за того, что весь свой обвес ~10k строк раза три рефакторил. На третий раз приходит понимание, что так, как в KOSMOS писать можно и оно работает. Но переписывать это рано или поздно надо будет

Всё ровно наоборот. Там сразу всё видно, а в твоём варианте ты ОПЯТЬ повторил ту же ошибку и создаёшь существующий каталог (а несущшествующий не создаёшь) — то есть, код не имеет смысла вообще, его можно полностью удалить.

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

Да ёлы-палы. Ну пусть оно так работает в оригинале. Зачем мне это нужно? Я указал на синтаксис. Зачем мне знать как оно там правильно работает?

if [[ ! -e "$dir" ]]; then
    mkdir -p -- "$dir" || continue 1
fi

или так:

if [[ ! -e "$dir" ]]; then
    mkdir -p -- "$dir" 
else
    continue 1
fi

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

Ну вот теперь, с четвёртого раза, правильно.

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

То есть, ты сейчас всеми вот этими экзерцизами показал, чем твой подход хуже — сложнее заметить ошибку. Большое спасибо за наглядную демонстрацию, убедил. Ровно в противоположном тому, в чём хотел, правда. Но я и правда стал на это чуть иначе смотреть. Казалось, совсем вкусовщина, но нет, всё же есть разница — было лучше. :)

upd:

который знают все

Нет. Если человек не знает простых и натуральных для шелла конструкций, то и этот сахар, вероятно, не знает. Первые нужнее.

и визуально его легче читать

Точно нет. И ты это наглядно продемонстрировал на своём примере.

Смею предположить, что есть корреляция между ганстастайл скриптами и конкретным бардаком, который в этом обвесе творится

if [[ ! -e "$dir" ]]; then
    mkdir -p -- "$dir" 
else
    continue 1
fi

Ты решил поучаствовать в соревновании «как написать путаннее и сложнее по максимуму»?

Конкретно этот код (если бы нужно было такое поведение) нормально пишется так:

[[ -e "$dir" ]] || continue 1
mkdir -p -- "$dir"

Ну или если в детстве || покусал, то так

if [[ -e "$dir" ]]; then
    continue 1
fi

mkdir -p -- "$dir"

Точно нет. И ты это наглядно продемонстрировал на своём примере.

1. я пятый раз говорю, что я не вникал в работу скрипта
2. если бы ганстастайл баша был визуально лучше if elif else fi, то в других языках эту конструкцию не использовали бы. Почему она в баше до сих пор присутствует? Обратная совместимость с каким-нибудь sh и всякими шелами bsd
3. если конкретно тебе это удобней - используй, но не утверждай, что это эффективней

Или просто так:

mkdir -p -- "$dir"

Потому что ты его в любом случае должен создать. И все проверки не нужны т.к эту проверку реализует сам mkdir

я пятый раз говорю, что я не вникал в работу скрипта

Я тоже. Только в тот фрагмент, который мы обсуждали. Но ты в четырёх строках умудрился всё сломать.

И нет, я не хочу тебя унизить и сказать, что ты ничего не умеешь. Наоборот. Это просто наглядная демонстрация, к чему приводит избыток сахара там, где он нафиг не нужен.

если бы ганстастайл баша был визуально лучше if elif else fi, то в других языках эту конструкцию не использовали бы.

Он не всегда лучше. Но часто. В данном случае все эти ifы — это какие-то ненужные понты. Но в коде со сложной логикой, особенно с else и особенно ещё и с elifами, и/или где в каждой ветке куча кода, они полезны.

Но другие языки при этом иррелевантны. Мы сейчас о шелл-скриптах.

Почему она в баше до сих пор присутствует?

Потому что в ней есть смысл. Просто без пихания везде и всюду как карго-культ.

Хотя в баше в принципе много чего присуствует… В том числе просто по историческим причинам. Это не самый лучший пример дизайна.

если конкретно тебе это удобней - используй, но не утверждай, что это эффективней

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

Так что я изначально согласен «не утверждать». Если ты в свою очередь больше не утверждаешь, что твой вариант лучше :)

Или просто так:

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

То, что я не правильно повторил логику работы оригинального скрипта не отменяет этого KOSMOS -- сборка комфортненьких shell-скриптов, функций и конфигов системы (комментарий)

Но другие языки при этом иррелевантны. Мы сейчас о шелл-скриптах.

Вот поэтому везде шелл-скрипты и выбрасывают и говорят о них так: если вам нужно что-то по-сложней hello world, то возьмите нормальный ЯП. Я же пытаюсь использовать shell-скрипты так, чтобы их можно было эксплуатировать и не использовать какой-нибудь пайтон там, где можно обойтись без него

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

Но мы это, конечно же, проверять не будем :)

Ну так-то я в целом согласен с этим посылом. Если скрипт достаточно сложный, лучше взять нормальный ЯП, а не упарываться шеллом. Шелл это в первую очередь клей для вызова сторонних программ + простая логика вроде завершения с ошибкой, или успешно, пайпов, ну и подобного. Сложную логику на нём писать не очень.

Но тут, как всегда в таких «философских» вопросах всё в итоге сводится к тому, где кончается простое и начинается сложное. Эту грань каждый нащупывает для себя сам опытным путём. Как-то формализовать её, наверное, невозможно. Точнее, формализовать-то каждый второй, кто уже нащупал, сможет, но его критерии не совпадут с критериями других в итоге :)

Но мы это, конечно же, проверять не будем :)

Ага :)

Там вообще специфичный стиль кода очень. Этот continue вызывается вне цикла… Но в теле функции… которая вызывается в цикле… и при этом ещё и сама функция определена по-разному в зависимости от условия в case… спасибо хоть не в другом файле, а то я бы начал думать, что там где-то в конце игла, а в ней — смерть кощеева.

О таком я и говорил выше — что именно сама логика в этом «космосе» какая-то переусложнённая, и непонятно зачем так писать (а местами вообще можно было вместо нескольких дюжин строк кода тупо одним алиасом обойтись).

P.S. Конкретно в данном случае под «стилем кода» я имею в виду не оформление/форматирование/сахар.

всё в итоге сводится к тому, где кончается простое и начинается сложное

Да-да, один считает сложным и пишет 100 строк на python’e, а другой 20к строк на баше пишет и считает это простым и неделями пытается обойти ограничения баша, в итоге всё переусложняет

я как-то создал больше 10000 алиасов

Сдуру, как говорится, можно и нефритовый стержень сломать.

(этот пост написан чисто ради посмотреть на свои звёзды)

О таком я и говорил выше — что именно сама логика в этом «космосе» какая-то переусложнённая, и непонятно зачем так писать (а местами вообще можно было вместо нескольких дюжин строк кода тупо одним алиасом обойтись).

Так и я об том же. Зачем вникать в эту писанину? :). Смысл в этом какой?