Auto mounting/unmounting CD-ROM

[nuitari]

Ho appena finito la stesura di un nuovo articolo sull'auto mounting/unmounting dei CD-ROM.

Ditemi pure che ne pensate

http://www.slacky.eu/wikislack/index.ph ... unmounting

[nuitari]

ops avevo fatto qualche errorino, sistemato

[conraid]

Ho appena finito la stesura di un nuovo articolo sull'auto mounting/unmounting dei CD-ROM.

Ditemi pure che ne pensate

http://www.slacky.eu/wikislack/index.ph ... unmounting

Buono... una domanda.
Questo metodo entra in conflitto con l'automount di KDE?

[nuitari]

come ho scritto nell'articolo, assolutamente no, è quella la figata. s'integra perfettamente con HAL e tutto quello che ne consegue. Inoltre non va in conflitto nemmeno con altri eventuali programmi/comandi di automounting, in quanto tra la rilevazione del device ed il suo mount fa passare 3 secondi per permettere ad altri software eventuali di fare il mounting al posto suo

[conraid]

come ho scritto nell'articolo, assolutamente no, è quella la figata. s'integra perfettamente con HAL e tutto quello che ne consegue. Inoltre non va in conflitto nemmeno con altri eventuali programmi/comandi di automounting, in quanto tra la rilevazione del device ed il suo mount fa passare 3 secondi per permettere ad altri software eventuali di fare il mounting al posto suo

Interessante, lo proverò.
Grazie dell'how-to

[nuitari]

dovere / piacere

[nuitari]

Ho notato che la configurazione di IVMAN che ho suggerito non funziona un granchè bene, perchè prendeva in considerazione solo di volumi di tipo cd_rom (quindi non gli rw, non i dvd, etc).

Ho aggiornato l'articolo mettendo una configurazione migliore, che prende in considerazione tutti i dispositivi ottici con l'esclusione di quelli non masterizzati.

http://www.slacky.eu/wikislack/index.ph ... unmounting

Ho anche messo il percorso su dove attingere la documentazione dei namespaces HAL

[nuitari]

Ho corretto la riga da inserire in rc.local, era sbagliata

[Mario Vanoni]

Ho corretto la riga da inserire in rc.local, era sbagliata :p

Ottimo lavoro, congrats!

Ma 'sta riga e` veramente corretta?

Ai tempi era "commando > dove_vuoi 2>&1"
man bash: order of redirection

Mario Vanoni

[Paoletta]

da man bash:

Note that the order of redirections is significant. For example, the
command

ls > dirlist 2>&1

directs both standard output and standard error to the file dirlist,
while the command

ls 2>&1 > dirlist

directs only the standard output to file dirlist, because the standard
error was duplicated as standard output before the standard output was
redirected to dirlist.

nuitari correggi la riga!

[nuitari]

Er... posso anche cambiarla, ma funziona in entrambi i modi...

Se faccio il redirect di stderr in stdout e poi redirecto stdout su un file, il risultato dovrebbe essere esattamente lo stesso, per quanto cambi il significato....

[Mario Vanoni]

Er... posso anche cambiarla, ma funziona in entrambi i modi...

Se faccio il redirect di stderr in stdout e poi redirecto stdout su un file, il risultato dovrebbe essere esattamente lo stesso, per quanto cambi il significato....

Ha ragione Paoletta, quindi resta _sempre_ _Bourne_ _Shell_ _Compatible_,
bash/ksh/tcsh/zsh ecc. usano la stessa sintassi,
non metterti nei pasticci con i possibili _porting_ su altre piattaforme, per favore!

Mario Vanoni

[nuitari]

Ehe ok, in onore della compatibilità ho già fatto la correzione ^^
comunque quel che dice il quote di paoletta è che l'ordine degli operatori cambia il *siginficato*, ma nel caso specifico non il risultato. Od ho capito male? A me sembra di no.. Se come dice il quote stderr viene duplicato su stdout prima che stdout venga reindirizzato sul file, a conti fatti ho l'output di entrambi gli stream sul file..

[Mario Vanoni]

Ehe ok, in onore della compatibilità ho già fatto la correzione ^^
comunque quel che dice il quote di paoletta è che l'ordine degli operatori cambia il *siginficato*, ma nel caso specifico non il risultato. Od ho capito male? A me sembra di no.. Se come dice il quote stderr viene duplicato su stdout prima che stdout venga reindirizzato sul file, a conti fatti ho l'output di entrambi gli stream sul file..

Sempre in primo posto la compatibilita`, non mondo M$, ma mondo UNIX p.f.!

La sottile differenza e` questa:

ls file_non_esistente > questo_test 2>&1
# nessun messaggio di errore a livello shell, va nel file!
less questo_test
ls: cannot ...

ls file_non_esistente 2>&1 > questo_test
ls: cannot ...
# l'errore di stderr viene mandato subito su stdout
less questo_test
niente, _vuoto_!

Sorry, finezze/pregi del mondo UNIX, devi conviverci.

Mario Vanoni

[nuitari]

Ok, allora non è assolutamente uguale, anzi. Meglio ancora quindi che abbia corretto la riga, perchè l'altra sintassi È a tutti gli effetti sbagliata.

Grazie dell'hint, non si finisce mai d'imparare