> Pytałem się wyraźnie: jaki jest już w systemie. O tym że można mieć bash w

i dostałeś WYRAŹNĄ odpowiedź: Windows Scripting Host.

Wiktor Zychla

do góry

Użytkownik "Wiktor Zychla" <u...@n...com.eu> napisał w wiadomości grup
dyskusyjnych:h2f4o6$ft8$...@n...news.neostrada.pl.
..
>> Pytałem się wyraźnie: jaki jest już w systemie. O tym że można mieć bash
>> w
>
> i dostałeś WYRAŹNĄ odpowiedź: Windows Scripting Host.

Owszem. Dostałem też równie wyraźną odpowiedź - PowerShell (a ten nie jest
preinstalowany o ile się nie mylę).

No, to teraz pytanko - dlaczego to musi być tak popieprzone (w porównaniu z
bash). Taki sobie skrypt:

Const SHOW_ACTIVE_APP = 1
Set objShell = Wscript.CreateObject("Wscript.Shell")
objShell.Run ("echo 123"), SHOW_ACTIVE_APP, True
Wscript.Quit

zamiast grzecznie wypisać 123 - buntuje się, bo oczywiście nie ma takiego
programu jak echo w MS Windows. Echo jest wbudowane w command.com, ale
command.com też nie bardzo działa z VBS, w dodatku XP i Vista to raczej
cmd.exe .

Po co takie cudo mi? Ano po to, aby zrobić "echo " & param & " | app.exe"
zamiast zwykłego "echo 123".

W bash to trywialne: echo "$param1 $param2 $param3 $param4" | app

Po co tak? Ano, param-sy są wypracowywane przez skrypt - jakieś 20-30
wartości na każdy, czyli łącznie więcej niż 20^4 zestawów parametrów ale
trochę z tego odpada - nie każda kombinacja jest potrzebna. To powinno się
łatwo modyfikować, tak bez kompilacji - także np. przy powtórnym
uruchomieniu nie odpalać zestawu już policzonego itd. Sam program app jest
mocno numeryczny - i chodzi o to, aby nie zaśmiecać go jakimiś bzdetami
okołosystemowymi (czas obliczeń dla jednego zestawu... no... powiedzmy około
2 godziny; tak, wiem ile jest 2 godziny razy 160 000; tak, wiem co to jest
O(n^k) i wiem że nie da się szybciej - i tak jest zaje... szybko.)
.Ładowanie od nowa za każdym razem ułatwia życie gdy system padnie czy coś -
strata tylko jednego przebiegu.

W bash to było trywialne - generowanie parametrów, odpalanie programu,
łapanie wyników, archiwizacja wyników, transfer do gnuplot przez sed, duży
ładny plik z wynikami - kilkaset stron wykresów. Ba! Skrypty ślicznie
gwarantują odtwarzalność wyników - jak ktoś nie wierzy, czy np. będzie
chciał policzyć te same zestawy parametrów ale dla innego modelu - to proszę
bardzo, bez wysiłku. Tak jak lubię - mniej klikania więcej rezultatów. A
program app ma tylko stdin/stdout. Zero GUI.

W Windows jest... no jakoś pod górkę. W końcu są Unix Utils - bo jestem za
leniwy aby uruchamiać Linuksa. Można by zakładać plik tymczasowy. Można
napisać własne echo. Ale chyba już mi się odechciało skryptów w MS Windows.

Czy MS musi wszystko komplikować bardziej niż trzeba?!

slawek

do góry

slawek wrote:
> W Linuksie sprawa jest prosta - bash, albo i jakiś inny.
>
> A jaki shell/język skryptowy jest dostępny w MS Windows - chodzi o to,
> aby niczego nie trzeba było instalować i aby nie trzeba było sprawdzać
> jakie to są Windows (Vista czy np. jakieś ME/NT) ? Polecenia z plików
> BAT to trochę za mało...

CMD ma funkcjonalność taką jak bash.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

> Owszem. Dostałem też równie wyraźną odpowiedź - PowerShell (a ten nie jest
> preinstalowany o ile się nie mylę).

jest, na Windows Server 2008. nigdzie nie napisałeś o jaki Windows Ci
chodzi.
piszesz tylko "czy jest preinstalowany na każdych MS Windows", odpowiedź na
takie pytanie jest negatywna dla każdej technologii skryptowej - WSH nie ma
na przykład na Windows 95.

> W bash to trywialne: echo "$param1 $param2 $param3 $param4" | app

nie znam bash i Ci nie pomogę, natomiast naturalne potokowanie robi się w
skryptach Windows tak:

http://www.microsoft.com/technet/scriptcenter/topics
/winpsh/manual/pipe.mspx

to jest nawet LEPSZE niż potoki w bashu, bo potokiem przekazywane mogą być
obiekty, a nie tylko literały.

natomiast w WSH, który NIE JEST POWŁOKĄ, tylko hostem skryptów z tego co mi
wiadomo potokowania w taki łatwy sposób nie ma - oczekujesz funkcjonalności
jabłka od gruszki. do potokowania międzyprocesowego służą potoki, których

> command.com też nie bardzo działa z VBS

kto Ci tak powiedział?

Dim oExecution
set oShell = createobject("wscript.shell")
polecenie = "program1 | program2 | program3"
set oExecution = oShell.exec("%ComSpec% /c """ & polecenie & """")
Wscript.Echo oExecution.StdOut.readall

> Czy MS musi wszystko komplikować bardziej niż trzeba?!

jak się nie umie wyrwać poza schemat starych przyzwyczajeń, to się ma
pretensje do wszystkich dookoła ;)
po prostu daj sobie szansę albo wróć do starych dobrych narzędzi, byleś nie
narzekał że coś nie działa jeden-do-jeden tak, jak się już kiedyś nauczyłeś.

pozdrawiam uprzejmie
Wiktor Zychla

do góry

> No, to teraz pytanko - dlaczego to musi być tak popieprzone (w
> porównaniu z bash). Taki sobie skrypt:
>
> Const SHOW_ACTIVE_APP = 1
> Set objShell = Wscript.CreateObject("Wscript.Shell")
> objShell.Run ("echo 123"), SHOW_ACTIVE_APP, True
> Wscript.Quit
>
> zamiast grzecznie wypisać 123 - buntuje się, bo oczywiście nie ma
> takiego programu jak echo w MS Windows. Echo jest wbudowane w
> command.com, ale command.com też nie bardzo działa z VBS, w dodatku XP i
> Vista to raczej cmd.exe .
>
> Po co takie cudo mi? Ano po to, aby zrobić "echo " & param & " |
> app.exe" zamiast zwykłego "echo 123".
>
> W bash to trywialne: echo "$param1 $param2 $param3 $param4" | app
>
> Po co tak? Ano, param-sy są wypracowywane przez skrypt - jakieś 20-30
> wartości na każdy, czyli łącznie więcej niż 20^4 zestawów parametrów ale
> trochę z tego odpada - nie każda kombinacja jest potrzebna. To powinno
> się łatwo modyfikować, tak bez kompilacji - także np. przy powtórnym
> uruchomieniu nie odpalać zestawu już policzonego itd. Sam program app
> jest mocno numeryczny - i chodzi o to, aby nie zaśmiecać go jakimiś
> bzdetami okołosystemowymi (czas obliczeń dla jednego zestawu... no...
> powiedzmy około 2 godziny; tak, wiem ile jest 2 godziny razy 160 000;
> tak, wiem co to jest O(n^k) i wiem że nie da się szybciej - i tak jest
> zaje... szybko.) .Ładowanie od nowa za każdym razem ułatwia życie gdy
> system padnie czy coś - strata tylko jednego przebiegu.
>
> W bash to było trywialne - generowanie parametrów, odpalanie programu,
> łapanie wyników, archiwizacja wyników, transfer do gnuplot przez sed,
> duży ładny plik z wynikami - kilkaset stron wykresów. Ba! Skrypty
> ślicznie gwarantują odtwarzalność wyników - jak ktoś nie wierzy, czy np.
> będzie chciał policzyć te same zestawy parametrów ale dla innego modelu
> - to proszę bardzo, bez wysiłku. Tak jak lubię - mniej klikania więcej
> rezultatów. A program app ma tylko stdin/stdout. Zero GUI.
>
> W Windows jest... no jakoś pod górkę. W końcu są Unix Utils - bo jestem
> za leniwy aby uruchamiać Linuksa. Można by zakładać plik tymczasowy.
> Można napisać własne echo. Ale chyba już mi się odechciało skryptów w MS
> Windows.
>
> Czy MS musi wszystko komplikować bardziej niż trzeba?!

Ale tu nie ma nic skomplikowanego. Masz obiekt do uruchamiania programów
zewnętrznych - używasz go dla każdego pojedynczego programu. Wyniki
działania wyciągasz do zmiennej, obrabiasz w VBS i przekazujesz jako
parametry przy uruchamianiu kolejnych programów.

Identycznie by to można zrobić w Perlu, czy czymkolwiek pod unixami.

Jedynie nie ma w WSH możliwości bezpośredniego wykonywania potokowego,
ale taka technika i tak jest błędogenna przy bardziej skomplikowanych
rzeczach, więc to nie powinno być problemem.


--
Zobacz, jak się pracuje w Google:
http://pracownik.blogspot.com

do góry

On 01.07.2009, Mateusz Ludwin wrote:
> slawek wrote:
>> W Linuksie sprawa jest prosta - bash, albo i jakiś inny.
>>
>> A jaki shell/język skryptowy jest dostępny w MS Windows - chodzi o to,
>> aby niczego nie trzeba było instalować i aby nie trzeba było sprawdzać
>> jakie to są Windows (Vista czy np. jakieś ME/NT) ? Polecenia z plików
>> BAT to trochę za mało...
>
> CMD ma funkcjonalność taką jak bash.

Wiesz co, ja bym się kłócił. Raz, że pisanie w nim skryptów to PITA,
dwa, że nawet niespecjalnie potrafi ot, choćby głupie przejęcie outputu
programu do zmiennej żeby użyć go jako argumentu dla innego polecenia.

--
Stanislaw Klekot

do góry

Użytkownik "Stachu 'Dozzie' K." <d...@d...im.pwr.wroc.pl.nospam>
napisał w wiadomości grup
dyskusyjnych:s...@d...im.pwr.wr
oc.pl...
>> CMD ma funkcjonalność taką jak bash.
>
> Wiesz co, ja bym się kłócił. Raz, że pisanie w nim skryptów to PITA,
> dwa, że nawet niespecjalnie potrafi ot, choćby głupie przejęcie outputu
> programu do zmiennej żeby użyć go jako argumentu dla innego polecenia.

CMD? No, bez żartów. Nie chodzi o to że zamiast ls jest dir - tylko właśnie
o to, o czym pisał Dozzie - sklejanie skryptem rozmaitych małych
programików. A do tego właśnie bash jest wprost idealny. W dodatku jest bash
dla MS Windows - a nie ma CMD dla Linuksa (bo i po co?) Wybór jest
oczywisty - bash, bash i jeszcze raz bash. I dlatego, choć bash jest free, i
choć były słuchy że MS włączy go do Windows - to aż dziwi że nie ma go
domyślnie w systemie MS. Co byłoby złego w tym, że byłby? To mały program,
wolę mieć bash-a zamiast Sapera.

slawek

do góry

Użytkownik "Patryk Włos" <p...@i...peel> napisał w wiadomości
grup dyskusyjnych:h2fd77$dls$...@o...icpnet.pl...
> Ale tu nie ma nic skomplikowanego. Masz obiekt do uruchamiania programów
> zewnętrznych - używasz go dla każdego pojedynczego programu. Wyniki

Cóż, widziałeś jak takie rzeczy robi się w bash? Widziałeś jak to jest w
VBS? Moim, subiektywnym, zdaniem w bash jest dużo prościej.

> Identycznie by to można zrobić w Perlu, czy czymkolwiek pod unixami.

Oczywiście. Odkrywcze zdanie - pod Uniksem czy Linuksem jest dużo łatwiej.
Odkrywcze. Odkrywcze. Rewelacja.

A o czym pisałem? A tak nawiasem mówiąc - to masz Perl na MS Windows
preinstalowany?

> Jedynie nie ma w WSH możliwości bezpośredniego wykonywania potokowego, ale
> taka technika i tak jest błędogenna przy bardziej skomplikowanych
> rzeczach, więc to nie powinno być problemem.

A czy to coś bardzo skomplikowanego jest? Jak miałbym napisać 5000 linii
jakiegoś skryptu - to pewnie jakieś zalety VBS bym docenił. Ale przy
skrypcie liczącym... 20 linijek... to chyba liczy się prostota?

Twoja opinia o sprawie da się streścić - wolno golić się jedynie maszynkami
Braun, bo jak wiadomo brzytwą można się skaleczyć. Przy okazji zapominając
że są inne wybory - np. depilacja woskiem.

Ogólnie jak widzę MS ma ciągle jeden i ten sam problem - nie potrafią tam
zrozumieć (jako paradygmatu), że równolegle mogą pracować różne programy. To
zaczęło się od preemptive multitasking (który nic nie miał wspólnego z
multitaskingiem), to ciągle wraca. Owszem, nie wątpię że w USA informatycy
wiedzą co to jest współbieżność. Ale w MS dalej myślą kategoriami DOS 3.3 -
czyli jeden komputer, jeden użytkownik, jakiś (jeden!) program. Co można
zrobić. Można najwyżej przełączyć się alt-tab na inny program. Ale na raz
tylko jeden jest ten pierszoplanowy. To daje efekty... czasem niezamierzone.

Pipeline to wyjątkowo prosty mechanizm. Ale w DOS był zrobiony ohydnie -
program najpierw liczył się całkiem do końca zapisując plik tymczasowy - a
dopiero potem ten plik tymczasowy był zapodawany dalej. Nic dziwnego że to
nie mogło dobrze działać. Weźmy np. taki schemat: program nr 1 odbiera
faksy, program numer 2 wyodrębnia faksy które należy wydrukować, program nr
3 drukuje faksy. Microsoftowskie pojęcie o programowaniu doprowadzało do
sytuacji, w której program numer 2 nigdy nie zaczynał pracy - bo program
numer 1 nigdy jej nie kończył! Gorzej - w plik tymczasowy puchł aż do
zatkania. Totalne zepsucie dobrego mechanizmu.

Oczywiście, można do tego dorabiać ideologię, zatrudniać facetów (babki) od
PR, głosić że "technika błędogędna" czy jakoś tak. Nota bene, swego czasu -
i to przed dominacją MS - uznawano że Basic nie jest poważnym językiem,
nawet w TV o tym było (w roku mniej-więcej 1072), że jego stosowanie
prowadzi do poważnych błędów i że tylko Algol. Więc jak to jest - "technika
błędogęgna" - czy język programowania dla niedzielnych programistów? Bez
jaj - pokaż mi język programowania w którym nie da sie ex def robić
błędów... :)

slawek

do góry

Stachu 'Dozzie' K. wrote:

>>> A jaki shell/język skryptowy jest dostępny w MS Windows - chodzi o to,
>>> aby niczego nie trzeba było instalować i aby nie trzeba było sprawdzać
>>> jakie to są Windows (Vista czy np. jakieś ME/NT) ? Polecenia z plików
>>> BAT to trochę za mało...
>> CMD ma funkcjonalność taką jak bash.
>
> Wiesz co, ja bym się kłócił. Raz, że pisanie w nim skryptów to PITA,

Bo go nie znasz. Basha się nauczyłeś a CMD nie.

> dwa, że nawet niespecjalnie potrafi ot, choćby głupie przejęcie outputu
> programu do zmiennej żeby użyć go jako argumentu dla innego polecenia.

Widziałem kiedyś takie sztuczki w CMD że fanatyczny pryszczers od basha wymiękł
i uciekł z wątku.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

> Pipeline to wyjątkowo prosty mechanizm. Ale w DOS był zrobiony ohydnie -
> program najpierw liczył się całkiem do końca zapisując plik tymczasowy - a

ja sądzę, że masz sprzeczność w koncepcji.

z jednej strony znęcasz się, zupełnie niepotrzebnie, nad mechanizmami z
poprzedniej epoki, z drugiej strony chcesz rozwiązania, które nie wymaga
żadnych dodatkowych komponentów (PowerShell nie może być, bo nie ma go
standardowo w starszych systemach), czyli de facto ograniczasz się do
rozwiazań z poprzednich epok.

proponuję wątek zakończyć.
napisałem Ci jak to co chcesz zrobić w WSH, napisałem Ci też że w PowerShell
potoki działają nawet lepiej niż w bashu.

jeśli to nadal Ci nie wystarczy, to być może tak naprawdę nie chodzi o ten
czy inny problem, tylko o to że chcesz sobie ponarzekać.
a od tego jest pl.pregierz.

pozdrawiam uprzejmie
Wiktor Zychla

do góry