Lanciare un programma esterno, dentro un programma Java, sotto Linux
Rain
Nel mio programma Java ho necessità di eseguire un altro programma esterno
mediante una stringa di comando.
Sotto Windows, poichè il percorso contiene cartelle con degli spazi, è
necessario includere la stringa di comando tra doppi apici.
Fin qui tutto bene e infatti il programma sotto Windows ha girato
perfettamente, compreso lanciare il programma esterno.
Tuttavia sotto Linux la cosa non funziona. Premesso che non conosco quasi
per niente questo SO, volevo sapere da voi: esiste una qualche istruzione
Java (tipo il File.separator per quanto riguarda la separazione del path)
per risolvere questo problema?
Beh... qualcuno di voi in effetti potrebbe dirmi: ma sotto Linux non sono
ammessi percorsi con spazi. Vero (o almeno mi pare così). Ma Linux è in
grado di leggere il filesystem di Windows e pertanto potrei dire al
programma di cercare quel file esterno su quella partizione!
Ringrazio anticipatamente tutti coloro che mi risponderanno.
--
*Rain*
«Il cuore ha le sue ragioni che la ragione non conosce.»
[Blaise PASCAL]
Gian Uberto Lauri
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "R" == Rain <*****@*********.*> writes:
R> istruzione Java (tipo il File.separator per quanto riguarda la
R> separazione del path) per risolvere questo problema?
Se hai usato i backslash ovvio che non funziona. I backslash in Unix
servono per l'escaping dei blank (che sono tra i caratteri usati come
separatori di token nella shell - voglio vedere come se la cavano ad
implementare una shell quelli di Microsoft se non fanno la stessa
cosa...) o altri caratteri speciali.
--
/\ ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
//--\ | | \| | Integralista GNUslamico
\/ e allevatore di bug da competizione
Rain
(sa...@spammer.impiccati.it) che sembrerebbero provenire da
<87br1ec...@paperoga.gianoziaorientale.it>, il cui significato rimane
ancora un mistero:
> Se hai usato i backslash ovvio che non funziona. I backslash in Unix
> servono per l'escaping dei blank (che sono tra i caratteri usati come
> separatori di token nella shell - voglio vedere come se la cavano ad
> implementare una shell quelli di Microsoft se non fanno la stessa
> cosa...) o altri caratteri speciali.
In realtà non ho fatto proprio così.
Espongo brevemente cosa fa il programma.
A seguito di un doppio click su una JList viene lanciato un player che si
prende in carico di riprodurre un file indicato nella JList stessa.
Il percorso del player viene estratto da un file INI di configurazione e
pertanto è conforme allo standard del SO in uso (perchè nel file INI questo
viene scritto così!!).
Per quanto riguarda il file da riprodurre esso si trova nella partizione
dove risiede Windows e il programma, girando sotto Linux, lo cerca lì.
La stringa di comando che genero è quindi la seguente (sotto Linux):
percorsoPlayer/player "percorsoClip/nomeFile.mp3"
dove
percorsoPlayer ---> risiede sulla partizione in cui gira Linux
percorsoClip/nomeFile.mp3 ---> risiede sulla partizione in cui è
installato Windows
Voglio sottolineare che "percorsoClip/nomeFile.mp3" è formattato proprio dal
SO, in quanto, così come avviene per il player, anche la cartella in cui
cercare gli MP3 è scritta in un file INI che popolo prima dell'esecuzione
del programma.
Tuttavia, nonostante la formattazione dei path sia conforme allo standard
del SO in uso, il problema credo che risieda nei doppi apici.
Sapete aiutarmi?
Gian Uberto Lauri
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "R" == Rain <*****@*********.*> writes:
R> percorsoPlayer/player "percorsoClip/nomeFile.mp3"
Eseguita da shell che risultato da ?
In java a chi la dai in pasto ?
R> percorsoPlayer ---> risiede sulla partizione in cui gira Linux
R> percorsoClip/nomeFile.mp3 ---> risiede sulla partizione in cui è
R> installato Windows
Immagino che la partizione di windows sia correttamente montata e
leggibile all'utente che lancia l'applicazione.
R> il problema credo che risieda nei doppi apici. Sapete aiutarmi?
Non mi parrebbe. In Unix (e quindi in Linux) un comando della forma
comando "questo qui è un solo parametro"
assegna al primo parametro del programma (argv[1] o $1 se è uno
script) l'intera stringa "questo qui è un solo parametro" ed è una
delle tecniche con cui si indicano i nomi di file contenenti un blank.
Rain
(sa...@spammer.impiccati.it) che sembrerebbero provenire da
ancora un mistero:
> Immagino che la partizione di windows sia correttamente montata e
> leggibile all'utente che lancia l'applicazione.
Ovviamente. ;-)
Allora... ho debuggato il programma ed ho ottenuto i seguenti risultati.
Premetto subito che il sistema Linux è quello fornito da KNOPPIX v4.0 e,
sotto Windows, il programma funziona correttamente.
La stringa di comando che genero è la seguente:
(1) "/KNOPPIX/usr/bin/xine" "/mnt/hda2/Prova/prova.mp3"
Ovviamente *xine* legge anche gli MP3!!!
Sottolineo il fatto che lanciando la (1) dalla bash funziona tutto OK.
Lanciando la (1) dal programma, invece, ottengo un NullPointerException. Di
seguito lo stack trace:
java.io.IOException: java.io.IOException: "/KNOPPIX/usr/bin/xine": not found
at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
at java.lang.ProcessImpl.start(ProcessImpl.java:65)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
at java.lang.Runtime.exec(Runtime.java:591)
at java.lang.Runtime.exec(Runtime.java:429)
at java.lang.Runtime.exec(Runtime.java:326)
at DoppioClick.mouseClicked(DoppioClick.java:36)
at
java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:212)
at java.awt.Component.processMouseEvent(Component.java:5491)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
at java.awt.Component.processEvent(Component.java:5253)
at java.awt.Container.processEvent(Container.java:1966)
at java.awt.Component.dispatchEventImpl(Component.java:3955)
at java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3803)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:3901)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
at java.awt.Container.dispatchEventImpl(Container.java:2010)
at java.awt.Window.dispatchEventImpl(Window.java:1774)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Come è possibile se su Windows funziona tutto correttamente?
In ogni caso, grazie mille per l'aiuto. :-)
Gian Uberto Lauri
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "R" == Rain <*****@*********.*> writes:
R> (1) "/KNOPPIX/usr/bin/xine" "/mnt/hda2/Prova/prova.mp3"
Non ha nulla di particolare, salvo /KNOPPIX .
Al momento non ho il tempo per far partire la Knoppix da CD, ma il
fatto che l'eccezione sia
R> java.io.IOException: java.io.IOException: "/KNOPPIX/usr/bin/xine":
R> not found at java.lang.UNIXProcess.<init>(UNIXProcess.java:148) at
mi muoverebbe a vedere cosa è /KNOPPIX. Il problema non è legato a Java.
Tra l'altro, se /KNOPPIX/usr/bin è contenuta in $PATH non dovrebbe essere
necessario dare il path completo...
Gian Uberto Lauri
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "R" == Rain <*****@*********.*> writes:
R> (1) "/KNOPPIX/usr/bin/xine" "/mnt/hda2/Prova/prova.mp3"
Provato adesso e non mi da quella eccezione. Ma la stringa che passi a
exec() quale č ?
Rain
(sa...@spammer.impiccati.it) che sembrerebbero provenire da
ancora un mistero:
>> (1) "/KNOPPIX/usr/bin/xine" "/mnt/hda2/Prova/prova.mp3"
>
> Provato adesso e non mi da quella eccezione. Ma la stringa che passi a
> exec() quale è?
Esattamente quella che vedi mediante l'istruzione
Runtime.getRuntime().exec(command);
dove command è uguale alla (1).
Comunque, ora non posso nemmeno fare altri test perchè non ho il CD di
KNOPPIX (ce l'ho a casa).
Mi sta venendo il sospetto che non si tratti di un problema di Java, dato
che KNOPPIX è un po' particolare visto che carica le cose su ramdisk.
Il fatto è che però tu mi stai dicendo che hai appena fatto la prova e ti
funiona......... Mah....
Quando torno a casa stasera vedrò che accidenti può essere.
Gian Uberto Lauri
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "R" == Rain <*****@*********.*> writes:
R> Durante un sopralluogo, trovai dei geroglifici incisi da *Gian
R> Uberto Lauri* (sa...@spammer.impiccati.it) che sembrerebbero
R> provenire da <87acgwm...@paperoga.gianoziaorientale.it>, il cui
R> significato rimane ancora un mistero:
>>> (1) "/KNOPPIX/usr/bin/xine" "/mnt/hda2/Prova/prova.mp3"
R> dove command è uguale alla (1).
Io ho usato "/KNOPPIX/usr/bin/xine /mnt/hda2/Prova/prova.mp3" passato
alla exec(String comando).
A quanto pare se tu invece passi "\"/KNOPPIX/usr/bin/xine\"
\"/mnt/hda2/Prova/prova.mp3\"" alla exec() di Linux arriva
"/KNOPPIX/usr/bin/xine" e non /KNOPPIX/usr/bin/xine causando l'errore.