[ solved ] bash script anomalia

Fórumok

Sziasztok!

Van egy kicsi bash scriptem ami nem az elképzelésem szerint működik.
https://pastebin.com/cCGHmdHX

Ha a parancsokat begépelem a terminálba, akkor jól lefut.
pi@raspberrypi:~ $ workon
CCL_V4
coral
gopigo3
openvino
py3cv3
py3cv4

Ha a terminálba begépelt sorokat berakom a mytesting.sh scriptbe a megfelelő futtatási jogokkal és onnan futtatom, akkor hibát dob:
pi@raspberrypi:~ $ ./mytesting.sh
/home/pi
./mytesting.sh: sor: 8: workon: parancs nem található

Mit rontok el? Mit kéne az első sorba írni, hogy jól fusson a bash script?

Mindez, Raspberry pi 4b raspbian alatt történik.

Hozzászólások

terminálból aktiválódik, ott a zárójelben a prompt előtt látszik:

pi@raspberrypi:~ $ workon py3cv4
(py3cv4) pi@raspberrypi:~ $ 

és itt meg a virtuális környezet lezárása, vissztér a normál user szintre:

(py3cv4) pi@raspberrypi:~ $ deactivate
pi@raspberrypi:~ $ 

üdv: virtualm

Pont az első sorra nincs ötletem, de a `which workon` kimenete hasznos információt tartalmazhat.

A ~-od nincs benne egyik futtatási útvonalban sem. Mivel a workon parancsot a ~-ban adtad ki, ezért onnan lefut, de már a bash scripted nem találja. Csináltam én is egyet:

cat ./workon
echo Fghdsh2323h231l
$ ./workon
Fghdsh2323h231

Most figyelj!

$ cat ./workont_futtato_parancs
workon

ÉS:

./workont_futtato_parancs
./workont_futtato_parancs: sor: 1: workon: parancs nem található

ÁM, ha:

$ cat ./workont_futtato_parancs
/home/a_te_konytarad/workon

Akkor már:

$ ./workont_futtato_parancs
Fghdsh2323h231

Avagy vagy a workon-t futattó szkriptedbe beteszed a workon teljes elérési útját, vagy a workon-t beteszed a /usr/local/bin-be, ha a workonod nem feltételezi, hogy ~-ban van, és relatív útvonalakat használ fel onnan.
____________________

Szerk.: Nem kell figyelembe venned: most látom csak, hogy virtualenv is bezavarhat. Bár elég necces akkor is, hogy nem található a parancs.
A kör szűkítése érdekében tettél fel egy másik shell-t, vagy ha van fenn sh, azzal próbáltad?

READY.
󠀠󠀠‎‏‏‎▓
Szerkesztve: 2020. 05. 04., h – 13:28

Probald meg ezt miutan beleptel a python virtaulenv dir-be:

 

```bash

source ./env/bin/activate

```

 

Forras: https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/#activating-a-virtual-environment

 

 

Valoszinu azert fut le ha te futtatod a parancsot, mert ott a shell-ben mar letezik a "workon" function.

Miutan a `which workon` nem talalt semmit, probald meg a inkabb igy:

 

```bash
alias | grep workon

functions | grep workon

```

Ugyan nem tudom, miről van szó, de több problémát is sejtek. Először is nyomozd ki, hol van ez a workon:

which workon

vagy

type -p workon

Végső kétségbeesés esetén locate-tal is megkeresheted. Olyan nincs, hogy van valami a gépen, és nem tudod, honnan indul el.

A másik, hogy ha ez egy virtuális környezet, akkor az a gyanúm, hogy a workon nem tér vissza, hanem ő fut, s onnan egy saját shellt ad. Ha ez így van, akkor a deactivate tér csak vissza az eredeti shellhez, ami azt is jelenti, hogy amit a shell scriptedben leírtál, az a workon után nem fog lefutni, csak ha interaktív módon becsépelted azt, hogy deactivate. Viszont akkor meg lesz egy rakás hibaüzeneted, mert a shelled nem fogja érteni, mit akarsz tőle.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A kért kimenetek :

pi@raspberrypi:~ $ which workon
pi@raspberrypi:~ $ 

pi@raspberrypi:~ $ type -p workon
pi@raspberrypi:~ $ 

Jól mondod, a workon ez egy virtuális környezetet aktiváló parancs lenne, paraméterezve hívható, hogy melyik környezet legyen aktív.

----------------------------------------------

A csúfság az, hogy a tulajdonos "mester" https://www.pyimagesearch.com/ aki supportot igért az eladáskor, csak semmit mondó, udvarias választ adott a felvetett problémára. Adott egy egysoros scriptet amivel menni kellene:

A kapott start_py3cv4.sh script tartalma:

#!/bin/bash
echo "Starting Python 3.7 with OpenCV 4.1.1 bindings..."
workon py3cv4

Ez ugyanúgy hívná a workon környezetet az adott profillal, de nem találja, pedig ott van, futtathatóan.

pi@raspberrypi:~ $ ls -lA

-rwxrwxrwx  1 pi   pi      83 szept  3  2019 start_py3cv4.sh

pi@raspberrypi:~ $ start_py3cv4.sh
bash: start_py3cv4.sh: parancs nem található

Valószínű, hogy nálam van valami bibi, de nem tudom, hogy mi. A bash feldolgozás nem tetszik nekem.

üdv: virtualm

Ez nem DOS, az aktuális könyvtár nem része a PATH-nak. Indítsd így:

./start_py3cv4.sh

Már feltéve, hogy abban a könyvtárban vagy, amelyikben ez a script van. Ezen felül nézd meg, ez a workon nem egy alias esetleg, vagy nézd meg a telepítőjét, hova teszi. Ha ebben a scriptben annyi van, amennyit írtál, és az működik, akkor az a workon valahol van. Vagy a PATH-ban szereplő könyvtárak valamelyikében, vagy egy alias, vagy egy függvény. De valahol lennie kell.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Sajnos a bash script nem működik.

Ott vagyok a megfelelő könyvtárban, a script futtatható lenne:

pi@raspberrypi:~ $ ls -lA

-rwxrwxrwx  1 pi   pi      83 szept  3  2019 start_py3cv4.sh

pi@raspberrypi:~ $ start_py3cv4.sh
bash: start_py3cv4.sh: parancs nem található

-----------------------------------------------

újra letöltöttem és kiírtam az img fájlt egy másik SDcardra. Hasonlóan beteg a dolog.

pi@raspberrypi:~ $ ./start_py3cv4.sh
Starting Python 3.7 with OpenCV 4.1.1 bindings...
./start_py3cv4.sh: sor: 3: workon: parancs nem található

Ha a parancsokat terminálba begépelem azok működnek:
pi@raspberrypi:~ $ workon
coral
gopigo3
openvino
py3cv3
py3cv4

pi@raspberrypi:~ $ workon py3cv4
(py3cv4) pi@raspberrypi:~ $

pi@raspberrypi:~ $ workon py3cv4
(py3cv4) pi@raspberrypi:~ $ python3
Python 3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv2
>>> cv2.__version__
'4.1.1'
>>> 

A scripttel indított virtuális környezet nem áll fel.

Azt nem értem, hogy terminálba begépelve megy és ugyanaz bash alatt scriptben nem megy.
 

üdv: virtualm

Még azt tudom elképzelni, hogy már rég nem az eredeti bash fut, hanem egy másik shell, amelynek a workon egy belső parancsa. Azért az kinyomozható, hogy mi a shelled, mi az a workon, hol van. Az nem kérdezhető le, hogy mit és hova tett a telepítő, illetve mi a pre-install script, post-install script?

Olyasmire gondolok, mint például az

rpm -ql csomagnév

csak gondolom, neked nem rpm alapú rendszered van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, debian alapú, buster a raspbianom. dpkg -l |grep csomagnev - milyen csomagnevet keressek ? Egy előre telepített SDcardról beszélünk amin az alábbiak vannak :

raspbian ( boot és szokásos csomagjai )

python3.7

opencv3 - 4 (forrásból forditva)

a hozzájuk való csomagokkal, indító scriptekkel pl a fent emlitett egysoros ./start_py3cv4.sh

ezen kívül oktató anyagok, példa programokkal

https://www.pyimagesearch.com/2016/11/21/raspbian-opencv-pre-configured-and-pre-installed/

üdv: virtualm

De jó lenne tudni, hogy hol van 'definiálva' (*). Shell belső parancs, shell-függvény, shell alias, vagy valóban a PATH-ban van valahol.

(*) Azért lehet jó tudni, mert esetleg az egyéb hiányzó dolgok is ott vannak.

Igen, néztem és próbáltam,  balazs4 bocs, hogy nem reagáltam le időben. https://hup.hu/comment/2475736#comment-2475736

Ugyanúgy semmi:

pi@raspberrypi:~ $ alias | grep workon
pi@raspberrypi:~ $

--------------------------------------------------

pi@raspberrypi:~ $ functions | grep workon
bash: functions: parancs nem található

üdv: virtualm

A 'type -p' nem jó, mert az csak a PATH-ban keres. Sem a belső parancsok, sem a shell függvnyek, sem az aliasok listáját nem keresi végig. Szóval ha az a kérdés, hogy egy parancs hol a fenében van, akkor simán csak a

$ type parancs

a megfelelő megoldás.

A workon parancsot a "virtualenvwrapper" csomag hozza létre, bash function formájában.

Mégpedig úgy hozza létre, hogy ki kell adni a következő parancsot:

source /usr/share/virtualenvwrapper/virtualenvwrapper.sh

(debiánon. Más disztribben máshol lehet a virtualenvwrapper.sh)

Várhatóan ez a parancs benne van a .bashrc vagy .bash_profile vagy /etc/bash.bashrc vagy /etc/profile -ben, emiatt nem adtad ki még soha, mégi működik.

 

Ha egy parancsfile-ben ( pelda.sh) használod a workon parancsot, akkor két lehetőséged van:

1) A pelda.sh meghívása nem futtatás, hanem source legyen:

source pelda.sh

2) A pelda.sh második sorába helyezd el a 'source /usr/share/virtualenvwrapper/virtualenvwrapper.sh' parancsot.

 

Magyarázat:

a 'source' úgy futtatja a scriptet, hogy nem hoz létre neki subprocesst. A sima futtatás pedig létrehoz. Egy rakás változó, függvény nem öröklődik a subprocessbe. Ez is ilyen.

Fontos megkülönböztetni hogy nem a "terminálba" gépeled be a parancsot, hanem egy "login shellbe".

Nézz annak utána hogy a login shell pontosan mit jelent, miket futtat pluszban (.profile, .bashrc meg az abból kiinduló dolgok).

Amikor csak úgy indítasz egy (másik) shellt - mert ugye azt tudjuk hogy amikor csak úgy beírod hogy ./script.sh akkor a script.sh egy másik shellt indít és abban indul el a scripted, és az indító scriptből csak az exportált környezeti változókat veszi át pl.

Érdemes megnézni a "source" bash commandot - mert ez az aktuális shellben hajtja végre a scriptet azaz nem indít új shellt.

Gábriel Ákos

nagyonofftopic

A source parancs annyira bashizm, mint ide Lacháza. Tessék megtanulni helyette a . (azaz pont, dot) nevű parancsot. Mindent ugyanúgy kell vele használni, egyedül az írásmódja más, mert nem

 

source file.sh

hanem

. file.sh

Direkt ránéztem, ezt még (a manual szerint) a zsh is csak ebben az utóbbi formában ismeri. És ebben az a lényeg, hogy a . parancs az eredeti, Bourne-shell-beli írásmód, a source pedig a C-shell-beli utánérzés - amit persze bevittek az inkompatibilitás jegyében a bash-ba is. (Mivel a C-shell-ben kb minden komolyabb konstrukció más szintaxissal írandó, nem sok értelme volt, hisz nem igazán lehet olyan scriptet írni, ami fut mind a kettőben és az echo 'Hello, world!' -nél bonyolultabb.

/nagyonofftopic

Egy kis user kiegészítéssel tartozom nektek, a segítőimnek:

Mivel naponta, max 4 órát tudok foglalkozni a hobby projektemmel ezért vannak történések amik másnapra- harmadnapra tolódnak, esetleg elfelejtődnek. Az időm egy része, után olvasással telik, mert amiket kapok javaslatokat, megpróbálom megértve alkalmazni és a teszt eredményekről korrekt módon beszámolni. Ezen, elhúzódó teszt körülményekről írnék néhány gondolatot.

1 - Laptop- Debian alatt, kiírtam egy vásárolt, előtelepített img fájlt. ( Raspberry Pi4 hardverre készült )

2 - Első induláskor, alapvető setupok, honosítások, frissítések megtörténtek, minden rendben jól működött.

3 - A korábban Pi3- ra irt és jól működő bash scripjeimet és python forrásaimat áthoztam a Pi4- re és elkezdtem az új rendszert tesztelni.

4 - A kis python projektem ledeket és nyomógombokat kezel egy pici célhardveren. Korábban Pi3 volt a futtató hardver de teljesítmény igény miatt váltottam Pi4- re. Az alap op raspbian buster maradt, python3 és OpenCv modulokkal. A Pi3- ról simán, minden gond nélkül átköltöztem a Pi4- re. Teszt asztalon, műhelyben, monitorral, billentyűzettel minden ment mint a karikacsapás. Igen ám, de majd monitor nélkül és billentyűzet nélkül kell, hogy menjen a kis beágyazott rendszer. Ekkor kezdődtek a problémák. A "távoli" ssh kapcsolat jól, stabilan működött, de a monitor nélküli variációk nem akartak összejönni. Az egy külön fejezet volt és lesz még. A forrásból fordított és telepített dolgaim sem sikerültek úgy ahogy szerettem volna. Gondoltam, hogy egy forrásból fordított, optimalizált, előre telepített profi, gyári program csomaggal véget vetek a sok nyüglődésnek és végre az érdemi munkával foglalkozhatok nem a linux reszelésével töltöm a napjaimat. Igy esett a választásom a pyimageserch fizetős csomagjaira. Ennek használatának buktatóiba vontalak be benneteket evvel a poszttal.

5 - Az új rendszer legelső pythonos tesztjének indításkor nem tulajdonítottam jelentőséget annak a ma már nem elhanyagolható ténynek, hogy a billentyű és monitor nélküli teszt lefagyott. Akkor nem láttam az okát, de ma sejtem, mert több nap után, egy vadonat új redszerrel ( 1- 3 ) megísmétlődött és elcsíptem némi információt a kifagyott VNC képernyőből.  Ez a fagyás, haltba viszi az Rpi4 alaplapot. Az ujraindítások után az itt postolt bash anomáliák jöttek elő és többet nem tudtam odáig eljutni mint az egy héttel ezelőtti fagyásnál- haltnál. Az egyébbként terminálból begépelve működő parancsok a "gyárilag" és általatok is ajánlott módokon sem akartak működni. Erről szólt a post eleje. 

6 - Nem gondoltam volna, hogy a Pi3 és Pi4 hardveren jól működő python3 program ilyen bajt okoz ha egy profi virtuális környezet alatt, az előirt módokon futtatom. Most ott tartok, hogy localizáljam, bizonyítsam, megismételjem a hibát, hogy mi okozza a haltot és mi fossa össze úgy a rendszer azon részét ami ezt a bash anomáliát okozza.

Egyenlőre úgy néz ki, hogy a távoli gépen, virtuális környezetben futtatott python3 kód azon része ütközik valamivel ami a GPIO lábakat kezeli. Úgy tűnik mintha a virtuális környezet nélkül jól működő GPIO kód virtuális környezet alatt súlyos ( halt ) hibát okoz és ez megváltoztat valamilyen rendszer paramétereket. Úgy tűnik, mintha az alapgép használná a lábakat amiket a virtuális környezet is használni szeretne. Olyan mintha a GPIO lábkezelés nem virtualizálódna hanem külön életet élne, nem veszi át a lábak felügyeletét.

 

Bocsánat a hosszú postért, de ez így lett kerek. 

üdv: virtualm

Részleges sikereim vannak. Újra telepítettem, mentettem a pyimagesearch- tól vásárolt előtelepített Raspbian3_4.img csomagot. Igy most az eredetileg vásárolt, jó állapotú rendszerrel kisérletezhetem. Természetesen a szokásos frissítéseket elvégeztem. 

A jól működő, futtató bash script így néz ki:

#!/bin/bash
echo "Starting Python 3.7 with OpenCV 4.1.1 bindings..."
workon py3cv4
echo "jump work mapp..."
cd /home/pi/.virtualenvs/py3cv4
echo "call python3 testing.py"
python3 testing.py
echo "return home..."
cd ~
echo "workon py3cv4 deactivate"
deactivate

--------------------------------------------

meghívása pedig így néz ki:

pi@raspberrypi:~ $ source start_py3cv4.sh

--------------------------------------------

Amit futtatnék, az a saját, kicsi, egyszerű python3 kódom, a testing.py ami az 50. sorig jól fut, majd a GPIO lábak vezérlésekor haltba küldi a Raspberry Pi4- et. Tehát most már nem a bash anomáliával van dolgom, hanem a virtuális környezettel.

https://pastebin.com/St0g58qU A kód elején az importok és kiiratások jól működnek. Ha csak az 50. sorig futtatom akkor hiba nélkül lefut. Ez a kód nem virtuális környezetben, normál telepítésnél és normál futtatásnál jó lefut, virtuális környezetben katasztrófális HALT hibát okoz. A virtuális környezetben futó python alkalmazás GPIO része és elcsípett üzenete azt mondja, hogy a lábak foglaltak, valaki használja, ami nem igaz, mert szűz indítás után történik mindez.

A személyes problémám az, hogy én magam nem tudtam "jó" virtuális környezetet létrehozni, ezért vásároltam a profi program csomagot a pyimagesearch- től, ami miatt szomorú vagyok. Nem tudom, hogyan és mit kell tennem ahhoz, hogy a GPIO kezelés is jól fusson a virtuális környezet alatt. Semmi extra nincs a dologban, Raspberry Pi3- 4- re ajánlottak python- cv3- 4 program csomagot, oktatást, támogatást, de a dolgok betegen működnek, pontosabban mondva, nem működnek.

Mit ajánlotok, hogy a további boncolgatásához indítsak egy új python - virtualenvs - GPIO postot, vagy mehet ez itt tovább ?

üdv: virtualm

Én az egész problémát nem értem. Van egy R-Pi-d, ha jól értem. A GPIO lábait akarod piszkálni. Gondolom, van erre egy kernel hívás. Ráadásul azt írod, ez működik neked. Aztán valamit egyfajta virtuális rendszerben szeretnél, de ha jól értem, ez nem valódi, hardware virtualizáció. Miért? Mi ebben a jó? Miért nem futtatod a programod közvetlenül az R-Pi-n? Mi lenne, ha írnál C-ben, vagy akárhogy egy picike daemont, amelyik például egy named pipe-ban várná az adatokat, amit a GPIO-ra ír, aztán a virtuális rendszered ebbe a fifo-ba írna? Egyáltalán mi a cél? Nincs ez elbonyolítva? Egy mikrokontrolleren írok a portra, és az történik, amit szeretnék, aztán jól is van. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

root@rpi:/dev# ls -l /dev|grep -i gpio

crw-rw---- 1 root gpio    254,   0 Mar  7 03:17 gpiochip0

crw-rw---- 1 root gpio    254,   1 Mar  7 03:17 gpiochip1

crw-rw---- 1 root gpio    254,   2 Mar  7 03:17 gpiochip2

crw-rw---- 1 root gpio    248,   0 Mar  7 03:17 gpiomem

Gábriel Ákos

ezeket a virtuális környezetben adtam ki, mert ott jön a hiba:

(py3cv4) pi@raspberrypi:~ $ id
uid=1000(pi) gid=1000(pi) csoportok=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),105(input),109(netdev),997(gpio),998(i2c),999(spi)

(py3cv4) pi@raspberrypi:~ $ id pi
uid=1000(pi) gid=1000(pi) csoportok=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),105(input),109(netdev),999(spi),998(i2c),997(gpio)
(py3cv4) pi@raspberrypi:~ $ 
 

hol olvashatok ezek után, mert ez egy kicsit kínai : 997(gpio)

üdv: virtualm

A pi nevű felhasználónak ezek alapján van joga a gpio írására, olvasására. Minden parancsnak a man parancsnév paranccsal olvashatsz utána, a konkrét esetben:

man id

Már, ha jól értettem a kérdést. Lapozgatni page up, page down, fel, le nyilak, kilépés q, keresés /regexp.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ugyanezek, userként a virtuális környezetben:

(py3cv4) pi@raspberrypi:~ $  ls -l /dev|grep -i gpio
crw-rw----  1 root gpio    254,   0 máj    8 02:43 gpiochip0
crw-rw----  1 root gpio    254,   1 máj    8 02:43 gpiochip1
crw-rw----  1 root gpio    254,   2 máj    8 02:43 gpiochip2
crw-rw----  1 root gpio    247,   0 máj    8 02:43 gpiomem
(py3cv4) pi@raspberrypi:~ $

üdv: virtualm

root@raspberrypi:/home/pi# ls -l /dev|grep -i gpio
crw-rw----  1 root gpio    254,   0 máj    8 02:43 gpiochip0
crw-rw----  1 root gpio    254,   1 máj    8 02:43 gpiochip1
crw-rw----  1 root gpio    254,   2 máj    8 02:43 gpiochip2
crw-rw----  1 root gpio    247,   0 máj    8 02:43 gpiomem
root@raspberrypi:/home/pi# 
 

üdv: virtualm

Python virtualenv-ről van szó. Itt nem arról van szó hogy ez jó v nem jó, pythonban ez a módi. Van vele némi kínlódás. Ha emberünk kissé jobban benne lenne a témában akkor inkább a dockert javasolnám, az mégis sokkal több mindenre jó.

Mondjuk a megfelelő device-okat oda is be kellene tákolni, de ha egyszer jól összeraktál egy docker image-t meg egy compose-t az aztán bárhol elindul.

Gábriel Ákos

A jogokat teljesen kiterjesztettem, sem a pi user sem a root nem tudja jól futtatni a GPIO láb teszteket ebben a környezetben.

https://www.raspberrypi.org/downloads/raspbian/ buster desktop, python3 + opencv- vel jól működik, de itt a pyimagesearch alatt nem. A supportjuk udvariasan igérget, egyenlőre eredménytelen ötletekkel.

üdv: virtualm

A virtuális környezetben :

(py3cv4) pi@raspberrypi:~ $ sudo apt install rpi.gpio
Csomaglisták olvasása... Kész
Függőségi fa építése       
Állapotinformációk olvasása... Kész
Megjegyzés: „python-rpi.gpio-dbgsym” kijelölése „rpi.gpio” regexhez
Megjegyzés: „python3-rpi.gpio” kijelölése „rpi.gpio” regexhez
Megjegyzés: „rpi.gpio-common” kijelölése „rpi.gpio” regexhez
Megjegyzés: „python-rpi.gpio” kijelölése „rpi.gpio” regexhez
Megjegyzés: „python3-rpi.gpio-dbgsym” kijelölése „rpi.gpio” regexhez
rpi.gpio-common már a legújabb verzió (0.6.5-1).
python-rpi.gpio már a legújabb verzió (0.7.0~buster-1).
python-rpi.gpio-dbgsym már a legújabb verzió (0.7.0~buster-1).
python3-rpi.gpio már a legújabb verzió (0.7.0~buster-1).
python3-rpi.gpio-dbgsym már a legújabb verzió (0.7.0~buster-1).
0 frissített, 0 újonnan telepített, 0 eltávolítandó és 0 nem frissített.
(py3cv4) pi@raspberrypi:~ $ 
 

üdv: virtualm

Azt még mindig nem értem, hogy ha ez működik natívan, és nem működik ebben a pythonos virtuális környezetben, akkor miért akarod, hogy ebben működjön. Valahogy az az érzésem, hogy van egy nyitott ajtód, és a falon akarsz átmenni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A Raspberry Pi eszközökhöz adnak desktop szintű programokat. A sok marhaság mellett ami engem érdekel az a raspbian, python3. Már sok- sok hónapja ezen a "gyári" free környezeten barkácsolom a kisalkalmazásaimat, főleg picamera kezelést. Ezzel a gyári free összeállítással eljutottam egy működőképes szintre, de teljesítmény és hardver korlátokba ütköztem és emiatt kerestem a megoldásokat. A picamera mellett 3 db ledet és 5 db nyomógombot kell lekezelnem. A gyári free rendszerben, buster, geany, python3 alatt, saját telepítésű OpenCv rendszerrel ez kiválóan működik, de, és itt jöttek a problémáim.

Gyorsabban kellene, hogy menjen, monitor és billentyűzet nélkül kellene, hogy menjen ha már minden jól működik. Igen ám, de a fejlesztés jelen szakaszában még majdnem napi szinten kell a monitor, stb. Mivel a pythont is a linuxot is folyamatosan tanulom, ezért választottam egy olyan elérhető tanulási formát amiben a gyorsítás lehetősége is benne van és a különböző fejlesztői környezetek kialakítása is benne va. Igy esett a választásom a forrásból előtelepített optimalizált fejlesztői környezetre, a pyimagesearch kínálatában, kifejezetten a Raspberry lapka családra vannak előtelepített img fájlok a tanfolyami vevőik számára. Úgy éreztem, hogy ezt nekem csinálták és megvettem a csomagot, oktatást, támogatást.

A fizetés után egy másodperccel a hozzáférés működött. A támogatás pedig csak 1- 3 napos késéssel történő udvarias időtkérő levelezésben, ötletelésben kimerült. Egyenlőre elégedetlen ügyfélként probálok életet lehelni a "profi" rendszerbe.  

üdv: virtualm

„Ja, elvtársak, az élet nem egy habostorta!”

Az bármelyikünkkel megesik, hogy nem a feladattal foglalkozunk, mert előbb a fejlesztői környezetbe kellene életet lehelni. Ilyenkor keresgélni kell a neten, meg ahogy teszed is, fórumon kérdezni, hátha van valakinek ötlete. Pythont nem használtam, awk-t meg bash-t szoktam, ritkán C-t, illetve 8 bites mikrokontrolleren assembly-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerkesztve: 2020. 05. 08., p – 22:13

Most ott tartok, hogy féltem a Pi eszközömet a sok próbálozásból eredő fagyás miatt és a testing.py python programba tennek valami try - except kombót ha találnék rá valami GPIO error vagy I/O példát. Stringes és tömbös példákat talátam mint ötletet.

  try:
    v4="{[10]}"
    print (v4.format(cucc))
   except IndexError:
    print ('nincs ')
 

üdv: virtualm

Mit kell azon félteni? Csinálsz a flash eszközről egy szektor szintű mentést, a hardware-t meg szerintem nem tudod tönkretenni így. Bár nekem az is gyanús, hogy userspace-ből sima felhasználói joggal meg tudod fektetni a gépet. Nyilván nem akkor kell menteni, amikor a kártyáról fut az oprendszer, mert inkonzisztens lesz a másolat filerendszere, hanem offline egy PC-be dugott kártyaolvasó segítségével.
 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

De hogyan hal meg egy Linux userspace-ből? Nem lehetetlen, csak azért ez eléggé bug-gyanús. Mert ha a programodban hiba van, a kernelnek ki kellene vágni a fenébe, s vidáman működnie kellene tovább az oprendszernek. Védett mód meg ilyenek.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Bocsánat ha félreérthető voltam. nem igazi "fagyásról" vanszó, mert az igazándiból egy hurok valahol, hanem HALT- ba viszi a gépet, fentebb írtam is. Egy pillanatra felvillan a búcsúzó képernyő amin lefutnak dolgok és utána a lekapcsolást követően rendesen tudok gépet indítani. 

szerkesztve:

Igaz, hogy ez az indulás már más képernyővel indul, mert gondolom, hogy regisztrálta, hogy bibi volt a kiszálláskor és másképpen indul, de indul.

üdv: virtualm

Köszönöm, na ebből van egy hatalmas lista. Ebből egy példa:

pi@raspberrypi:~ $ last -x |grep shutdown
shutdown system down  4.19.97-v7l+     Fri May  8 02:43 - 01:00 (-18390+00:43)

szerkesztve:

és ebből is van bőven:

pi@raspberrypi:~ $ last reboot
reboot   system boot  4.19.97-v7l+     Thu Jan  1 01:00   still running
reboot   system boot  4.19.97-v7l+     Thu Jan  1 01:00 - 02:43 (18390+00:43)
 

üdv: virtualm

Korábban csináltam a másik SDcardon kernel frissítést, de ezen nem mert a support most is kért infót a telepített csomagokrók és nem akartam azt, hogy ne az Ő általuk tesztelt, forgalmazott környezet legyen, tehát nem akartam kifogást teremteni a rossz működésre. De ha gondolod az egyik klónon megpróbálhatom újra.

Ma például ez kellett nekik, ezt kérték:

(py3cv4) pi@raspberrypi:~ $ pip freeze
absl-py==0.8.0
astor==0.8.0
beautifulsoup4==4.8.0
boto==2.49.0
boto3==1.9.230
botocore==1.12.230
certifi==2019.6.16
chardet==3.0.4
Click==7.0
click-datetime==0.2
colorzero==1.1
cycler==0.10.0
Cython==0.29.13
dask==2.4.0
decorator==4.4.0
dlib==19.17.0
docutils==0.15.2
dropbox==9.4.0
face-recognition==1.2.3
face-recognition-models==0.3.0
Flask==1.1.1
gast==0.2.2
google-pasta==0.1.7
gpiozero==1.5.1
grpcio==1.23.0
gTTS==2.0.4
gTTS-token==1.1.3
h5py==2.10.0
idna==2.8
imageio==2.5.0
imutils==0.5.3
itsdangerous==1.1.0
Jinja2==2.10.1
jmespath==0.9.4
joblib==0.13.2
JSON-minify==0.3.0
Keras==2.3.0
Keras-Applications==1.0.8
Keras-Preprocessing==1.1.0
kiwisolver==1.1.0
mahotas==1.4.7
Markdown==3.1.1
MarkupSafe==1.1.1
matplotlib==3.1.1
networkx==2.3
numpy==1.17.2
pantilthat==0.0.7
picamera==1.13
Pillow==6.1.0
progressbar2==3.46.0
protobuf==3.9.1
pyHS100==0.3.5
PyJWT==1.7.1
pyparsing==2.4.2
PySocks==1.7.0
pytesseract==0.3.0
python-dateutil==2.8.0
python-utils==2.3.0
pyttsx3==2.71
pytz==2019.2
PyWavelets==1.0.3
PyYAML==5.1.2
pyzbar==0.1.8
pyzmq==18.1.0
requests==2.22.0
RPi.GPIO==0.7.0
s3transfer==0.2.1
scikit-image==0.15.0
scikit-learn==0.21.3
scipy==1.3.1
sh==1.12.14
six==1.12.0
soupsieve==1.9.3
subprocess32==3.5.4
tensorboard==1.13.1
tensorflow==1.13.1
tensorflow-estimator==1.14.0
termcolor==1.1.0
tinydb==3.14.1
twilio==6.30.0
typing==3.7.4.1
urllib3==1.25.3
Werkzeug==0.15.5
wrapt==1.11.2
zmq==0.0.0

üdv: virtualm

Most mindent frissítettem, a kernelt is, de a helyzet változatlan, a GPIO elérés nem működik a virtualenv alá forrásból telepített, optimalizált, megvásárolt csomagokkal. ( kissé elégedetlen vagyok )

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.4.35-v7l+ #1314 SMP Fri May 1 17:47:34 BST 2020 armv7l GNU/Linux

üdv: virtualm

ebből lehet valami okosat kiszedni ?

pi@raspberrypi:~ $ journalctl
-- Logs begin at Fri 2020-05-08 02:43:25 CEST, end at Sat 2020-05-09 00:14:37 CE
máj 08 02:43:25 raspberrypi kernel: Booting Linux on physical CPU 0x0
máj 08 02:43:25 raspberrypi kernel: Linux version 4.19.97-v7l+ (dom@buildbot) (g
máj 08 02:43:25 raspberrypi kernel: CPU: ARMv7 Processor [410fd083] revision 3 (
máj 08 02:43:25 raspberrypi kernel: CPU: div instructions available: patching di
máj 08 02:43:25 raspberrypi kernel: CPU: PIPT / VIPT nonaliasing data cache, PIP
máj 08 02:43:25 raspberrypi kernel: OF: fdt: Machine model: Raspberry Pi 4 Model
máj 08 02:43:25 raspberrypi kernel: Memory policy: Data cache writealloc
máj 08 02:43:25 raspberrypi kernel: cma: Reserved 256 MiB at 0x000000001ec00000
máj 08 02:43:25 raspberrypi kernel: On node 0 totalpages: 966656
máj 08 02:43:25 raspberrypi kernel:   DMA zone: 1728 pages used for memmap
máj 08 02:43:25 raspberrypi kernel:   DMA zone: 0 pages reserved
máj 08 02:43:25 raspberrypi kernel:   DMA zone: 196608 pages, LIFO batch:63
máj 08 02:43:25 raspberrypi kernel:   HighMem zone: 770048 pages, LIFO batch:63
máj 08 02:43:25 raspberrypi kernel: random: get_random_bytes called from start_k
máj 08 02:43:25 raspberrypi kernel: percpu: Embedded 17 pages/cpu s36928 r8192 d
máj 08 02:43:25 raspberrypi kernel: pcpu-alloc: s36928 r8192 d24512 u69632 alloc
máj 08 02:43:25 raspberrypi kernel: pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
máj 08 02:43:25 raspberrypi kernel: Built 1 zonelists, mobility grouping on.  To
máj 08 02:43:25 raspberrypi kernel: Kernel command line: coherent_pool=1M 8250.n
máj 08 02:43:25 raspberrypi kernel: Dentry cache hash table entries: 131072 (ord
máj 08 02:43:25 raspberrypi kernel: Inode-cache hash table entries: 65536 (order
máj 08 02:43:25 raspberrypi kernel: Memory: 3552864K/3866624K available (8192K k
lines 1-23
 

üdv: virtualm

Nem kényelmes vagyok hanem tudatlan. Mindent javaslatnak utána olvasok és megpróbálom hasznosítani. Amúgy köszönöm a segítséget, tényleg igazán rendesek és türelmesek vagytok egy 66 éves nyugdíjassal aki nem programozó és nem linux rendszergazda, de igyekszem azzá lenni.

üdv: virtualm

Azt látom, hogy nyafog valami gopigo3 modulért, ami éppen pythonos, és talán valami picike robot távirányítósdi lesz. Hogy ne tegye, gondolom, le kellene állítani valami ehhez tartozó szolgáltatást, vagy uninstallálni kellene valamit, nem tudom. Bár ez lehet mellékszál, mert nem feltétlenül ez a bajod.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez a gopigo modul (és az összes egyéb python modul ami a kód eredeti futtatásához kell) fel lett installálva a virtualenv alá?

Akkor lesz szép a baleset ha kiderül, hogy:

- valamelyik modul nem kompatibilis a python verzióval amelyik a virtualenv alatt van

- valamelyik modul nem kompatibilis a virtualenv -el

Bónusz kérdés: ugye mindegyik modul python3 -as?

Gábriel Ákos

Az eredeti "gyári" installálást a pyimageserch csinálta és adta el. Az én ismereteim szerint a modulok fent vannak. A kompatibilitásról nem tudok mondani semmit, csak annyit, hogy az én általam telepített python3 + opencv combón működik a GPIO vezérlés. A virtualenv alatt meg nem. Igen minden python3 alatt kell, hogy menjen.

üdv: virtualm

Off: Gondolom az egész kavaras célja az, hogy a hadvert ne C-ben kelljen programozni, ami nehéz, hanem Pythonban, ami könnyű.

Off: Az egész kavarás célja az, hogy a projekt működjön. 

A picamera kezelésére pythonos kódok elérhetőek és avval tanultam meg, hogy a programnak mit miért, hogyan kéne csinálni, hogy a kimenete valóban jó legyen, mert a futási tesztek közben kiderültek "apróságok" amik nem voltak publikálva. Ezeken a teszt módosításokon, egyértelműen könnyeb volt átlendülni a python segítségével. Mivel C- ben, majdnem mindent meglehet csinálni ezért végső esetben majd ezt is, de a pythonos fejlesztés, elsőre gyorsabb és könnyebb volt. Nem  mazohista vagyok hanem csak egy user vagy egy luser. Ezt http://www.geofizika.uni-miskolc.hu/Oktatok/vass/Kernighan_C_programoz%C3%A1si_nyelv.pdf elovasva egyenlőre maradtam a pythonnál. Ráadásul, nagyon sok pythonos baráti segítséget is kaptam a https://www.interkonyv.hu/konyvek/koos_antal_python_a_gepben szerzőjétől, amit ajánlok figyelmetekbe.

üdv: virtualm

Indítsd a scripted vagy rendszergazdaként vagy gpio júzerrel vagy csoporttal.

Szerintem a legegyszerűbb workaround hogy a shebang-be berakod a -l.

Kezd így a scriptet:

#!/bin/bash -l

Van egy olyan lehetőség, hogy átbogarászod, mit csinál az a workon() függvény, ha már éppen bash-ben van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mi lett a megoldás?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Több apró lépés volt a megoldás, nem egy nagy kulcsfontosságú esemény.

Amiket tettem: 

1 - kernel frissítés, "mert őskövület volt"

2 - a pyimagesearch supporttal való egyeztetés során kiderült, hogy az sh fájlom meghívása a sourcel ajánlott

3 - amikor már működött a bash script akkor kiderült, hogy valami csúnya ütközés van a háttérben a GPIO kezelésben

4 - külön szálat indítottam a GPIO probléma feltárására

5 - a virtualenv alól kiköltöztem és egy új telepítésre forrásból fordítottam az opencv csomagokat

6 - a pyimagesearch support felé dokumentáltam a programjukban lévő ütközést, törést, haltot.

7 - a tudatlanságom folyamatos leküzdése, következetes tesztelés és dokumentálás, mi jó, mi nem jó, stb

8 - mindezek a folyamatos hup.hu fórum használat és google- man oldalak olvasása közben.

üdv: virtualm