Daha büyük komut dosyasını birden çok komut dosyasına bölmek ve bunları ana komut dosyasında kaynaklamak yaygın mıdır?

Şu anda daha büyük bir Bash senaryosu geliştiriyorum (bu benim açık kaynaklı bir projem) ve karışıklık yaratmaya başlıyor. Mantığı fonksiyonlara böldüm, yerel değişkenleri kullanabildiğim ve sadece birkaç genel değişken tanımladığım. Yine de bakımı oldukça zorlaşıyor.

Komut dosyasını çoklu komut dosyalarına bölmeyi ve ana komut dosyasımda (diğer dillerdeki içe aktarma işlemlerine benzer şekilde) kaynak yapmayı düşündüm.

Ama bunun uygulanabilir bir yaklaşım olup olmadığını merak ediyorum. İlk olarak, çok sayıda komut dosyası oluşturmak, komut dosyasının yürütme süresini ciddi şekilde yavaşlatabilir ve ikincisi, dağıtımı zorlaştırır.

Öyleyse, bu iyi bir yaklaşım mı ve diğer (Açık Kaynak) projeler de aynı şekilde mi çalışıyor?

Evet, yaygın bir uygulamadır. Örneğin, Unix'in ilk günlerinde, sistemi önyükleme aşamalarında çok kullanıcılı çalışmaya yönlendiren sorumlu kabuk kodu tek bir dosyaydı /etc/rc,. Günümüzde önyükleme işlemi, merkezi konumlardan ihtiyaç duyulan ortak fonksiyonlar ve değişkenlerle, fonksiyonlara göre ayrılmış birçok kabuk betiği tarafından kontrol edilmektedir. Linux dağıtımları, Mac'ler, BSD'ler, hepsi bu yaklaşımı farklı derecelerde benimsemiştir.

Shell bu noktada iş için doğru araç mı? Kodun aşılmasıyla ilgili sorunları çözen bir geliştirici olarak size bir yeniden yazmanın düşünülmemesi gerektiğini söyleyebilirim, bunun yerine parçaları ölçeklendirmek için daha uygun bir parçaya ayırmayı düşünerek uygulamanızı büyütmek için - belki de piton veya yakut veya perl ?

Shell yardımcı bir dildir - bir betik dilidir - bu yüzden onu bu boyutlarda büyütmek zor olacaktır.

Bakımınızı kolaylaştırırsa, her ikisine de sahip olabilirsiniz. Kolayca saklayabilmeniz için mantıksal parçalara bölün, ardından dağıtmak için hepsini bir araya getirmek için bir Makefile yazın (örn.) Yazmak için işlevleri hızlı bir şekilde eklemek için bazı hızlı komut dosyaları yazabilirsiniz. sourcehat veya sadece bu gibi önemsiz bir şey yapmak (gibi, bu yeniden tabify gerekecek makesekmeleri gerekir):

all: myscript

myscript: includes/* body/*
    cat $^ > "$@" || (rm -f "$@"; exit 1)

Daha sonra bir "kaynak" versiyonuna (düzenleme için kullanılır) ve "ikili" versiyonuna (önemsiz kurulum için kullanılır) sahipsin.

Anlattığınız gibi bir senaryo bozulabilir - hemen hemen her şey yapılabilir. “İyi yaklaşımın” büyük senaryoyu bölümlere ayırmak, IPC mekanizmaları aracılığıyla iletişim kurmak için bölümlerinin ayrı bir süreç olarak nerede çalıştırılabileceğini bulmak olduğunu söyleyebilirim.

Bunun ötesinde, bir kabuk betiği için, onu tek bir dosya olarak paketlerdim. Söylediğiniz gibi dağıtımı zorlaştırıyor: ya 'kütüphane' komut dosyalarının nerede olduğunu bilmek zorundasınız - kabuk komut dosyaları için iyi bir standart yok - ya da yollarını doğru bir şekilde ayarlamak için kullanıcıya güveniyorsunuz.

Bunları sizin için idare eden, dosyaları açarak, uygun yere koyarak export PROGRAMDIR=$HOME/lib/PROGRAM, ~ / .bashrc dosyasına benzer bir şey eklemesini söyleyen bir yükleme programı dağıtabilirsiniz . Ardından, $PROGRAMDIRayarlanmamışsa veya beklediğiniz dosyaları içermiyorsa ana program başarısız olabilir .

Diğer senaryoları doldurmanın yükü kadar endişelenmem. Tepegöz gerçekten sadece bir dosya açıyor; metnin işlenmesi, özellikle işlev tanımları ise aynıdır.

Yaygın uygulama veya değil, bir dizi ihracattan başka bir şey tedarik etmenin iyi bir fikir olduğunu sanmıyorum. Kaynak kodu kullanarak kod çalıştırmanın sadece kafa karıştırıcı olduğunu ve yeniden kullanımı sınırladığını biliyorum, çünkü çevresel ve diğer değişken ayarları kaynak kodunu kaynak koduna oldukça bağımlı hale getiriyor.

Uygulamanızı daha küçük, kendi kendine yeten komut dosyalarına bölmek için daha iyi durumdasınız, ardından bunları bir dizi komut olarak uygulayın. Bu, her bir komut istemi arasında kendi içerdiği her bir betiği etkileşimli bir kabukta çalıştırabilir, dosyaları, günlükleri vb. İnceleyebilir. Tek, büyük uygulama komut dosyanız hata ayıklamayı tamamladıktan sonra yalnızca bir dizi komut çalıştıran daha basit bir kontrol komut dosyasına dönüşür.

Bir grup küçük, kendi kendine yeten komut dosyası, kurulumu zor bir problemle karşılaşır.

Senaryoları kaynak göstermenin bir alternatifi, basitçe onları argümanlarla çağırmaktır. İşlevselliğinizin çoğunu kabuk işlevlerine zaten ayırdıysanız, muhtemelen bunu zaten yapabilmeniz için oldukça yakınsınızdır. Aşağıdaki Bash pasajı, bir komut dosyasında belirtilen herhangi bir işlevin alt komut olarak kullanılmasına izin verir:

if [[ ${1:-} ]] && declare -F | cut -d' ' -f3 | fgrep -qx -- "${1:-}"
then "$@"
else main "$@" # Try the main function if args don't match a declaration.
fi

Olmamasının nedeni sourceçevre ve seçenek kirliliğinden kaçınmaktır.

İşte benim büyük bir bash betiğinin birden fazla dosyaya nasıl bölündüğü ve daha sonra sonuçtaki bir betiğe nasıl yerleştirilebileceğine dair bir örnek: https://github.com/zinovyev/bash-project

Bunun için bir kullanıyorum Makefile:

TARGET_FILE = "target.sh"
PRJ_SRC = "${PWD}/src/main.sh"
PRJ_LIB = $(shell ls -d ${PWD}/lib/*) # All files from ./lib

export PRJ_LIB

SHELL := /bin/env bash
all: define_main add_dependencies invoke_main

define_main:
    echo -e "#!/usr/bin/env bash\n" > ${TARGET_FILE}
    echo -e "function main() {\n" >> ${TARGET_FILE}
    cat "${PRJ_SRC}" | sed -e 's/^/  /g' >> ${TARGET_FILE}
    echo -e "\n}\n" >> ${TARGET_FILE}

invoke_main:
    echo "main \$$@" >> ${TARGET_FILE}

add_dependencies:
    for filename in $${PRJ_LIB[*]}; do cat $${filename} >> ${TARGET_FILE}; echo >> ${TARGET_FILE}; done