bash zmienna globalna zagnieżdżona

[Mir]

Mamy sobie taki przykładowy skrypt:
------------------------------------------------------------
#!/bin/bash
zmienna="stara wartosc"
echo |if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
------------------------------------------------------------
Oraz wynik jego działania:
------------------------------------------------------------
zmienna = stara wartosc
zmienna = cos nowego!
a na koniec zmienna = stara wartosc
------------------------------------------------------------
Jak zrobić, by otrzymać: "a na koniec zmienna = cos nowego!" ???

Domyślam się, że problem jest związany z "|", gdzie polecenie w potoku
jest uruchamiane jako nowy proces w "podpowłoce"...?
Próbowałem różne kombinacje z export, declare, set,... i nie daje
rady, jestem już tym zmęczony..
...rozwiązanie z tymczasowym plikiem, jest dla mnie trochę jakoś tak
dziwaczne.

Pozdrawiam
Mir

[Paweł Kraszewski]

Post by Mir
Domyślam się, że problem jest związany z "|", gdzie polecenie w potoku
jest uruchamiane jako nowy proces w "podpowłoce"...?
Próbowałem różne kombinacje z export, declare, set,... i nie daje
rady, jestem już tym zmęczony..
...rozwiązanie z tymczasowym plikiem, jest dla mnie trochę jakoś tak
dziwaczne.

Proces potomny nie ma wpływu na środowisko procesu macierzystego. EOT.

[Rafal Dabrowa]

Post by Mir
------------------------------------------------------------
#!/bin/bash
zmienna="stara wartosc"
echo |if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
------------------------------------------------------------
------------------------------------------------------------
zmienna = stara wartosc
zmienna = cos nowego!
a na koniec zmienna = stara wartosc
------------------------------------------------------------
Jak zrobić, by otrzymać: "a na koniec zmienna = cos nowego!" ???
Domyślam się, że problem jest związany z "|", gdzie polecenie w potoku
jest uruchamiane jako nowy proces w "podpowłoce"...?
Próbowałem różne kombinacje z export, declare, set,... i nie daje
rady, jestem już tym zmęczony..
...rozwiązanie z tymczasowym plikiem, jest dla mnie trochę jakoś tak
dziwaczne.

Masz do wyboru:
1. dołożyć klamerki { i }:
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}

2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

[Mir]

Niestety klamerki { i } nie rozwiązują mojego problemu (za klamerką
zmienna = stara wartosc). No trudno, zostanę przy rozwiązaniu z
plikiem.

Post by Rafal Dabrowa
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

Tutaj mnie trochę zaintrygowałeś... W zasadzie nigdy się nad tym nie
zastanawiałem, od początku używałem basha do pisania skryptów jako
najbardziej rozbudowaną i uniwersalną wersję shella, mającym
największe możliwości. Innymi nie interesowałem się uważając je za
okrojone wersje, przystosowane do jakiś specyficznych zadań.
Choć to już nie na temat, ale jeśli ktoś zna jakąś fajną stronę
opisującą i porównującą shelle (szczególnie pod kątem pisania
skryptów) to ma okazję sie pochwalić.

Dzięki za pomoc.
Mir

[Stachu 'Dozzie' K.]

Post by Mir
Niestety klamerki { i } nie rozwiązują mojego problemu (za klamerką
zmienna = stara wartosc). No trudno, zostanę przy rozwiązaniu z
plikiem.

Post by Rafal Dabrowa
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

Tutaj mnie trochę zaintrygowałeś... W zasadzie nigdy się nad tym nie
zastanawiałem, od początku używałem basha do pisania skryptów jako
najbardziej rozbudowaną i uniwersalną wersję shella, mającym

^^^^^^^^^^^

Post by Mir
największe możliwości.

^^^^^^^^^^
LOL w kontekście porównywania zsh i basha.

Post by Mir
Innymi nie interesowałem się uważając je za
okrojone wersje, przystosowane do jakiś specyficznych zadań.
Choć to już nie na temat, ale jeśli ktoś zna jakąś fajną stronę
opisującą i porównującą shelle (szczególnie pod kątem pisania
skryptów) to ma okazję sie pochwalić.

Jeśli chodzi o porównanie, to chyba tylko praktyka. ash jest najbardziej
podstawową wersją SUS compliant sh, choć potrafi nieco więcej niż wymaga
standard. ksh z kolei (i pdksh, jako pochodna) ma więcej spraw (głównie
składniowych) jemu specyficznych, ale niekiedy nie rozumie tego, co inne
shelle przełkną bez problemu.

[MoonWolf]

Post by Stachu 'Dozzie' K.

Post by Mir
najbardziej rozbudowaną i uniwersalną wersję shella, mającym

^^^^^^^^^^^

Post by Mir
największe możliwości.

^^^^^^^^^^
LOL w kontekście porównywania zsh i basha.

A ja od ponad roku się próbuję przesiąść na zsh. I jakoś nie mam
motywacji :/

[Stachu 'Dozzie' K.]

Post by MoonWolf

Post by Stachu 'Dozzie' K.

Post by Mir
najbardziej rozbudowaną i uniwersalną wersję shella, mającym

^^^^^^^^^^^

Post by Mir
największe możliwości.

^^^^^^^^^^
LOL w kontekście porównywania zsh i basha.

A ja od ponad roku się próbuję przesiąść na zsh. I jakoś nie mam
motywacji :/

Ja przyjrzałem się zshellowi bliżej gdy zobaczyłem, że pokazuje
uzupełnienia *pod* promptem, a przy trzecim wciśnięciu tabulatora
zaczyna przebiegać kolejne elementy z listy uzupełnień. A gdy
przeczytałem, że można bezkarnie wymieszać radośnie klawiszologię Emacsa
i vi, pokochałem tę powłokę.

[MoonWolf]

Post by Stachu 'Dozzie' K.

Post by MoonWolf
A ja od ponad roku się próbuję przesiąść na zsh. I jakoś nie mam
motywacji :/

Ja przyjrzałem się zshellowi bliżej gdy zobaczyłem, że pokazuje
uzupełnienia *pod* promptem, a przy trzecim wciśnięciu tabulatora
zaczyna przebiegać kolejne elementy z listy uzupełnień. A gdy
przeczytałem, że można bezkarnie wymieszać radośnie klawiszologię
Emacsa i vi, pokochałem tę powłokę.

Chyba w końcu się przesiądę - póki co skrypty mogę pisać w bashu (:)

[Stachu 'Dozzie' K.]

Post by MoonWolf

Post by Stachu 'Dozzie' K.

Post by MoonWolf
A ja od ponad roku się próbuję przesiąść na zsh. I jakoś nie mam
motywacji :/

Ja przyjrzałem się zshellowi bliżej gdy zobaczyłem, że pokazuje
uzupełnienia *pod* promptem, a przy trzecim wciśnięciu tabulatora
zaczyna przebiegać kolejne elementy z listy uzupełnień. A gdy
przeczytałem, że można bezkarnie wymieszać radośnie klawiszologię
Emacsa i vi, pokochałem tę powłokę.

Chyba w końcu się przesiądę - póki co skrypty mogę pisać w bashu (:)

Wiesz, ja odróżniam shella w którym pracuję na codzień i shella w którym
piszę skrypty. W pierwszym przypadku lubię mieć mnóstwo udogodnień (np.
w globach, *(/) czy **/*{1..10}.jpg, uproszczone pętle,
`for E in *; rm $E', `|&' robiące za `2>&1 |' i tak dalej), w drugim
ważna jest dla mnie powszechność występowania. Basha nie zawsze mam do
skryptów, zresztą nie zawsze jest mi potrzebny, więc często się
ograniczam do samego sh.

[Konrad Kosmowski]

Post by Stachu 'Dozzie' K.

Post by MoonWolf
Chyba w końcu się przesiądę - póki co skrypty mogę pisać w bashu (:)

Wiesz, ja odróżniam shella w którym pracuję na codzień i shella w którym
piszę skrypty. W pierwszym przypadku lubię mieć mnóstwo udogodnień (np. w
globach, *(/) czy **/*{1..10}.jpg, uproszczone pętle, `for E in *; rm $E',
`|&' robiące za `2>&1 |' i tak dalej), w drugim ważna jest dla mnie
powszechność występowania. Basha nie zawsze mam do skryptów, zresztą nie
zawsze jest mi potrzebny, więc często się ograniczam do samego sh.

Niby tak. Ale na jakiej platformie nie ma basha w normalnej, wspieranej etc.
formie? Aktualnie stety albo niestety z reguły wybiera się to co jest
przyjemniejsze w obsłudze dla ludzi, a nie to co zajmuje 400KB mniej pamięci bo
to nie problem z reguły.

[Stachu 'Dozzie' K.]

Post by Konrad Kosmowski

Post by Stachu 'Dozzie' K.

Post by MoonWolf
Chyba w końcu się przesiądę - póki co skrypty mogę pisać w bashu (:)

Wiesz, ja odróżniam shella w którym pracuję na codzień i shella w którym
piszę skrypty. W pierwszym przypadku lubię mieć mnóstwo udogodnień (np. w
globach, *(/) czy **/*{1..10}.jpg, uproszczone pętle, `for E in *; rm $E',
`|&' robiące za `2>&1 |' i tak dalej), w drugim ważna jest dla mnie
powszechność występowania. Basha nie zawsze mam do skryptów, zresztą nie
zawsze jest mi potrzebny, więc często się ograniczam do samego sh.

Niby tak. Ale na jakiej platformie nie ma basha w normalnej, wspieranej etc.
formie?

Instalatory? Initramdyski (tak, bywa że tworzę ręcznie)? Linuksy
embedded? Linuksy na ARM, ot, choćby Familiar?

Post by Konrad Kosmowski
Aktualnie stety albo niestety z reguły wybiera się to co jest
przyjemniejsze w obsłudze dla ludzi, a nie to co zajmuje 400KB mniej pamięci bo
to nie problem z reguły.

Co nie zmienia faktu, że jeśli nie potrzebuję zmiennych lokalnych
i tablic, a regexpy występują rzadko, to wybieram sh zamiast basha.

[Tomasz Chmielewski]

Post by Stachu 'Dozzie' K.

Post by Konrad Kosmowski

Post by Stachu 'Dozzie' K.

Post by MoonWolf
Chyba w końcu się przesiądę - póki co skrypty mogę pisać w bashu (:)

Wiesz, ja odróżniam shella w którym pracuję na codzień i shella w którym
piszę skrypty. W pierwszym przypadku lubię mieć mnóstwo udogodnień (np. w
globach, *(/) czy **/*{1..10}.jpg, uproszczone pętle, `for E in *; rm $E',
`|&' robiące za `2>&1 |' i tak dalej), w drugim ważna jest dla mnie
powszechność występowania. Basha nie zawsze mam do skryptów, zresztą nie
zawsze jest mi potrzebny, więc często się ograniczam do samego sh.

Niby tak. Ale na jakiej platformie nie ma basha w normalnej, wspieranej etc.
formie?

Instalatory? Initramdyski (tak, bywa że tworzę ręcznie)? Linuksy
embedded? Linuksy na ARM, ot, choćby Familiar?

Z initramdyskami to tez sztuka dla sztuki, w wiekszosci wypadkow czy
zajmie on 2, czy 6 MB, nie ma znaczenia.

Embedded, to co innego. Choc i tam sprzet jest coraz mocniejszy, z
wieksza iloscia pamieci, wiekszym flashem itd.

[Stachu 'Dozzie' K.]

Post by Tomasz Chmielewski

Post by Stachu 'Dozzie' K.

Post by Konrad Kosmowski

Post by Stachu 'Dozzie' K.

Post by MoonWolf
Chyba w końcu się przesiądę - póki co skrypty mogę pisać w bashu (:)

Wiesz, ja odróżniam shella w którym pracuję na codzień i shella w którym
piszę skrypty. W pierwszym przypadku lubię mieć mnóstwo udogodnień (np. w
globach, *(/) czy **/*{1..10}.jpg, uproszczone pętle, `for E in *; rm $E',
`|&' robiące za `2>&1 |' i tak dalej), w drugim ważna jest dla mnie
powszechność występowania. Basha nie zawsze mam do skryptów, zresztą nie
zawsze jest mi potrzebny, więc często się ograniczam do samego sh.

Niby tak. Ale na jakiej platformie nie ma basha w normalnej, wspieranej etc.
formie?

Instalatory? Initramdyski (tak, bywa że tworzę ręcznie)? Linuksy
embedded? Linuksy na ARM, ot, choćby Familiar?

Z initramdyskami to tez sztuka dla sztuki, w wiekszosci wypadkow czy
zajmie on 2, czy 6 MB, nie ma znaczenia.

Ale kopiowanie basha z zależnościami to dość pracochłonny proces (ldd
+ awk + tar), zwłaszcza gdy już się ma gotowy initramdysk i paprze
w takim czymś. Prościej jest zrezygnować ze zmiennych lokalnych
i regexpów.

Post by Tomasz Chmielewski
Embedded, to co innego. Choc i tam sprzet jest coraz mocniejszy, z
wieksza iloscia pamieci, wiekszym flashem itd.

Wytłumaczysz mojemu iPAQowi 3660, że ma coraz więcej RAM-u i flasha?
Będę bardzo wdzięczny, bo pozbędę się plecków CF.

[Tomasz Chmielewski]

Post by Stachu 'Dozzie' K.

Post by Tomasz Chmielewski

Post by Stachu 'Dozzie' K.

Post by Konrad Kosmowski

Post by Stachu 'Dozzie' K.

Post by MoonWolf
Chyba w końcu się przesiądę - póki co skrypty mogę pisać w bashu (:)

Wiesz, ja odróżniam shella w którym pracuję na codzień i shella w którym
piszę skrypty. W pierwszym przypadku lubię mieć mnóstwo udogodnień (np. w
globach, *(/) czy **/*{1..10}.jpg, uproszczone pętle, `for E in *; rm $E',
`|&' robiące za `2>&1 |' i tak dalej), w drugim ważna jest dla mnie
powszechność występowania. Basha nie zawsze mam do skryptów, zresztą nie
zawsze jest mi potrzebny, więc często się ograniczam do samego sh.

Niby tak. Ale na jakiej platformie nie ma basha w normalnej, wspieranej etc.
formie?

Instalatory? Initramdyski (tak, bywa że tworzę ręcznie)? Linuksy
embedded? Linuksy na ARM, ot, choćby Familiar?

Z initramdyskami to tez sztuka dla sztuki, w wiekszosci wypadkow czy
zajmie on 2, czy 6 MB, nie ma znaczenia.

Ale kopiowanie basha z zależnościami to dość pracochłonny proces (ldd
+ awk + tar),

3 minuty?

Post by Stachu 'Dozzie' K.
zwłaszcza gdy już się ma gotowy initramdysk

Ktory powstal sam z siebie, bezpracochlonnie.

Post by Stachu 'Dozzie' K.
i paprze
w takim czymś. Prościej jest zrezygnować ze zmiennych lokalnych
i regexpów.

Czasem tak, czasem nie.

Post by Stachu 'Dozzie' K.

Post by Tomasz Chmielewski
Embedded, to co innego. Choc i tam sprzet jest coraz mocniejszy, z
wieksza iloscia pamieci, wiekszym flashem itd.

Wytłumaczysz mojemu iPAQowi 3660, że ma coraz więcej RAM-u i flasha?
Będę bardzo wdzięczny, bo pozbędę się plecków CF.

O, kolejny przypadek logiki zerojedynkowej u osobnika zdawaloby sie
rodzaju ludzkiego.

[Stachu 'Dozzie' K.]

Post by Tomasz Chmielewski

Post by Stachu 'Dozzie' K.
zwłaszcza gdy już się ma gotowy initramdysk

Ktory powstal sam z siebie, bezpracochlonnie.

Owszem. Wziąłem gotowy i go poprawiam.

Post by Tomasz Chmielewski

Post by Stachu 'Dozzie' K.

Post by Tomasz Chmielewski
Embedded, to co innego. Choc i tam sprzet jest coraz mocniejszy, z
wieksza iloscia pamieci, wiekszym flashem itd.

Wytłumaczysz mojemu iPAQowi 3660, że ma coraz więcej RAM-u i flasha?
Będę bardzo wdzięczny, bo pozbędę się plecków CF.

O, kolejny przypadek logiki zerojedynkowej u osobnika zdawaloby sie
rodzaju ludzkiego.

Widzisz, jest między nami podstawowa różnica. Ja wydaję się. Ty już
dawno z daleka wyglądasz na trolla. Żegnam.

[Tomasz Chmielewski]

Stachu 'Dozzie' K. schrieb:

(...)

Post by Stachu 'Dozzie' K.

Post by Tomasz Chmielewski

Post by Stachu 'Dozzie' K.

Post by Tomasz Chmielewski
Embedded, to co innego. Choc i tam sprzet jest coraz mocniejszy, z
wieksza iloscia pamieci, wiekszym flashem itd.

Wytłumaczysz mojemu iPAQowi 3660, że ma coraz więcej RAM-u i flasha?
Będę bardzo wdzięczny, bo pozbędę się plecków CF.

O, kolejny przypadek logiki zerojedynkowej u osobnika zdawaloby sie
rodzaju ludzkiego.

Widzisz, jest między nami podstawowa różnica. Ja wydaję się. Ty już
dawno z daleka wyglądasz na trolla. Żegnam.

Uhm.
Popularne twierdzenie "komputery sa coraz szybsze, maja coraz wiecej
pamieci i wieksze dyski" rowniez obalisz, zachecajac do rozmow z twoim
386 DX?

[Rafal Dabrowa]

Post by Mir
Niestety klamerki { i } nie rozwiązują mojego problemu (za klamerką
zmienna = stara wartosc). No trudno, zostanę przy rozwiązaniu z
plikiem.

Jest jeszcze trzeci sposób. Zobacz

http://wooledge.org/mywiki/BashFAQ#faq24

i "ProcessSubstitution"

Post by Mir

Post by Rafal Dabrowa
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

Tutaj mnie trochę zaintrygowałeś... W zasadzie nigdy się nad tym nie
zastanawiałem, od początku używałem basha do pisania skryptów jako
najbardziej rozbudowaną i uniwersalną wersję shella, mającym
największe możliwości. Innymi nie interesowałem się uważając je za
okrojone wersje, przystosowane do jakiś specyficznych zadań.

Główna zaleta to ta że bash jest dostępny na każdym Linuksie.
Ale porównując go z np. ksh93 nie powiedziałbym że bash jest bardziej
rozbudowany. Nie wiem czy bash ma coś czego ksh nie ma. Za to
ksh ma parę rzeczy których nie ma bash, np. tablice asocjacyjne albo
ko-procesy. No, i nie ma wspomnianej na wstępie uperdliwości związanej z
potokami, bo skrajnie prawa komenda w potoku jest wykonywana w bieżącym
procesie, o ile jest to komenda wbudowana.

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Rafal Dabrowa

Post by Mir
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

I w jaki sposób któreś z tych rozwiązań ma pomóc na fundamentalną zasadę
działania systemu operacyjnego, czyli oddzielenie środowiska procesu
potomnego od środowiska procesu macierzystego?
Dane trzeba przekazywać w inny sposób niż przez zmienne, po prostu.
Albo przez plik tymczasowy, albo przez stdin/stdout.

[Rafal Dabrowa]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Rafal Dabrowa

Post by Mir
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

I w jaki sposób któreś z tych rozwiązań ma pomóc na fundamentalną zasadę
działania systemu operacyjnego, czyli oddzielenie środowiska procesu
potomnego od środowiska procesu macierzystego?

Na tę zasadę to nie pomoże, ale na wspomniany problem ze zmiennymi to i
owszem.

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Rafal Dabrowa

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Mir
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

I w jaki sposób któreś z tych rozwiązań ma pomóc na fundamentalną zasadę
działania systemu operacyjnego, czyli oddzielenie środowiska procesu
potomnego od środowiska procesu macierzystego?

Na tę zasadę to nie pomoże, ale na wspomniany problem ze zmiennymi to i
owszem.

A w jaki niby sposób? Przecież rurkowanie tworzy proces potomny. Jak
chcesz w procesie potomnym zmienić środowisko rodzica?

[Rafal Dabrowa]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Rafal Dabrowa

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Mir
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

I w jaki sposób któreś z tych rozwiązań ma pomóc na fundamentalną zasadę
działania systemu operacyjnego, czyli oddzielenie środowiska procesu
potomnego od środowiska procesu macierzystego?

Na tę zasadę to nie pomoże, ale na wspomniany problem ze zmiennymi to i
owszem.

A w jaki niby sposób? Przecież rurkowanie tworzy proces potomny. Jak
chcesz w procesie potomnym zmienić środowisko rodzica?

Wcale nie chcę.

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Rafal Dabrowa

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Mir
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

I w jaki sposób któreś z tych rozwiązań ma pomóc na fundamentalną zasadę
działania systemu operacyjnego, czyli oddzielenie środowiska procesu
potomnego od środowiska procesu macierzystego?

Na tę zasadę to nie pomoże, ale na wspomniany problem ze zmiennymi to i
owszem.

A w jaki niby sposób? Przecież rurkowanie tworzy proces potomny. Jak
chcesz w procesie potomnym zmienić środowisko rodzica?

Wcale nie chcę.

To objaśnij mi jak chcesz wpłynąć na stan procesu macierzystego z
procesu potomnego?

[Rafal Dabrowa]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Rafal Dabrowa

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Mir
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

I w jaki sposób któreś z tych rozwiązań ma pomóc na fundamentalną zasadę
działania systemu operacyjnego, czyli oddzielenie środowiska procesu
potomnego od środowiska procesu macierzystego?

Na tę zasadę to nie pomoże, ale na wspomniany problem ze zmiennymi to i
owszem.

A w jaki niby sposób? Przecież rurkowanie tworzy proces potomny. Jak
chcesz w procesie potomnym zmienić środowisko rodzica?

Wcale nie chcę.

To objaśnij mi jak chcesz wpłynąć na stan procesu macierzystego z
procesu potomnego?

A po co miałbym w ogóle to robić?

Polecam do wykonania:
1. uruchom skrypt zmodyfikowany w sposób pokazany w rozwiązaniu 1
i sprawdź czy zmienił się wynik działania skryptu
2. zainstaluj w systemie (jeśli jeszcze nie masz) ksh93 albo zsh i
uruchom w nim oryginalny skrypt. Porównaj wynik działania skryptu
w ksh/zsh z wynikiem działania w baszu.

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Rafal Dabrowa

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Rafal Dabrowa

Post by Mariusz Kruk

Post by Mir
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
2. użyć jakiegoś normalnego szela, wolnego od tego typu pomysłowej
funkcjonalności (zsh, ksh)

I w jaki sposób któreś z tych rozwiązań ma pomóc na fundamentalną zasadę
działania systemu operacyjnego, czyli oddzielenie środowiska procesu
potomnego od środowiska procesu macierzystego?

Na tę zasadę to nie pomoże, ale na wspomniany problem ze zmiennymi to i
owszem.

A w jaki niby sposób? Przecież rurkowanie tworzy proces potomny. Jak
chcesz w procesie potomnym zmienić środowisko rodzica?

Wcale nie chcę.

To objaśnij mi jak chcesz wpłynąć na stan procesu macierzystego z
procesu potomnego?

A po co miałbym w ogóle to robić?
1. uruchom skrypt zmodyfikowany w sposób pokazany w rozwiązaniu 1
i sprawdź czy zmienił się wynik działania skryptu

Argh. Dopiero teraz się dopatrzyłem gdzie jest zamykająca klamra.
(zmyliły mnie te wcięcia).
Fakt, z klamrami będzie coś nowego, ale w ogólności to trochę kiepski
pomysł, jesli chciałbyś zmienną użyć w dalszej części programu.

Post by Rafal Dabrowa
2. zainstaluj w systemie (jeśli jeszcze nie masz) ksh93 albo zsh i
uruchom w nim oryginalny skrypt. Porównaj wynik działania skryptu
w ksh/zsh z wynikiem działania w baszu.

Hmm.. właśnie sobie doinstalowałem zsh i czytam manuala (muszę przyznać,
swoją drogą, że sprawia wrżenie lekko bałaganiarkiego w porównaniu z
bashem, ale to takie subiektywne niczym niepoparte wrażenie. YMMV).
I, szczerze mówiąc, nie do końca rozumiem działanie `|' w zsh. Jeśli
dobrze rozumiem, jeśli przed `a|b' wstawię `coproc', efekt będzie taki,
jak w bashu, tak? A jeśli nie wstawię? To co? On zamierza cały wynik
działania `a' zbuforować? Nie do końca to dla mnie jasne.

[Stachu 'Dozzie' K.]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Rafal Dabrowa

Post by Rafal Dabrowa

Post by Mir
zmienna="stara wartosc"
echo |{ if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}

[...]

Post by Mariusz Kruk

Post by Rafal Dabrowa
A po co miałbym w ogóle to robić?
1. uruchom skrypt zmodyfikowany w sposób pokazany w rozwiązaniu 1
i sprawdź czy zmienił się wynik działania skryptu

Argh. Dopiero teraz się dopatrzyłem gdzie jest zamykająca klamra.
(zmyliły mnie te wcięcia).

Faktycznie, głupio zrobione. Moim zdaniem powinno to być sformatowane
tak:
#v+
echo | {
if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
#v-

Post by Mariusz Kruk
Fakt, z klamrami będzie coś nowego, ale w ogólności to trochę kiepski
pomysł, jesli chciałbyś zmienną użyć w dalszej części programu.

Ja w takich przypadkach półjawnie przechodzę do subshella używając
backticków.

Post by Mariusz Kruk

Post by Rafal Dabrowa
2. zainstaluj w systemie (jeśli jeszcze nie masz) ksh93 albo zsh i
uruchom w nim oryginalny skrypt. Porównaj wynik działania skryptu
w ksh/zsh z wynikiem działania w baszu.

Hmm.. właśnie sobie doinstalowałem zsh i czytam manuala (muszę przyznać,
swoją drogą, że sprawia wrżenie lekko bałaganiarkiego w porównaniu z
bashem, ale to takie subiektywne niczym niepoparte wrażenie. YMMV).

Bo zsh to nie shell do skryptowania, tylko do pracy interaktywnej.
Można go sobie bardzo dokładnie dopasować do potrzeb, przez co ma
wymieszane opcje włączające i wyłączające pewne skróty składniowe
i cukier zsh-specific.

Post by Mariusz Kruk
I, szczerze mówiąc, nie do końca rozumiem działanie `|' w zsh. Jeśli
dobrze rozumiem, jeśli przed `a|b' wstawię `coproc', efekt będzie taki,
jak w bashu, tak? A jeśli nie wstawię? To co? On zamierza cały wynik
działania `a' zbuforować? Nie do końca to dla mnie jasne.

Słowo kluczowe coproc służy do czegoś innego. Za manualem (a raczej
stroną info):

#v+
If a pipeline is preceded by `coproc', it is executed as a coprocess; a
two-way pipe is established between it and the parent shell. The shell
can read from or write to the coprocess by means of the `>&p' and `<&p'
redirection operators or with `print -p' and `read -p'.
#v-

To znaczy możesz pisać do koprocesu, a zaraz potem odczytać co koproces
na to powiedział. Mnie nigdy się to nie przydało bo rzadko potrzebuję
komunikacji dwukierunkowej, a jeśli już, to używam potoku nazwanego.

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Argh. Dopiero teraz się dopatrzyłem gdzie jest zamykająca klamra.
(zmyliły mnie te wcięcia).

Faktycznie, głupio zrobione. Moim zdaniem powinno to być sformatowane
#v+
echo | {
if true; then
echo "zmienna = $zmienna"
zmienna="cos nowego!"
echo "zmienna = $zmienna"
fi
echo "a na koniec zmienna = $zmienna"
}
#v-

No, mniej więcej coś w ten deseń.
Chociaż ja pewnie wolałbym wyrzucić otwierającą klamrę niżej, albo
całość poniżej otwierającej klamry wciąć bardziej (włącznie z
zamykającą). Ale to już kwestia osobniczych preferencji.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Fakt, z klamrami będzie coś nowego, ale w ogólności to trochę kiepski
pomysł, jesli chciałbyś zmienną użyć w dalszej części programu.

Ja w takich przypadkach półjawnie przechodzę do subshella używając
backticków.

W sensie przypisania do zmiennej wyniku działania sekwencji? (wyniku,
rzecz jasna w sensie stdout, nie exit code :-))
W sumie jedyna sensowna metoda.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Rafal Dabrowa
2. zainstaluj w systemie (jeśli jeszcze nie masz) ksh93 albo zsh i
uruchom w nim oryginalny skrypt. Porównaj wynik działania skryptu
w ksh/zsh z wynikiem działania w baszu.

Hmm.. właśnie sobie doinstalowałem zsh i czytam manuala (muszę przyznać,
swoją drogą, że sprawia wrżenie lekko bałaganiarkiego w porównaniu z
bashem, ale to takie subiektywne niczym niepoparte wrażenie. YMMV).

Bo zsh to nie shell do skryptowania, tylko do pracy interaktywnej.
Można go sobie bardzo dokładnie dopasować do potrzeb, przez co ma
wymieszane opcje włączające i wyłączające pewne skróty składniowe
i cukier zsh-specific.

Ja tam za leniwy jestem. Do dziś na epsilonie używam tcsh tylko dlatego,
że nie chce mi się szukać jak w bashu zrobić tcshowe alt-p :-)
(chociaż skryptowanie w tcsh to raczej nie to, co tygrysy lubią
najbardziej; tu jednak bash)

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
I, szczerze mówiąc, nie do końca rozumiem działanie `|' w zsh. Jeśli
dobrze rozumiem, jeśli przed `a|b' wstawię `coproc', efekt będzie taki,
jak w bashu, tak? A jeśli nie wstawię? To co? On zamierza cały wynik
działania `a' zbuforować? Nie do końca to dla mnie jasne.

Słowo kluczowe coproc służy do czegoś innego. Za manualem (a raczej
#v+
If a pipeline is preceded by `coproc', it is executed as a coprocess; a
two-way pipe is established between it and the parent shell. The shell
can read from or write to the coprocess by means of the `>&p' and `<&p'
redirection operators or with `print -p' and `read -p'.
#v-
To znaczy możesz pisać do koprocesu, a zaraz potem odczytać co koproces
na to powiedział. Mnie nigdy się to nie przydało bo rzadko potrzebuję
komunikacji dwukierunkowej, a jeśli już, to używam potoku nazwanego.

Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

[Rafal Dabrowa]

Post by Mariusz Kruk
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Potomek nie jest tworzony dla polecenia po prawej stronie '|' w potoku.
O ile jest to polecenie wbudowane, oczywiście.

[Stachu 'Dozzie' K.]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Fakt, z klamrami będzie coś nowego, ale w ogólności to trochę kiepski
pomysł, jesli chciałbyś zmienną użyć w dalszej części programu.

Ja w takich przypadkach półjawnie przechodzę do subshella używając
backticków.

W sensie przypisania do zmiennej wyniku działania sekwencji? (wyniku,
rzecz jasna w sensie stdout, nie exit code :-))
W sumie jedyna sensowna metoda.

Tak, właśnie w ten sposób. Programista czytający mój kod tego się
właśnie spodziewa czytając taki kawałek, więc nie będę mu utrudniać
życia.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Rafal Dabrowa
2. zainstaluj w systemie (jeśli jeszcze nie masz) ksh93 albo zsh i
uruchom w nim oryginalny skrypt. Porównaj wynik działania skryptu
w ksh/zsh z wynikiem działania w baszu.

Hmm.. właśnie sobie doinstalowałem zsh i czytam manuala (muszę przyznać,
swoją drogą, że sprawia wrżenie lekko bałaganiarkiego w porównaniu z
bashem, ale to takie subiektywne niczym niepoparte wrażenie. YMMV).

Bo zsh to nie shell do skryptowania, tylko do pracy interaktywnej.
Można go sobie bardzo dokładnie dopasować do potrzeb, przez co ma
wymieszane opcje włączające i wyłączające pewne skróty składniowe
i cukier zsh-specific.

Ja tam za leniwy jestem. Do dziś na epsilonie używam tcsh tylko dlatego,
że nie chce mi się szukać jak w bashu zrobić tcshowe alt-p :-)

A co to robi? Ja ostatnio włączałem w zsh parę tcshellowych komend.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
I, szczerze mówiąc, nie do końca rozumiem działanie `|' w zsh. Jeśli
dobrze rozumiem, jeśli przed `a|b' wstawię `coproc', efekt będzie taki,
jak w bashu, tak? A jeśli nie wstawię? To co? On zamierza cały wynik
działania `a' zbuforować? Nie do końca to dla mnie jasne.

Słowo kluczowe coproc służy do czegoś innego. Za manualem (a raczej
#v+
If a pipeline is preceded by `coproc', it is executed as a coprocess; a
two-way pipe is established between it and the parent shell. The shell
can read from or write to the coprocess by means of the `>&p' and `<&p'
redirection operators or with `print -p' and `read -p'.
#v-
To znaczy możesz pisać do koprocesu, a zaraz potem odczytać co koproces
na to powiedział. Mnie nigdy się to nie przydało bo rzadko potrzebuję
komunikacji dwukierunkowej, a jeśli już, to używam potoku nazwanego.

Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Ja tam za leniwy jestem. Do dziś na epsilonie używam tcsh tylko dlatego,
że nie chce mi się szukać jak w bashu zrobić tcshowe alt-p :-)

A co to robi? Ja ostatnio włączałem w zsh parę tcshellowych komend.

Coś jak tab-completion, tylko nie z filesystemu, tylko z historii.
Innymi słowy, jeśli przed chwilą uruchamiałem `./test.sh', po wpisaniu
kropki i naduszeniu alt-p dostanę właśnie `./test.sh'

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

[Stachu 'Dozzie' K.]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Ja tam za leniwy jestem. Do dziś na epsilonie używam tcsh tylko dlatego,
że nie chce mi się szukać jak w bashu zrobić tcshowe alt-p :-)

A co to robi? Ja ostatnio włączałem w zsh parę tcshellowych komend.

Coś jak tab-completion, tylko nie z filesystemu, tylko z historii.
Innymi słowy, jeśli przed chwilą uruchamiałem `./test.sh', po wpisaniu
kropki i naduszeniu alt-p dostanę właśnie `./test.sh'

E, to ja to mam w pod ^P i pod k w trybie poleceń (vi). Odpowiednio
.up-history i .history-beginning-search-backward.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

Ta spójność wprowadza trochę problemów i bywa niewygodna. Zresztą moim
zdaniem to kwestia dyskusyjna, czy ostatnie polecenie powinno być
wykonywane w subshellu. Dla mnie logiczniej wygląda podejście ksh/zsh,
a bashowe jedynie łatwiej zaimplementować.

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Ja tam za leniwy jestem. Do dziś na epsilonie używam tcsh tylko dlatego,
że nie chce mi się szukać jak w bashu zrobić tcshowe alt-p :-)

A co to robi? Ja ostatnio włączałem w zsh parę tcshellowych komend.

Coś jak tab-completion, tylko nie z filesystemu, tylko z historii.
Innymi słowy, jeśli przed chwilą uruchamiałem `./test.sh', po wpisaniu
kropki i naduszeniu alt-p dostanę właśnie `./test.sh'

E, to ja to mam w pod ^P i pod k w trybie poleceń (vi). Odpowiednio
.up-history i .history-beginning-search-backward.

Ależ ja wiem, że się da. Tyle, że nie chce mi się tego konfigurować w,
powiedzmy, bashu, skoro w tcsh działa od razu. Lenistwo, panie.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

Ta spójność wprowadza trochę problemów i bywa niewygodna. Zresztą moim
zdaniem to kwestia dyskusyjna, czy ostatnie polecenie powinno być
wykonywane w subshellu. Dla mnie logiczniej wygląda podejście ksh/zsh,
a bashowe jedynie łatwiej zaimplementować.

Podejście zsh jest o tyle niespójne, że o syntaktyce (działaniu rurek)
decyduje semantyka (czyli, czy polecenie jest wbudowane, czy
zewnętrzne).

[Stachu 'Dozzie' K.]

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

Ta spójność wprowadza trochę problemów i bywa niewygodna. Zresztą moim
zdaniem to kwestia dyskusyjna, czy ostatnie polecenie powinno być
wykonywane w subshellu. Dla mnie logiczniej wygląda podejście ksh/zsh,
a bashowe jedynie łatwiej zaimplementować.

Podejście zsh jest o tyle niespójne, że o syntaktyce (działaniu rurek)
decyduje semantyka (czyli, czy polecenie jest wbudowane, czy
zewnętrzne).

Lepiej żeby o semantyce (działaniu read) decydowała syntaktyka
(położenie read w potoku) w tak nieintuicyjny sposób?

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

Ta spójność wprowadza trochę problemów i bywa niewygodna. Zresztą moim
zdaniem to kwestia dyskusyjna, czy ostatnie polecenie powinno być
wykonywane w subshellu. Dla mnie logiczniej wygląda podejście ksh/zsh,
a bashowe jedynie łatwiej zaimplementować.

Podejście zsh jest o tyle niespójne, że o syntaktyce (działaniu rurek)
decyduje semantyka (czyli, czy polecenie jest wbudowane, czy
zewnętrzne).

Lepiej żeby o semantyce (działaniu read) decydowała syntaktyka
(położenie read w potoku) w tak nieintuicyjny sposób?

Przyznam, że nie do końca rozumiem. Chodzi Ci o to, że `| read ZMIENNA'
ustawi zmienną w procesie potomnym? Toć to intuicyjne i zgodne z opisem
działania rurek. I działanie read się nie zmienia. Co najwyżej, dla
początkujących może być trudno przyzwyczaić się do aktu spawnowania
potomka, ale działanie read jako takie jest dokładnie takie samo w
procesie macierzystym, jak w potomnym.
Chyba, że o coś innego Ci chodzi.

[Stachu 'Dozzie' K.]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

Ta spójność wprowadza trochę problemów i bywa niewygodna. Zresztą moim
zdaniem to kwestia dyskusyjna, czy ostatnie polecenie powinno być
wykonywane w subshellu. Dla mnie logiczniej wygląda podejście ksh/zsh,
a bashowe jedynie łatwiej zaimplementować.

Podejście zsh jest o tyle niespójne, że o syntaktyce (działaniu rurek)
decyduje semantyka (czyli, czy polecenie jest wbudowane, czy
zewnętrzne).

Lepiej żeby o semantyce (działaniu read) decydowała syntaktyka
(położenie read w potoku) w tak nieintuicyjny sposób?

Przyznam, że nie do końca rozumiem. Chodzi Ci o to, że `| read ZMIENNA'
ustawi zmienną w procesie potomnym? Toć to intuicyjne i zgodne z opisem
działania rurek.

Intuicyjnym byłoby, gdyby wszelkie shell builtiny i keywordy były
wykonywane w tym samym shellu, o ile nie poprosi się o subshella jawnie
(nawiasy okrągłe). Programista shellowy moim zdaniem nie powinien musieć
znać uniksowego API dla C, żeby dobrze rozumieć swój język.

Post by Mariusz Kruk
I działanie read się nie zmienia. Co najwyżej, dla
początkujących może być trudno przyzwyczaić się do aktu spawnowania
potomka, ale działanie read jako takie jest dokładnie takie samo w
procesie macierzystym, jak w potomnym.
Chyba, że o coś innego Ci chodzi.

Być może.

[Mariusz Kruk]

epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

Ta spójność wprowadza trochę problemów i bywa niewygodna. Zresztą moim
zdaniem to kwestia dyskusyjna, czy ostatnie polecenie powinno być
wykonywane w subshellu. Dla mnie logiczniej wygląda podejście ksh/zsh,
a bashowe jedynie łatwiej zaimplementować.

Podejście zsh jest o tyle niespójne, że o syntaktyce (działaniu rurek)
decyduje semantyka (czyli, czy polecenie jest wbudowane, czy
zewnętrzne).

Lepiej żeby o semantyce (działaniu read) decydowała syntaktyka
(położenie read w potoku) w tak nieintuicyjny sposób?

Przyznam, że nie do końca rozumiem. Chodzi Ci o to, że `| read ZMIENNA'
ustawi zmienną w procesie potomnym? Toć to intuicyjne i zgodne z opisem
działania rurek.

Intuicyjnym byłoby, gdyby wszelkie shell builtiny i keywordy były
wykonywane w tym samym shellu, o ile nie poprosi się o subshella jawnie
(nawiasy okrągłe).

To mamy inne definicje intuicyjności ;-)
W manie do basha jest explicite powiedziane, że wszystko, co po
prawej stronie rurki wykonuje się w podprocesie.

Post by Stachu 'Dozzie' K.
Programista shellowy moim zdaniem nie powinien musieć
znać uniksowego API dla C, żeby dobrze rozumieć swój język.

Za to powinien znać na pamięć listę wszystkich builtinów shella, żeby
wiedzieć kiedy zostanie wyspawnowany do podprocesu, a kiedy nie?
Zwłaszcza jeśli akurat się okaże, że ktoś używa funkcji o nazwach takich
jak zewnętrzne programy.

[Stachu 'Dozzie' K.]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.
Programista shellowy moim zdaniem nie powinien musieć
znać uniksowego API dla C, żeby dobrze rozumieć swój język.

Za to powinien znać na pamięć listę wszystkich builtinów shella, żeby
wiedzieć kiedy zostanie wyspawnowany do podprocesu, a kiedy nie?

Już prędzej. Zwłaszcza że niewiele jest sytuacji, gdy możesz chcieć
modyfikować środowisko shella wewnątrz potoku (zmienne środowiskowe
i ewentualnie ulimits).

Post by Mariusz Kruk
Zwłaszcza jeśli akurat się okaże, że ktoś używa funkcji o nazwach takich
jak zewnętrzne programy.

[Rafal Dabrowa]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

Ta spójność wprowadza trochę problemów i bywa niewygodna. Zresztą moim
zdaniem to kwestia dyskusyjna, czy ostatnie polecenie powinno być
wykonywane w subshellu. Dla mnie logiczniej wygląda podejście ksh/zsh,
a bashowe jedynie łatwiej zaimplementować.

Podejście zsh jest o tyle niespójne, że o syntaktyce (działaniu rurek)
decyduje semantyka (czyli, czy polecenie jest wbudowane, czy
zewnętrzne).

Lepiej żeby o semantyce (działaniu read) decydowała syntaktyka
(położenie read w potoku) w tak nieintuicyjny sposób?

Przyznam, że nie do końca rozumiem. Chodzi Ci o to, że `| read ZMIENNA'
ustawi zmienną w procesie potomnym? Toć to intuicyjne i zgodne z opisem
działania rurek.

Intuicyjnym byłoby, gdyby wszelkie shell builtiny i keywordy były
wykonywane w tym samym shellu, o ile nie poprosi się o subshella jawnie
(nawiasy okrągłe).

To mamy inne definicje intuicyjności ;-)
W manie do basha jest explicite powiedziane, że wszystko, co po
prawej stronie rurki wykonuje się w podprocesie.

To po lewej też.

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.
Programista shellowy moim zdaniem nie powinien musieć
znać uniksowego API dla C, żeby dobrze rozumieć swój język.

Za to powinien znać na pamięć listę wszystkich builtinów shella, żeby
wiedzieć kiedy zostanie wyspawnowany do podprocesu, a kiedy nie?
Zwłaszcza jeśli akurat się okaże, że ktoś używa funkcji o nazwach takich
jak zewnętrzne programy.

Zasady są takie same jak przy wykonywaniu polecenia bez potoku.
Niby czemu w potoku te zasady miałyby przeszkadzać, skoro nie
przeszkadzają gdy się nie tworzy potoku ?

Jeśli potokiem na poziomie N określimy:

polecenie 1 | polecenie 2 | ... | polecenie N

to zwykłe polecenie jest potokiem na poziomie 1. Dla potoku na
poziomie 1 nie obowiązują żadne inne reguły. Czy jest to jakaś
niespójność ?

[Lech Karol Pawłaszek]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo ">$LINE"; done < Stachu 'Dozzie' K.

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Ja tam za leniwy jestem. Do dziś na epsilonie używam tcsh tylko dlatego,
że nie chce mi się szukać jak w bashu zrobić tcshowe alt-p :-)

A co to robi? Ja ostatnio włączałem w zsh parę tcshellowych komend.

Coś jak tab-completion, tylko nie z filesystemu, tylko z historii.
Innymi słowy, jeśli przed chwilą uruchamiałem `./test.sh', po wpisaniu
kropki i naduszeniu alt-p dostanę właśnie `./test.sh'

Czyli coś w stylu jak w trybie emacs CTRL+R i napisanie kropki? :-)
Ciężko sobie wyobrazić efektywną pracę interaktywną bez tego (dla mnie
przynajmniej).

Post by Mariusz Kruk

Post by Stachu 'Dozzie' K.

Post by Mariusz Kruk
Za szybko przeczytałem, znaczy się :-)
A w takim razie "normalne" rurkowanie jak się dokonuje? Nie tworzy
potomka? Bo nie do końca rozumiem dlaczego ten nasz przykładowy skrypt z
tego wątku w zsh jednak działa inaczej.

Nie tworzy jeśli odbiorcą (ostatnim poleceniem w potoku) jest sam shell.

No to wolę chyba bashowe rozwiązanie. Przynajmniej jest spójne.

+1.

Pozdrawiam,