Gabucinonak szeretettel

 ( hrgy84 | 2015. március 24., kedd - 9:15 )

Meg mindenki masnak, aki szereti:

https://bugzilla.redhat.com/show_bug.cgi?id=1202858

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

>pidfile

daemontools kedveli ezt

klassz

az igen :D

Nájsz :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

nemide

-pilisig-

tabzs :D

Ne baszogasd a squidet, mert rohadtul megsértődik és viszi a disket.
Visszasírjuk még a Debian SSL fiaskót, ott jó esetben csak ellopták az adatot nem pedig elfüstölték. :D

-pilisig-

Ennyit a hiperszuper Enterprise Linux minőségbiztosításáról.

"Hello,

package containing this bug has never been released.

Cheers,

Pavel"

--
arch,debian,openelec,android

Ez egy fejlesztői - még nem is beta - verzió.

Láttam, akkor is nevetséges.

Tudjuk, te hibátlanul és papíron kódolsz. Nevetséges pedig véletlenül sem vagy.

Tudod, én nem vagyok fejlesztő, mégsem követek el ilyen bakikat. Másmilyeneket tucatjával, de ilyet eddig még nem sikerült.
--
Blog | @hron84
Üzemeltető macik

Tudjuk. Hidd el, tudjuk.

:)

Lehet, hogy épp azért mert nem vagy fejlesztő, nem?

Rendszerint ha rm -Rf "$var" szeru dolog kerul egy scriptbe akkor en is ovatosabb vagyok a szokotnal.

Utoljara hasonlo balfaszsagot 20 eve kovettem el, fat -al es disk-hez kotodo rendszerhivasokkal jatszottam DOS -on, egyszer veletlenul az mbr-tol keztem irtni a hard disket a floppy helyett, hiaba `figyeltem`.
Azota vagyok meg ovatosabb.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mikor rm-et látok kipróbálom. rm -f vagy -r esetén pedig legalább 3x megnézem és végiggondolom hogy mit is csinálok, honan fut az a cucc, stb.

Masszív adatvesztést életemben 1x sikerült okozni, 1x pedig közel voltam. Egyik sem törlés eredménye volt.

A hiba pedig nem "kódolás" eredménye.

Fejlesztő programnyelvet ír, nem shell scriptet. :)

restart() {
	stop
	RETVAL=$?
	if [ $RETVAL -eq 0 ] ; then
		rm -rf $SQUID_PIDFILE_DIR/*
		start
	else
		echo "Failure stopping squid or stopping squid took too long. Please check before restarting."
		return 1
        fi
}

rm ne legyen már script-ben, leszarom hogy mi az oka :)

Torolj egy pidfajlt rm nelkul kerlek.
--
Blog | @hron84
Üzemeltető macik

unlink pidfile

Es az unlink abban kulonbozik az rm-tol, hogy...
--
Blog | @hron84
Üzemeltető macik

Hogy elolvasod a man paget es rájössz. Sokban.

Segítek: http://linux.die.net/man/1/unlink

hogy nem rekurzív? és hogy nem töröl könyvtárakat?

^lelőtte^

genya vagyok, na. (meg otthagyom a tabot, amibe írok sokáig)

Amellett, hogy nem nezte meg, van-e ertelmes tartalma a valtozonak, meg arrol sem hallott ez a verzenyzo, hogy mondjuk szokoz is lehet konyvtar ill. filenevben. Egyszer ezt mindenki megszivja, es utana rajon, hogy a quoting nem viccbol lett kitalalva.

Jumping the bumblebee... ha az a bug még ismerős valakinek.

Meg OS X-en volt valami olyan, hogy vendég viókkal belépve vitte az adatokat? Vagy hasonló.. ;)

amit szintén egy linuxmániás szerencsétlen gányolt össze

;] trey harder