LINUX.ORG.RU

Скрипт на bash с использованием whiptail

 , ,


0

1

В общем суть в чем, хочу написать маленький скрипт, который с использованием whiptail показывал жесткие диски. Накатал примерно такое:

#!/bin/bash

rm -f /tmp/tempfile
touch /tmp/tempfile
kdisk=$[$(fdisk -l | grep "Диск" | awk 'END {print NR}')+1]
nr=1
until [ $kdisk -eq $nr ]
do
disk=$(fdisk -l | grep "Диск" | awk NR==$nr)
echo \\ \"$disk\" \" \" >> /tmp/tempfile
nr=$[$nr+1]
done
k=`cat "/tmp/tempfile" | tr -s '\r\n' ' '`
OPTION=$(whiptail --title "test" --menu "test menu" 15 60 4 $k 3>&1 1>&2 2>&3)
exitstatus=$?
if [ $exitstatus = 0 ]; then
	echo $OPTION
else
	echo "fail"
fi
И все бы хорошо, да вот только whiptail мне показывает какую-то дикую ересь. А конкретно, он как-то неправильно обрабатывает переменную k. При этом если руками подставить вместо $k вывод полученный от cat «/tmp/tempfile» | tr -s '\r\n' ' ' , то все нормально отображает. И подскажите почему скрипт в centos 6 запускается, а вот в последней ubuntu он не работает.

Ответ на: комментарий от d_a

с точки зрения ядра globstar тоже ересь, к тому же повторяет функциональность find, да и то не дотягивает

anonymous
()
Ответ на: комментарий от anonymous

с точки зрения ядра globstar тоже ересь

А я вот почему-то думаю, ему в самый раз.

к тому же повторяет функциональность find, да и то не дотягивает

Зато во многих случаях экономится 1 форк, 1 труба, убирается бойлерплейт связанный с разбором потока от find (а именно read и -print0) и кто-то не прострелит себе все ноги, разбирая поток от find неправильно. Это ли не бесценно?

d_a ★★★★★
()
Ответ на: комментарий от d_a

А я вот почему-то думаю, ему в самый раз.

ой, не globstar, а extglob, переизобретение башем регулярных выражений в общем

Зато во многих случаях экономится 1 форк, 1 труба, убирается бойлерплейт связанный с разбором потока от find (а именно read и -print0)

ваш же **/*.c совпадет с каталогом foo.c

и кто-то не прострелит себе все ноги, разбирая поток от find неправильно. Это ли не бесценно?

все равно ведь придется

anonymous
()
Ответ на: комментарий от anonymous

Да, всё так. В общем, подытоживая, я действительно считаю что массивы (обычные, "старые") решают реальные проблемы shell, давая замену вредным антипаттернам, в то время как у "новых" высокоуровневых конструкций (словари, какие-то воображаемые структуры данных на ссылках, с которых всё началось) я таких задач не вижу. (Может они есть, конечно, но пока примеров никто не привел. А просто так, шоб было? Ну вы поняли.)

d_a ★★★★★
()
Ответ на: комментарий от d_a

Зато во многих случаях экономится 1 форк, 1 труба

Зато ваш скрипт не стартует, пока всё дерево не будет обойдено. И требуется O(n) памяти.

и кто-то не прострелит себе все ноги

Очень много я видел скриптов, где for i in * заменили на list=*; ...; for i in $list и вроде работало :), а потом вдруг перестало (на файликах с пробелами, естественно). У людей, знающих про find -print0 в среднем больше целых ног, чем у использующих * :)

Я использую оба способа, по обстоятельствам. Но при сомнениях - пайпы.

legolegs ★★★★★
()
Последнее исправление: legolegs (всего исправлений: 1)
Ответ на: комментарий от legolegs

list=*; ...; for i in $list

А это у вас и не массив. Это вообще фигня какая-то :) Наверное, вы имели в виду list=(*); for i in "${list[@]}"; do ...; done?

d_a ★★★★★
()
Ответ на: комментарий от d_a

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

legolegs ★★★★★
()
Ответ на: комментарий от legolegs
Ну и for i in * так-то тоже неправильно изначально, на пустой директории звёздочка в цикл угодит. Тогда уж for i in ./*
d_a ★★★★★
()
Ответ на: комментарий от d_a

Поэтому я и топлю за find | xargs. Там думать надо меньше. Даже без print0 можно жить.

legolegs ★★★★★
()
Последнее исправление: legolegs (всего исправлений: 1)
Ответ на: комментарий от d_a

for i in ./*

Всё равно не помогает что-то. Ладно, это я видимо уже косячу, убедили, find > glob :)

d_a ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.