Комментарии 4
Не очень понятен сценарий использования инженером ТП. Возможно, проще было бы оформить в виде мастера, когда все варианты и подстановки делаются уже после запуска, внутри баш-скрипта, а не на его входе, в оболочке. Типа того, как работают git init или npm init.
Задачу манипуляции с LUN успешно решают примерно все эксплуатанты ДЦ. Нюансы, традиционно, в контроле сложности. Кому-то хватает коммерческих вариантов, типа vSAN от vmWare. Кто-то сразу кидается делать GUI.
В моём сценарии, абстракции добавляются по мере необходимости. Потому что "внутренние" задачи являются расходной частью бизнеса, ресурсы на них выделяются соответственно.
Есть "физический" слой, linux+multipath+qemu(libvirt). На первых порах его хватает, раскидать конфиги можно и каким-нибудь ansible/pdsh. И там же тяп-ляп пересканировать SAN.
Когда понятно что "всё", есть смысл обернуть конфигурацию каким-нибудь DSL. И организовать транспорт поприличнее, с контролем compliance. Это кардинально снизит "ошибки оператора" и позволит дотянуть до следующего "порога" (если бизнес не развалится).
Когда опять упёрлись (тратить ресурсы дорогих инженеров при наличии дешёвых стало накладно), оборачиваем имеющееся в очередную абстракцию. Здесь уже́ есть смысл потратить время на разложение операций по базисным функциям, обеспечить конкурентные изменения и контроль выпуска. GIT, так-то, был ещё на предыдущем шаге. Но вот здесь он прямо-таки играет всеми красками, да.
А вот вместо того чтобы тратить время на написание кастомного шелла, я его потратил на вкручивание json-интерфейсов ко всем модулям. На па́ру с обеспечением функциональности автодополнения/автозаполнения везде где это возможно.
Когда/если встанет задача обернуть всё в GUI, программисту останется прокинуть сдизайненные (вот тут боюсь что им же) "окошки" к готовым и документированным интерфейсам.
Но это всё лирика. Системотехнике есть и без меня кому учить. Я просто иногда стараюсь показать интересные (ПММ) случаи.
А в данном случае интересно как раз практическое применение bash-completion. Не на "всю катушку", но около того. При наличии как позиционных, так и "свободных" аргументов, включая "--ключ=значение".
Побуждения тут вполне корыстные. Когда очередной коллега попытается отпетлять от организации подсказок в CLI с аргументацией "отвяжись, не умею я в bash-completion", теперь можно ткнуть в ссылку. "Ну вот же «рыба», с разъяснениями."
Написать нормальный bash completion это да, задача не из простых. Я сам недавно такое проходил, почитал разные статьи, но там всё примитивно как правило и сложные случаи с под командами и их флагами не рассказывается как сделать. В итоге остановился на конечном автомате. У вас я вижу много ифчиков, возможно с автоматом и состоянием их количество подсократится. Вот пример моего https://github.com/navrocky/dcw/blob/master/completion.bash
Да, так идеологически правильнее.
На накладные расходы (в статье — достаточно "короткие" структуры, зато "дорогие" внешние вызовы) это заметно не повлияет. Лучше делать так, как более "читаемо".
В описанном случае проблемой было "да как это вообще сделать-то?!". Вышло вот так.
После получения понимания "как это работает", ничто больше не заставляет писа́ть сложные completion'ы на bash. Но, как всегда, есть нюанс: сложность в этом месте указывает на дефекты в проектировании интерфейса.
Публикации
Bash-completion: как сделать удобно в CLI