Uruchamianie skryptu w tle skryptem - bash.

[Michał Czarkowski]

Mam mały problem – próbuję uruchomić skrypt basha w tle skryptem. Kiedyś działało, co prawda
w innej dystrybucji, dzisiaj nie chce działać.
Oba skrypty są w tym samym katologu.
Przykładowe skrypty:
skrypt1:

#!/bin/bash
cd /do/tego/samego/katalogu
./skrypt2 &
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
skrypt2:
#!/bin/bash

unbuffer -p cat /dev/jakieś_urządzenie | unbuffer -p /usr/bin/grep "cośtam" | while read dane;
do
echo $dane >> gdzieśtam.txt
done

Skrypt2 da się uruchomić i działa dobrze z wiersza poleceń. Uruchomiony ręcznie z "&" na końcu
„uruchamia się, ale nie działa”, po naciśnieciu enter zostaje zatrzymany… Pomocy :-D

[Michał Czarkowski]

W dniu Thu, 19 Jul 2018 05:37:50 +0000, użytkownik Michał Czarkowski
napisał:

Nie ma za to problemu uruchomieniem skryptem jakiegoś skompilowanego programu…
Czy ktoś ma pomysł jak rozwiązać problem?

[marrgol]

Tak na szybko: po co ta pętla? I cat?

grep "cośtam" /dev/jakieś_urządzenie >> gdzieśtam.txt

robi to samo…


--
mrg

[Michał Czarkowski]

…i zajmuje mniej miejsca. :-D
Nie jestem informatykiem. Takie coś jak to, co przedstawiłem wcześniej,
powstało w wyniku, jeśli dobrze pamiętam, dopisywania kolejnych poleceń po wcześniejszym
sprawdzeniu, że poprzednie jednak działają. :-D, zmian założeń, koncepcji :-D
i niewiedzą o buforowaniu danych, o którym zresztą dowiedziałem się, jeśli się nie mylę,
na tej grupie.
Skrypty znowu działają. Podpowiedź znalazłem w manualu unbuffera. Teraz skrypt2 wygląda tak:

skrypt2:
#!/bin/bash

unbuffer cat /dev/jakieś_urządzenie | unbuffer -p /usr/bin/grep "cośtam" | while read dane;

do
echo $dane >> gdzieśtam.txt
done

nie ma "-p" po pierwszym unbuffer, jakiś czas temu poprzednia wersja skryptu działała dobrze, ale po licznych
aktualizacjach systemu przestała. :-D. Cieszę się, że odpisano mi na grupie, pozdrawiam.

[marrgol]

On 2018-07-20 at 03:45, Michał Czarkowski wrote:
>>> skrypt2:
>>> #!/bin/bash
>>>
>>> unbuffer -p cat /dev/jakieś_urządzenie | unbuffer -p /usr/bin/grep "cośtam" | while read dane;
>>> do
>>> echo $dane >> gdzieśtam.txt
>>> done
>>>

>>> […]

>>
>> Tak na szybko: po co ta pętla? I cat?
>>
>> grep "cośtam" /dev/jakieś_urządzenie >> gdzieśtam.txt
>>
>> robi to samo…
>
> …i zajmuje mniej miejsca. :-D

Przede wszystkim może być wielokrotnie szybsze. Zrobiłem sobie
eksperyment z plikem wejściowym z 3,4mln linii -- twoja wersja
wykonywała się kilka sekund, moja kilkadziesiąt milisekund,
ponad 50x szybciej. :-)


--
mrg

[Michał Czarkowski]

W jaki sposób mógłbym sprawdzić czas wykonywania się skryptu, jak to zrobiłeś?
Nauczyłbym się czegoś nowego. Urządzenie podpięte do systemu wysyła niewielką
ilość danych co sekundę, mniej więcej. Prędkość zastosowanego przeze mnie
rozwiązania jest bardziej :-D niż wystarczająca. Zresztą skrypt wygląda juz inaczej,
w pętli „while” mam „case in” i kilka warunków, skrypt tworzy również prosty kod html,
zapisuje do plików i robi to wystarczająco szybko, by odczytać ponownie dane z podłączonego
urządzenia. Użyty do tego komputer, choć nie najnowszy, jest wystarczająco wydajny do
zrealizowania tego zadania. :-D
Napisz mi w jaki sposób przeprowadziłeś pomiar czasu wykonywania się skryptów,
zawsze z chęcią nauczę się czegoś nowego i pożytecznego.
Pewnie zoptymalizuję skrypt w proponowany przez Ciebie sposób używając
„grep "cośtam" /dev/jakieś_urządzenie” na początku skryptu.

[marrgol]

On 2018-07-20 at 23:31, Michał Czarkowski wrote:
> W jaki sposób mógłbym sprawdzić czas wykonywania się skryptu, jak to zrobiłeś?

Uruchamiając skrypt (albo ogólnie program) za pośrednictwem polecenia
'time' (wbudowane polecenie basha albo „wolnostojące” /usr/bin/time),
czyli np.:

time ./skrypt

> Urządzenie podpięte do systemu wysyła niewielką
> ilość danych co sekundę, mniej więcej. Prędkość zastosowanego przeze mnie
> rozwiązania jest bardziej :-D niż wystarczająca. Zresztą skrypt wygląda juz inaczej,> w pętli „while” mam „case in” i kilka warunków, skrypt tworzy również
prosty kod html,
> zapisuje do plików i robi to wystarczająco szybko, by odczytać ponownie dane z podłączonego
> urządzenia. Użyty do tego komputer, choć nie najnowszy, jest wystarczająco wydajny do
> zrealizowania tego zadania. :-D

No proszę, nawet przemknęło mi przez głowę, że źródło danych musi być
powolne, a plik wyjściowy monitorowany „na żywo”, bo nie bardzo widzę
inne uzasadnienie zastosowania 'unbuffer' przy przekierowywaniu wyniku
do pliku. :-) Oczywiście obróbka danych wyjściowych uzasadnia
tę pętlę, do której wcześniej miałem zastrzeżenia…

> Pewnie zoptymalizuję skrypt w proponowany przez Ciebie sposób używając
> „grep "cośtam" /dev/jakieś_urządzenie” na początku skryptu.

Nie zaszkodzi (oczywiście w Twoim przypadku 'unbuffer grep' albo,
dla urozmaicenia, 'stdbuf -oL grep', albo 'grep --line-buffered')
-- panuje opinia, że dobrą praktyką jest unikanie UUoC (useless use
of cat) i choć czasem może się to wydawać mniej przejrzyste to zawsze
to jeden (sub)shell i jedno polecenie mniej do uruchomienia (czyli
oszczędność zasobów nie najnowszego komputera ;-) ). Ale u Ciebie
jakiegoś znaczącego zysku z tej optymalizacji pewnie nie będzie…


--
mrg

[Michał Czarkowski]

W dniu Sat, 21 Jul 2018 02:30:02 +0200, użytkownik marrgol napisał:

> On 2018-07-20 at 23:31, Michał Czarkowski wrote:
>> W jaki sposób mógłbym sprawdzić czas wykonywania się skryptu, jak to zrobiłeś?
>
> Uruchamiając skrypt (albo ogólnie program) za pośrednictwem polecenia
> 'time' (wbudowane polecenie basha albo „wolnostojące” /usr/bin/time),
> czyli np.:
>
> time ./skrypt
>
>> Urządzenie podpięte do systemu wysyła niewielką
>> ilość danych co sekundę, mniej więcej. Prędkość zastosowanego przeze mnie
>> rozwiązania jest bardziej :-D niż wystarczająca. Zresztą skrypt wygląda juz inaczej,> w pętli „while” mam „case in” i kilka warunków, skrypt tworzy również
> prosty kod html,
>> zapisuje do plików i robi to wystarczająco szybko, by odczytać ponownie dane z podłączonego
>> urządzenia. Użyty do tego komputer, choć nie najnowszy, jest wystarczająco wydajny do
>> zrealizowania tego zadania. :-D
>
> No proszę, nawet przemknęło mi przez głowę, że źródło danych musi być
> powolne, a plik wyjściowy monitorowany „na żywo”, bo nie bardzo widzę
> inne uzasadnienie zastosowania 'unbuffer' przy przekierowywaniu wyniku
> do pliku. :-) Oczywiście obróbka danych wyjściowych uzasadnia
> tę pętlę, do której wcześniej miałem zastrzeżenia…

Tak właśnie się dzieje.

>
>> Pewnie zoptymalizuję skrypt w proponowany przez Ciebie sposób używając
>> „grep "cośtam" /dev/jakieś_urządzenie” na początku skryptu.
>
> Nie zaszkodzi (oczywiście w Twoim przypadku 'unbuffer grep' albo,
> dla urozmaicenia, 'stdbuf -oL grep', albo 'grep --line-buffered')
> -- panuje opinia, że dobrą praktyką jest unikanie UUoC (useless use
> of cat) i choć czasem może się to wydawać mniej przejrzyste to zawsze
> to jeden (sub)shell i jedno polecenie mniej do uruchomienia (czyli
> oszczędność zasobów nie najnowszego komputera ;-) ). Ale u Ciebie
> jakiegoś znaczącego zysku z tej optymalizacji pewnie nie będzie…

Też tak myślę, że znaczącego, zauważalnego zysku nie będzie, no i nie będę
musiał wymyślać jak przerobić ten już przerobiony niechlujny skrypt i jego
kolegów tak by znów działały. Komp, mimo że nie najnowszy daje radę :-D.
Dziękuję, że poświęciłeś mi trochę czasu i uwagi oraz za to, że
dowiedziałem się czegoś nowego. Zazwyczaj staram się samemu rozwiązać
problem, ale tym razem nic w sieci nie znalazłem, a podpowiedź w manualu
unbuffer'a dostrzegłem już po wysłaniu posta na grupę. To do następnego razu!
Pozdrawiam.