Ricevere info dal terminale

[Ceskho]

Come faccio a sapere che il terminale a finito di eseguire il comando che io avevo chiesto di fare?

io faccio così, non sò se sia la soluzione migliore però funziona :

Codice: [Seleziona]

PUBLIC SUB abc()
SHELL "comando" FOR INPUT OUTPUT AS "processo"
ENDIF

PUBLIC SUB processo_read()
'quello che verrebbe scritto sul terminale
DIM riga AS String
LINE INPUT #LAST, riga 'fai quello che vuoi con "riga"
textarea1.text &= riga & gb.newline ''>>>>>>>>>modifica per cescko
END

PUBLIC SUB processo_error(testo_errore AS string)
'il testo dell errore è quello tra parentesi .... non sò xchè
end

PUBLIC SUB processo_kill() 
'quello che serve a te
END

Sarebbe meglio postare all'interno di un altro topic già riguardante argomenti simili secondo mè .....

[leo72]

Codice: [Seleziona]

SHELL "comando" WAIT

L'aggiunta di WAIT forza Gambas ad attendere l'esecuzione del programma lanciato da terminale.
Un modo più complesso è quello di assegnare il processo lanciato da Shell ad un oggetto di tipo PROCESS e poi gestirlo tramite eventi.

[Ceskho]

Scusa leo ma perchè il tuo comando blocca anche i comandi che do prima..

Ti faccio un esempio...io voglio che il mio software prima apre un form e poi esegue un comando:

Codice: [Seleziona]

FForm.Show
SHELL comando WAIT

Il problema è che prima esegue il comando e poi quando ha finito apre il form...perchè?

[leo72]

Il problema da te riscontrato dipende dalla gestione della GUI di Gambas. In genere gli aggiornamenti delle finestre vengono fatti "un po' alla volta" e mai nell'istante esatto in cui vengono richiesti.

Ciò si può facilmente vedere in casi come quello da te descritti oppure ad esempio durante l'esecuzione di complessi calcoli con una ProgressBar che avanza per visualizzare lo stato del processo: in questo caso la finestra si freeza, finendo per essere aggiornata solo al termine dei calcoli.

Per evitare ciò basta mettere, sotto ai comandi che aggiornano elementi grafici quali widget vari o la stessa finestra, un bel

Codice: [Seleziona]

WAIT

oppure

Codice: [Seleziona]

WAIT 0.1

Il comando WAIT forza Gambas ad eseguire l'aggiornamento della GUI. Un eventuale numero dopo il comando indica invece un'attesa che deve essere minimo pari al valore impostato che esprime il tempo in secondi (quindi 0.1 equivale a 100 ms) e forza, inoltre, Gambas a leggere eventuali tasti premuti dall'utente, a leggere gli spostamenti ed i click del mouse.

Quindi, io metterei:

Codice: [Seleziona]

FForm.Show
WAIT 0.1
SHELL comando WAIT

[Ceskho]

avevo pensato alla stessa cosa solo che io avevo inserito WAIT 0.2 e stranamente il tutto si bloccava mentre con WAIT 0.1 non accade...mah!!!
Comunque grazie comunque...mi hai dato una bella spiegazione...

[Ceskho]

continuo qui:

@ giac_fab mi spiegheresti meglio per favore processo_read()?
Mi servirebbe avere in una textarea quello che restituisce il terminale...ho provato ovviamente con

SHELL comando To stringa

ma non mi restituisce nulla...penso che il problema sia dovuto al fatto che tramite terminale richiamo un programma.

Modificato il mio primo post

Sonstanzialmente apri un processo (SHELL) e lo lasci in background a far tutte le sue cose.

Questo processo avrà come riferimento "processo" (o quello che vuoi, dichiarato tramite AS "xyz" ).

Tramite la funzione _read _kill _error ti leggi ciò che stà facendo il processo in background.

Attenzione che il read legge SOLAMENTE l'output normale del programma, quindi se crasha o ha problemi devi gestire _error e _kill per renderti conto di cosa succede.

Comunque se guardi nella guida è stranamente ben spiegato questo passaggio.

[Ceskho]

ma il problema lo sai qual'è? io riverso il comando shell su una stringa con

SHELL comando TO stringa

Però ci sono comandi con cui ciò funziona ma altri no...non capisco come mai...

[giulio]

Potrebbe essere che il programma che lanci non scriva sullo standard output e quindi la stringa resti vuota. Esempio banale con "ls":

Codice: [Seleziona]

 
PUBLIC SUB Main()
  
  DIM slsLog AS String
  
  SHELL "ls " & User.Home &/ "fileinesistente" TO slsLog
  PRINT "primo log: " & slsLog
  
  SHELL "ls " & User.Home &/ "fileinsistente" & " 2>&1" TO slsLog
  PRINT "secondo log: " & slsLog
  
  
END

Chiedo a "ls" di 'listare' un file che non esiste e registrare il log. La prima stringa
rimane però vuota perché "ls" ha scritto sullo standar error. Così devo reindirizare
lo standard error su cui scrive "ls" sullo standard output. E ciò si fa con  "2>&1"
Nel secondo esempio la stringa sarà sempre piena, o con il percorso del file, se esiste,
o con l'errore del programma. Ciao.

Cioè dipende da che processo devi eseguire appunto .... il _read va bene per usare chennesò wget ... che continua nel tempo con l'output di una riga ....

se devi invece "prelevare" un unico output ti conviene usare TO "stringa"

[Ceskho]

Si infatti il mio problema era quello evidenziato da Giulio....grazie!