Dlaczego języki skryptowe (np. Perl, Python, Ruby) nie są odpowiednie jako języki powłoki? [zamknięte]

To kulturowe. powłoka Bourne ' ama prawie 25 lat; był jednym z pierwszych języków skryptowych i pierwszym dobrym rozwiązaniem centralnej potrzeby administratorów uniksowych. (Tj. 'klej' do łączenia wszystkich innych narzędzi i wykonywania typowych zadań uniksowych bez konieczności kompilowania cholernego programu C za każdym razem.)

Według współczesnych standardów jego składnia jest okropna, a jego dziwne zasady i styl interpunkcji jako oświadczenia (przydatne w latach 70. policzone) utrudniają nie-adminom penetrację. Ale to się udało.[4]} wady i niedociągnięcia zostały rozwiązane przez ewolucyjne ulepszenia w jego potomkach (ksh, bash, zsh) bez konieczności godzenia się z ideami stojącymi za tym. Admini trzymali się podstawowej składni, ponieważ, jak to było dziwne, nic innego nie poradziło sobie z prostymi rzeczami lepiej, nie wchodząc w drogę.

W przypadku złożonych rzeczy, pojawił się Perl i przekształcił się w rodzaj języka pół-admina, pół-aplikacji. Ale bardziej skomplikowane staje się coś, tym bardziej jest postrzegane jako aplikacja, a nie praca admina, więc ludzie biznesu mają tendencję do szukania "programistów", a nie" adminów", aby to zrobić, pomimo faktu, że odpowiedni rodzaj Geeka zwykle jest jednym i drugim. Tak więc na tym się skupiliśmy, a ewolucyjne ulepszenia możliwości aplikacji Perla zaowocowały...Python i Ruby. (To uproszczenie, ale Perl był jedną z kilku inspiracji dla obu języków.)

Wynik? Specjalizacja. Admini zazwyczaj myślą, że współczesne języki interpretowane są zbyt ciężkie na rzeczy, za które płacą codziennie. I ogólnie mają rację. Nie potrzebują przedmiotów. Nie dbają o struktury danych. Potrzebują poleceń. potrzebują kleju. nic innego nie próbuje robićpoleceń lepiej niż koncepcja powłoki Bourne ' a (może poza Tcl, o którym tu już wspomniano); a Bourne jest wystarczająco dobry.

Programiści - którzy w dzisiejszych czasach mają aby dowiedzieć się więcej o devops-spójrz na ograniczenia powłoki Bourne ' a i zastanów się, jak do cholery ktokolwiek mógł z tym wytrzymać. Ale narzędzia, które znają, choć z pewnością skłaniają się ku Uniksowemu stylowi operacji We / Wy i plików, nie są lepsze do tego celu. Pisałem takie rzeczy jak skrypty kopii zapasowych i jednorazowe zmiany nazw plików w Rubim, ponieważ znam to lepiej niż bash, ale każdy dedykowany admin mógłby zrobić to samo w bash -- prawdopodobnie w mniejszej liczbie wierszy i z mniejszym obciążeniem, ale tak czy siak, to działa równie dobrze.

Często się pyta "dlaczego wszyscy używają Y Kiedy Z jest lepszy?"--ale ewolucja w technologii, podobnie jak ewolucja we wszystkim innym, ma tendencję do zatrzymywania się na wystarczająco dobrym. "lepsze" rozwiązanie nie wygra, chyba że różnica jest postrzegana jako frustracja przełamująca rozdanie. Skrypty typu Bourne ' a mogą być frustrujące dla Ciebie , ale dla ludzi, którzy używają go cały czas i dla zadań to było przeznaczone, zawsze wykonywało swoją pracę.

Język powłoki musi być łatwy w użyciu. Chcesz wpisać jednorazowe polecenia wyrzuć, a nie małe programy. Czyli chcesz wpisać

ls -laR /usr

Nie

shell.ls("/usr", long=True, all=True, recursive=True)

To (również) oznacza, że języki powłoki nie dbają o to, czy argument jest opcją, łańcuchem znaków, liczbą czy czymś innym.

Ponadto, konstrukcje programistyczne w powłokach są dodatkiem, a nawet nie zawsze są wbudowane. Rozważmy kombinację if i [ w (ba) sh, seq do generowania sekwencji, i tak dalej.

Wreszcie, powłoki mają specyficzne potrzeby, których potrzebujesz mniej lub inaczej w programowaniu. Rury, przekierowanie plików, kontrola procesu / zadania i tak dalej.

Jeśli znasz taki język, proszę również go opublikować.

Tcl jest jednym z takich języków. Głównie dlatego, że jest przeznaczony przede wszystkim jako interpreter powłoki dla programów CAD. Oto doświadczenie programisty Pythona w zrozumieniu, dlaczego tcl został zaprojektowany w taki sposób, w jaki był: http://www.yosefk.com/blog/i-cant-believe-im-praising-tcl.html

Dla mnie pisałem i używałem i ulepszałem TCL shell (oczywiście napisany w tcl) jako mój główny Linux login shell on my homebrew router: Pure TCL readline

Niektóre z powodów, dla których lubię tcl ma wszystko wspólnego z podobieństwem jego składni do tradycyjnych powłok:

1. Najbardziej podstawową składnią tcl jest command argument argument.... Nie ma nic więcej. Jest to to samo co bash, csh lub nawet DOS shell.

2. Bareword jest uważany za ciąg. Jest to znowu podobne do tradycyjnych powłok pozwalających pisać: open myfile.txt w+ zamiast open "myfile.txt" "w+".

3. Ze względu na podstawy 1 i 2 tcl kończy się bardzo mało obcej składni. Piszesz kod z mniejszą interpunkcją: puts Hello zamiast printf("Hello");. Pisząc programy nie odczuwasz bólu tak bardzo, ponieważ spędzasz dużo czasu na rozmyślaniu o tym, co napisać. Kiedy używasz powłoki do kopiowania pliku, nie wydaje ci się, że po prostu wpisujesz i musisz wpisywać ( i " i , i ) i ; raz po raz irytuje cię bardzo szybko.

*uwaga: nie ja, jestem hardkorowym programistą tcl

Kto powiedział, że nie są? Zobacz też Zoidberg. REPLs (Read Eval Print Loops) tworzy gówniane powłoki, ponieważ każde polecenie musi być poprawne składniowo, a uruchamianie programu wychodzi z:

foo arg1 arg2 arg3

Do

system "foo", "arg1", "arg2", "arg3"

Więc potrzebujesz niestandardowej powłoki (a nie REPL), która rozumie polecenia i przekierowania oraz język, którego chcesz użyć do łączenia poleceń. I think zoid (the Zoidberg shell) robi całkiem dobrą robotę.

Ten wątek zainspirował mnie do przejęcia obsługi powłoki opartej na perlu Zoidberg. Po kilku poprawkach jest ponownie użyteczny! Sprawdź user ' s guide lub zainstaluj Bundle::Zoidberg Korzystanie z ulubionego klienta CPAN.

Nie.

nie, języki skryptowe prawdopodobnie nie są odpowiednie dla powłok.

Problemem jest dychotomia międzymakro językami a, cóż, wszystkim innym.

Powłoka jest w kategorii z innymi starszymi językami makro, takimi jak nroff i m4 . W tych procesorach wszystko jest ciągiem znaków i procesor definiuje mapowanie od ciągów wejściowych do wyjściowych.

Pewne granice są przekraczane w obu Kierunki we wszystkich językach, ale zazwyczaj jest dość jasne, czy Kategoria systemu to makro , czy, hmm, nie znam oficjalnego terminu ... Powiem "prawdziwy język".

Więc pewnie, możesz wpisać wszystkie swoje polecenia w języku takim jak Ruby, i może to być nawet drugi najlepszy wybór do prawdziwej powłoki, ale nigdy nie będzie to język makr. Jest zbyt wiele składni do uszanowania. To wymaga zbyt wielu cytatów.

Ale język makr ma swoje problemy kiedy zaczniesz w nim programować, ponieważ trzeba było pójść na zbyt wiele kompromisów, aby pozbyć się całej składni. Ciągi są wpisywane bez cudzysłowów. Różne ilości magii muszą być ponownie wprowadzone, aby wprowadzić brakującą składnię. Zrobiłem kiedyś w nroffie code-golf, żeby być innym. To było dość dziwne. Kod źródłowy do dużych implementacji w językach makr jest przerażający.

Myślę, że to kwestia parsowania. Języki powłoki domyślnie zakładają, że $ command oznacza, że masz na myśli polecenie do uruchomienia, Python / Ruby wymaga wykonania systemu("command") lub co innego. Nie chodzi o to, że są nieodpowiednie, tylko o to, że nikt jeszcze tego nie zrobił, przynajmniej tak myślę. Rush http://rush.heroku.com/{[2] } jest przykładową próbą w Ruby, Python ma "iPython" lub coś w tym stylu.

Ponieważ oba języki są formalnie językami programowania, to co można robić w jednym, można robić w drugim. W rzeczywistości jest to kwestia nacisku na projekt. Języki powłoki są zaprojektowane do interaktywnego użytku, podczas gdy języki skryptowe nie są.

Podstawową różnicą w projekcie jest przechowywanie danych między poleceniami a zakresem zmiennych. W Bash itp. musisz przeskoczyć przez obręcze, aby zapisać wartość( na przykład polecenia takie jak set a='something'), podczas gdy w językach takich jak Python po prostu używasz assignment statement (a = 'something'). Podczas używania wartości w języku powłoki musisz powiedzieć językowi, że chcesz wartość zmiennej, podczas gdy w językach skryptowych musisz powiedzieć językowi, kiedy chcesz natychmiastową wartość ciągu. Ma to wpływ, gdy jest używane interaktywnie.

W języku skryptowym, w którym ls zdefiniowano jako polecenie

a = some_value

ls a*b  

(co oznacza a? Czy to znaczy some_value * (cokolwiek to jest b) Czy masz na myśli "a' anystring 'B"?. W języku skryptowym domyślnym jest to, co jest przechowywane w pamięci dla.)

ls 'a*b'  Now means what the Unix ls a*b means.

In a Bash-like language

set a=some_value

ls a*b   means what the Unix ls a*b means.

ls $a*b  uses an explicit recall of the value of a.

Języki skryptowe ułatwiają przechowywanie i przywoływanie wartości i trudno jest mieć na wartości przejściowy zakres. Języki powłoki umożliwiają przechowywanie i przywoływanie wartości, ale mają trywialnie przejściowy zakres dla każdego polecenia.

Zadajesz pytanie. Nie wszyscy zgadzają się, że języki powłoki są lepsze. Po pierwsze, _ Why doesn ' t

Niedawno znajomy zapytał mnie, jak rekurencyjnie przeszukiwać jego skrypty PHP pod kątem ciągu znaków. Miał wiele dużych plików binarnych i szablonów w tych katalogach, które mogły naprawdę pogrążyć zwykły grep. Nie mogłem wymyślić sposobu, aby użyć grepa, aby to się stało, więc pomyślałem, że użycie find I grep razem będzie moim najlepszym wyborem.

  find . -name "*.php" -exec grep 'search_string' {} \; -print

Oto powyższe wyszukiwanie plików przerobione w Ruby:

  Dir['**/*.php'].each do |path|
    File.open( path ) do |f|
      f.grep( /search_string/ ) do |line|
        puts path, ':', line
      end
    end
  end

Twoja pierwsza reakcja może brzmieć: "Cóż, to trochę słowniejsze niż oryginał."I po prostu muszę wzruszyć ramionami i pozwolić, by tak było. "Jest o wiele łatwiejsze do rozszerzenia", mówię. Działa na różnych platformach.

Skalowalność i rozszerzalność? Common Lisp (można nawet uruchomić CLISP, i ewentualnie inne implementacje, jako Powłoka logowania w środowiskach UNIX).

Dla użytkowników windows, nie czułem jeszcze potrzeby powershell ponieważ nadal używam 4NT (teraz Przejmij kontrolę) od Jpsoft, jest to bardzo dobra powłoka z wieloma możliwościami programistycznymi. Łączy w sobie to, co najlepsze z obu światów.

Kiedy spojrzysz na NP IRB (interpreter ruby), musi być możliwe rozszerzenie go o więcej jednowierszowych, aby wykonywać codzienne Skryptowe lub masowe Zarządzanie plikami i zadania minutowe.