Bu, basit bir yapılandırma bilgisiyse, A veya B'den okunabilecek yapılandırma bilgilerine sahip olduğunuza benzer, daha sonra kullanılarak hem A'dan hem de B'den alınan üçüncü bir C dosyasında belirtilmelidir. ./C mekanizması.
A'dan B'yi aramaya çalışıyorsanız, B değişkenindeki bir değişkeni B olarak ayarlayın ve sonra bu değeri A'da okuyun, ardından ./ B standardını kullanıyorsanız, tüm değişkenler B'nin çağrılmasında belirlenenler, A ortamına geri kopyalanmaz.
Komut dosyaları arasında 'değişkenleri paylaşmanın' en mantıklı yolu, çağrılan komut dosyasının A'nın geçici bir dosyada kullanması gereken değişkenleri çıkarması ve ardından bunu A'dan B'ye göndermesinin sonuca varmasıdır. Daha karmaşık yollar, B'nin değişkenlerin, örn. B içeriyorsa:
#!/bin/bash -p
echo var=22
ve sonra A’da:
output=$(./B)
eval $output
echo $var
22 çıktısını alırdım. Bu, doğru olmak için zor ve sadece komut dosyaları arasında aktarılan değişkenlerin kısa bir listesi için güvenilmelidir.
Değişkenleri paylaşmak için komut dosyalarının elde edilmesinin gerçek yolu, bunların yalnızca işlevleri içermesini sağlamaktır ve A ve B'deki işlevleri çağırdıktan sonra çağrıştıran bir ana komut dosyasına sahiptir.
#!/bin/bash -p
. ./A
. ./B
do_a_stuff
echo $shared_variable
do_b_stuff
echo $shared_variable
A'da kodun B'de koduna bağlı olması, daha sonra bunları kullanarak, bunlar arasında paylaşılan tek bir ad alanıyla sonuçlanırsınız, böylece B'deki A ve A'dan B'ye işlevler çağırabilirsiniz. işlevsel bir hiyerarşinin ihlali ve zayıf kodlama olarak kabul edilir).