Wpisy z tagiem: bash

Zdarza mi się używać techniki 'skrypt, który wygeneruje skrypt, który,... ' i dość często z wykorzystaniem basha. Czasem rodzi to drobne problemy,
np. skrypt generujemy jako userX, a wykonujemy jako userY, niektóre zmienne środowiskowe zostały rozwiązane na podstawie środowiska userX.

1. Przykład#1 - zmienne środowiskowe są rozwijane

cat<<-FOOBAR
  echo Hello $USER
FOOBAR

1. Przykład#2 - białe znaki (tu spacja) za FOOBAR, skutecznie psują ten blok w ramach większego skryptu

cat<<-FOOBAR
  echo Hello $USER
FOOBAR 

1. Przykład#3 - bez rozwijania zmiennych środowiskowych. FOOBAR w apostrofach.

cat<<-'FOOBAR'
  echo Hello $USER
FOOBAR

1. Przykład#4 - bez rozwijania zmiennych środowiskowych, wynik do pliku.

cat<<-'FOOBAR' > greeting.sh 
  echo Hello $USER
FOOBAR

1. Przykład#5 - niektóre zmienna są rozwijane, inne nie. Escapowanie $ za pomocą \

export GREETING=Hello 

cat<<-FOOBAR
  echo $GREETING \$USER 
FOOBAR

Kurtyna.

Postanowiłem zaimplementować API do formatu plików konfiguracyjnych TreeStructInfo (w skrócie: TSI).

Dla tych, którzy o nim nie słyszeli: jest on autorstwa @furious programming i jest przeznaczony, jak sam autor pisze, "do przechowywania różnego rodzaju konfiguracji aplikacji i gier w formie drzew danych".

Wybrałem Basha jako technologię implementacji. Dlaczego Bash? Nie wiem. Chyba dlatego, że go (trochę) umiem. Może, że go lubię. Może by samego siebie przekonać, że się tak da (zamiast np. w JavaScripcie, który znam lepiej od Basha).

Nie mam przygotowanego ścisłego planu implementacji żadnego projektu API. Jak wyjdzie podczas implementacji, to wyjdzie. Moim celem jest skończenie – by działało. Na początku miałem nawet plan, by korzystać z rekurencji zamiast wbudowanych pętli, ale doszedłem do wniosku, że w Bashu rzadko będzie ku temu dobra okazja. Im mniej kombinowania, tym większa szansa, że to skończę.

W związku z tym, że to Bash, planuję stworzyć program konsolowy zamiast typowej biblioteki. Myślę, że dobrym wyborem na nazwę (a więc również polecenie konsolowe) będzie "tsi-bash"; jednak może się jeszcze to zmienić. Co do platform/środowisk działania programu, planuję prosto: tam, gdzie działa Bash, program będzie można uruchomić.

Utworzyłem już repozytorium na GitHubie (na razie puste, tak): https://github.com/DevSilv/tsi-bash https://github.com/DevSilv/tsi-bash-util Nie planuję korzystać w nim z issues; zostawię jednak tę funkcjonalność włączoną, gdyby ktoś chciał skomentować jakiś bug.

Czy zakładam, że ten projekt może nie wyjść, że mogę porzucić go w trakcie? Zakładam.

Jak zawsze – wszelkie komentarze, uwagi mile widziane. :) Tym bardziej w tym projekcie, gdzie moja praca jest w zasadzie wspólna z pracą @furious programming.

UPDATE: W kwestii licencji źródeł programu: na razie żadnej nie planuję (= brak licencji); może się to jeszcze zmienić.

Przy okazji: oficjalnie zawieszam moją naukę Angulara 7. Tutu pierwszy post w tym temacie dla przypomnienia, co i jak. "Zawieszenie" jest lżejszym wyrażeniem niż "zakończenie obecnej nauki", więc na razie tak piszę.

Czy wrócę do niego? Nie planuję.

Dlaczego nie udało mi się być systematycznym? Trudno powiedzieć.

Przy okazji 2 (@WeiXiao): czy pamiętam o CoyoteNET? Pamiętam. Jednak technologia .NET daleka jest od moich obecnych zainteresowań. Nie widzę sensu iść w coś, gdzie bym tylko zawadzał.

#programowanie #treestructinfo #furious-programming #pliki-konfiguracyjne #moja-nauka-angulara #news #projekt #bash

Wczoraj skończyłem pisać mój skrypt w języku C, który przetworzył mi plik tekstowy zawierający ponad 4,5 miliona linii i stworzył ok. 20 tys. plików wynikowych.

UPDATE: Tutaj siedzi on sobie na GitHubie: https://github.com/devsilv/devsilv-detlan

Nic skomplikowanego; ot, skrypt wyszukuje linie spełniające podany warunek i kopiuje je do poszczególnych plików wynikowych.

Wydajność

Czas wykonywania głównej pętli: ok. 30 sekund. Uważam to za wynik świetny, porównując z moim poprzednim skryptem, w Bashu, który zamierzał robić to samo kilka godzin (przerwałem mu w połowie). (Pamiętajcie, że na Bashu mogę nie znać się za dobrze. Żeby właściwie porównać te języki, znajdźcie benchmarki inne niż moje skrypty :P).

Poprawność wyjścia

Nie jestem doświadczony w języku C; wyszło, że taki nieskomplikowany skrypt to nic trudnego… powiedzmy. Wydaje się działać.

Właśnie. Ktoś mógłby zapytać, czy skrypt działa poprawnie. Przeglądałeś wszystkie pliki wynikowe linijka po linijce? Skąd wiesz, że jakiś znak występujący 3 razy na krzyż w pliku wejściowym nie został pominięty, ponieważ wśród 10 użytych funkcji użyłeś akurat jednej, która nie obsługuje odpowiedniego kodowania?

Słuszne uwagi. Nie wymagam wielkiej poprawności na tym etapie, więc przygotowałem sobie prosty jednolinijkowiec w Bashu, by sprawdzić poprawność plików:

for file in ./* ; do if [[ $(grep -o "here-i-typed-the-text-to-search-for" $file | wc -l) != 1 ]] ; then echo "$file is NOT OK" ; fi ; done

Wykonawszy ten test na plikach wynikowych, nie otrzymałem żadnego wyjścia (i tego właśnie oczekiwałem). — Przy okazji, jeśli oko Cię lekko zakuło od spojrzenia na konstrukcję for file in ./*, to ja nie wiem, w ilu wypadkach jest bezpieczna (na pewno nie we wszystkich!). Niemniej, ciekawostka, Greg mówi, że jest w porządku: http://mywiki.wooledge.org/ParsingLs#Enumerating_files_or_doing_stuff_with_files A jeśli chcesz pisać lepsze skrypty w systemach *nix, moim zdaniem warto także przeczytać ten "esej" Davida A. Wheelera (m.in. pisze o tej konstrukcji; wyszukaj w tekście in ./* lub in *).

W razie czego (w miarę potrzeb) przygotuję sobie coś więcej.

Spostrzeżenia

W związku ze skończeniem pisania mojego skryptu mam kilka spostrzeżeń.

Makefile

Do kompilacji nie użyłem makefile; wystarczyła mi historia poleceń linii komend. Nie wiem, czy to źle, czy dobrze. Do poprzedniego programu w C użyłem makefile. (Nie wspominam tego miło. Ale to pewnie dlatego, że nie chciało mi się wtedy uczyć tego języka. Wystarczyło mi do szczęścia samo przypominanie sobie C od podstaw).

Wersja standardu / dialektu C

Pisząc w C dobrze być pewnym, którego standardu / dialektu się używa, nadto – jawnie powiedzieć to kompilatorowi. Ot, bo różnorodność ich jest. Szczególnie jak jawnie używa się więcej niż jednej flagi kompilatora.

Alokacja pamięci

Mam dziwne wrażenie, że alokując pamięć w funkcjach i zwracając sam wskaźnik do niej, można by zrobić to lepiej – jakoś lepiej. Przecież to podatne na błędy (=dziwne) pisać przy każdej funkcji: "Uważaj: jeśli używasz tej funkcji, nie zapomnij zwolnić pamięci". A jak inaczej zasygnalizować użytkownikowi?

A używać funkcji, które operują na już zaalokowanej pamięci? To znów dla mnie nieintuicyjne. Nie napiszę przecież (choć w skrypcie napisałem):

const char *src = "Wesoły tekst o niczym";
const char *dst = malloc(strlen(src) + 1); // pamiętać: +1 to na kończący NULL
strcpy(src, dst);
free(dst);

tylko raczej wolę:

const char *src = "Wesoły tekst o niczym";
const char *dst = strdup(src); // przed C20 dostępne w dialektach GNU

choć oczywiście w tym drugim przypadku muszę tak samo na koniec:

free(dst);

(@alagner, dziękuję jeszcze raz).

Nie żebym* chciał wymyślać koło i implementować rozwiązanie pokroju garbage collectora, ale…

* To nie jest przytyk do nikogo. Po prostu mnie samemu ciężko zapamiętać wszystkie reguły, i tutaj bym zrobił błąd interpunkcyjny, gdybym nie sprawdził.

Wyjątki

Przydałaby się obsługa wyjątków czy czegoś… Ogólnie: przejrzysty mechanizm obsługi błędów, niezależny od "logiki biznesowej". ( :P )

Do tej pory nie zauważyłem, by w C była jedna wartość, którą można zwrócić z funkcji o każdym typie, a dzięki temu można uznać za odpowiednik wyjątku.

Są co prawda inne sposoby…

• Takie: https://stackoverflow.com/a/2891769 …
• Tu też coś jest: https://news.ycombinator.com/item?id=3883310 …
• Tu też: https://www.tutorialspoint.com/cprogramming/c_error_handling.htm …

Trzeba się ich nauczyć. Może nawet czasem lepsze niż wyjątki?

Szkoda, że nie trafiłem na jakąś stronę, która listuje, a najlepiej porównuje wszystkie możliwe sposoby.

Postscripta

(Dla zainteresowanych moją działalnością na naszym forum).

• @tajny_agent, pamiętam o wskazówce dot. prealokowania pamięci – może zrobię to w kolejnym skrypcie.
• Nie, nie zapomniałem o Angularze… Często mi się przypomina, jak wchodzę na forum. Ale co zrobić? Są różne projety; czas płynie; jedne pomysły znikają, inne się pojawiają; nie, żebym się usprawiedliwiał… Krótko mówiąc, jeśli zdecyduję się wrócić do Angulara lub definitywnie zakończyć obecną przygodę z nim, to wyraźnie o tym napiszę (podkreślam, że obecną, bo co przyszłość przyniesie, tego nie wiem).
• Nie, nie zapomniałem o CoyoteNET… Patrz wyżej. Jeśli zdecyduję się wrócić, to wyraźnie o tym napiszę. Na razie, jak napisałem na Slacku, wciąż robię to, co zaplanowałem jeszcze przed pojawieniem się pomysłu na CoyoteNET.

#c #skrypt #przetwarzanie-tekstu #text-processing #bash #język-programowania #spostrzeżenia

UPDATE: Dodałem link do GitHuba.