Buongiorno a tutti,

da qualche giorno sto cercando di sperimentare python ... perchè ho scoperto un piccolo esempio di script sul web che sembrava risolvere, in modo molto semplice, un problema che pareva impossibile con Java (che stavo cercando di imparare da mesi).

Preciso che sono un "vecchissimo" programmatore di linguaggi di terza generazione, approdato decenni fa a Visual Basic (che ho utilizzato fino al VB6) e a prima vista python gli somiglia molto.
Da molti anni non sviluppo più per lavoro ma solo per uso personale.

Da quello che ho visto fin'ora per eseguire uno script .py bisogna lanciarlo da una shell ... e per provare, impararare, debuggare ... va benissimo.

Quello che vorrei a questo punto, è che nel momento in cui aggiungo una voce al menù "Start" di Windows per eseguire lo script .py non mi aprisse anche una finestra del cmd.exe (terminale dei comandi).

Al momento, per ragiorni che sarebbe troppo lungo spiegare, sono ancora vincolato a Windows XP 32bit e alla versione 14.04 di Kubuntu, quindi sto usando Python 2.7.16.

Cercando sul web ho trovato varie indicazioni come, usare pythonw al posto di python, nel comando della voce del menù di start, piuttosto che modificare l'estensione del file da .py a .pyw ... ma purtroppo nessuna di queste indicazioni funziona.

Per caso può essere dovuto al fatto che dallo script python lancio un programma java?
Riporto un esempio:

import os
Cartella = 'C:/Applicazioni/NomeProg'
Comando = 'java -jar C:/Applicazioni/NomeProg/NomeProg.jar'

# altre istruzioni python

os.chdir(Cartella)
os.system(Comando)

Aggiungo che non mi interessa trasformare lo script in un file eseguibile, come ho visto chiedere in tante discussioni su vari siti, tanto i programmi che realizzerei sarebbero solo per uso personale, ma siccome ne farei un uso intensivo, e normalmente opero con "enne" finestre aperte, non voglio ritrovarmi con "enne" finestre di shell aperte che mi farebbero perdere solo tempo quando devo spostarmi tra una applicazione e l'altra con <Alt><Tab>.

Qualcuno gentilmente sa darmi qualche dritta?

Usare l'interprete pythonw.exe (ovvero, usare l'estensione *.pyw per gli script) è la cosa giusta, e funziona. Se non funziona, vuol dire che stai facendo qualcosa di sbagliato (tipo, non stai davvero modificando l'estensione perché non visualizzi le estensioni dei file nell'explorer di windows... tipo, windows non associa l'estensione pyw all'interprete pythonw.exe... magari è il tuo collegamento che apre lo stesso una shell... magari è il menu start che ha quell'effetto... qualcosa così).





Detto questo: in generale non è una buona idea https://pythoninwindows.blogspot.com/2019/03/e-adesso-dove-clicco.html




Detto questo: ma non capisco perché ti sei fatto uno script python solo per lanciare uno script java... chissà, magari è quello, che apre una shell...





Detto questo: ma alla fine del 2019... windows xp.. 32 bit... python 2.7... mah.

Caro RicPol,
ti ringrazio sinceramente per la risposta e le tue indicazioni.
Ci ho messo un po a rispondere perché ho voluto fare un po di prove.

RicPol said @ 2019-11-12 11:04:00:

Usare l'interprete pythonw.exe (ovvero, usare l'estensione *.pyw per gli script) è la cosa giusta, e funziona.

Questo mi fa piacere, perché mi conferma che almeno qualcosa l'ho capito ...

RicPol said @ 2019-11-12 11:04:00:

Se non funziona, vuol dire che stai facendo qualcosa di sbagliato (tipo, non stai davvero modificando l'estensione perché non visualizzi le estensioni dei file nell'explorer di windows...

Ti garantisco che da quando utilizzo Windows (ovvero dalla 3.11) l'ho sempre accuratamente impostato per vedere le estensioni dei file ... poichè come ho scritto prima, sono un tipo "vecchia maniera" ... mi piace vedere il più possibile.

RicPol said @ 2019-11-12 11:04:00:

tipo, windows non associa l'estensione pyw all'interprete pythonw.exe...

Ho verificato e avevo già fatto l'associazione tra file .pyw e pythonw.exe

RicPol said @ 2019-11-12 11:04:00:

magari è il tuo collegamento che apre lo stesso una shell... magari è il menu start che ha quell'effetto... qualcosa così).

Qui mi hai fatto venire un grosso dubbio;
Ho aperto il mio progetto java e ho disabilitato (perché sono subordinate al valore di una variabile boolean) tutte le istruzioni (System.out.println) che stampavano messaggi di debug, pensando che quelli "forzassero" l'apertura della shell (cmd.exe) ...
ma ... delusione ... la shell si apre ugualmente, pur rimanendo vuota.
In più ho fatto le seguenti prove:
Nel menù di start di Windows ho creato le seguenti voci:
C:\Applicazioni\xFile\xFile.jar
C:\WINDOWS\system32\javaw.exe -jar C:\Applicazioni\xFile\xFile.jar
C:\Applicazioni\xFile\xFile.vbs
dove il file vbs è il seguente:

const jarfile="C:\Applicazioni\xFile\xFile.jar"
dim wshell
set wshell=WScript.CreateObject("WScript.Shell")
wshell.run "javaw -jar " & jarfile ,1,false

e tutte mi eseguono il programma xFile.jar senza aprire la shell ... mentre la voce:
C:\Applicazioni\Python\pythonw.exe "C:\Applicazioni\xFile\xFile.pyw"
mi apre la shell.
Il file .pyw ridotto all'osso è:

import os

Cartella = 'C:/Applicazioni/xFile'
Comando = 'C:/WINDOWS/system32/javaw.exe -jar C:/Applicazioni/xFile/xFile.jar'

os.chdir(Cartella)
os.system(Comando)

Su Kubuntu invece:
la chiamata diretta /home/marco/xFile/xFile.jar non funziona
ma ...
java -jar /home/marco/xFile/xFile.jar
python /home/marco/xFile/xFile.py
funzionano entrambi senza aprire la shell ... boh?

RicPol said @ 2019-11-12 11:04:00:

Detto questo: in generale non è una buona idea https://pythoninwindows.blogspot.com/2019/03/e-adesso-dove-clicco.html

Da qui capisco che l'ambiente base per eseguire script python è la shell, ma viene citata anche la possibilità di usare degli ambienti per creare i classici programmi a finestre, di cui in effetti io ho bisogno.

RicPol said @ 2019-11-12 11:04:00:

Detto questo: ma non capisco perché ti sei fatto uno script python solo per lanciare uno script java... chissà, magari è quello, che apre una shell...

Cerco di spiegarmi, il più brevemente possibile:
Il mio proposito è di realizzare un lanciatore di programmi multipiattaforma, di cui ho creato la base con java, ma non riuscivo a trovare il modo di evitare l'attivazione di più istanze dello stesso programma ...
Ad un certo punto ho trovato in rete uno script python che prometteva di risolvere il problema, molto semplicemente; bastava eseguire il programma java o qualsiasi altro programma tramite tale script e lui si occupava di verificare la presenza di una precedente istanza in esecuzione ed eventualmente portarla in primo piano.
Da qui il mio interessamento per Python, che ho iniziato a studiare tramite un semplice tutorial.
Di fatto poi lo script non fa quello che promette, ma questo è un altro argomento.

RicPol said @ 2019-11-12 11:04:00:

Detto questo: ma alla fine del 2019... windows xp.. 32 bit... python 2.7... mah.

Capisco la tua perplessità, ma come dicevo, sono un programmatore del periodo jurassico ... e sono vincolato a XP a causa di un'applicazione che ho sviluppato in passato con VB6 e che non sono ancora riuscito a riscrivere in Java.
Di conseguenza uso Python 2.7 perché ho letto sul web che è l'ultima versione compatibile con XP.
Preciso che, secondo me, XP è la migliore versione di Windows che MS abbia mai realizzato, e sto cercando di sviluppare un mio lanciatore, (oltre che convertire il mio gestionale in java) proprio per sbarazzarmi finalmente di Windows e passare definitivamente al mondo linux.
Il mio interessamento verso Python è anche dovuto al fatto che, siccome mi sembra più semplice di java, potrei anche decidere di mollare java e riscrivere il tutto in Python, sempre che riesca a capire come creare le interfacce grafiche con Python.




A questo punto sono nella nebbia ... per cui qualsiasi aiutino, indicazione, suggerimento e' il benvenuto.

oh beh.... non so che dire... guarda, non te la prendere ma secondo me dovresti mettere in ordine le tue priorità...

Allora, che tu sia un programmatore giurassico ci può anche stare, ma guarda che intorno a te il mondo è cambiato parecchio dal giurassico, e comunque devi farci i conti se vuoi programmare ancora. A meno che non ti chiudi a chiave in casa con le finestre abbassate e ti metti a programmare in vb6 su win xp ascoltando Celin Dion...


Ora, sei padronissimo di pensare che xp sia l'ultima versione decente di windows, ma è come restare affezionati al vecchio televisore a tubo catodico: fa' come ti pare, ma guarda che con quello ormai non becchi più un canale digitale. (E comunque, nel merito, hai torto: le ultime versioni di windows sono di gran lunga superiori a xp, anche senza contare le novità. Un crash del sistema operativo, oggi, è veramente ma veramente raro... per dire).


E quindi non puoi costringere tutti quelli che vogliono usare il tuo programma a restare a xp, ti pare? E se lo usi solo tu, allora guarda: al limite fatti un bel computer nuovo con windows 10, e usa una macchina virtuale per farci girare dentro xp... almeno nel frattempo impari windows 10.


E lo stesso discorso vale per "passare a linux"... mamma mia, che lessico da anni '90... "passare a linux"... guarda, forse ti sei perso un po' di storia nel frattempo ma oggi, da un lato il mondo è già tutto "passato a linux"... ma solo sui server. Linux sul desktop oggi è ancora meno diffuso, in proporzione, di quanto lo fosse vent'anni fa. Ora, sicuramente un programmatore serio dovrebbe conoscere un po' di Linux, non ci piove, anche se vuole programmare gui desktop (che comunque oggi è un mercato di nicchia). Ma lo sviluppo di gui desktop vale la pena di farlo se si pensa al mercato windows, oggi ancora più di vent'anni fa. E comunque tu puoi anche "passare a Linux", come ti pare, ma non puoi costringere tutti quelli che usano il tuo programma gui desktop a passare a Linux anche loro, no?

Dopo di che, non è detto che il tuo gestionale in vb6 non possa ancora girare su windows 10... ci farei un tentativo... con un po' di fantasia è persino ancora possibile installare vb6 su win10, vedo... https://www.raymond.cc/blog/install-visual-basic-6-vb6-in-windows-7-without-microsoft-virtual-machine-for-java/ LOL

Dopo di che, il problema del "launcher" non ha molto senso... Il programma è quello che è... siamo d'accordo che il suo problema è che andrebbe riscritto daccapo... direi che la priorità è questa... nel frattempo puoi semplicemente dire a chi lo usa di fare attenzione a non lanciarne due istanze... lascia perdere il launcher.


Puoi scegliere di riscrivere il tuo programma in java, in python... diamine magari non è detto che non ti piacerebbe imparare un po' di C# su .net... L'importante è che ti trasferisci armi e bagagli su un sistema di sviluppo moderno. Se scegli Python, hai tutti gli strumenti che ti servono per costruire applicazioni gui... figurati, io saranno 15 anni che lo faccio... adesso ci ho pure scritto un libro... Non è certo questo il problema.


Per quanto riguarda il fatto di avere una sola istanza del programma in esecuzione, ripeto è un problema assolutamente secondario... e sicuramente non hai bisogno di un launcher per questo. E' il programma stesso che dovrebbe fare questo controllo... e questo si può fare in python come in java... per esempio ascoltando su una porta predefinita. Quindi, quando riscriverai il programma, aggiungerai questa funzionalità, se ti serve. Non hai bisogno di un accrocchio esterno tipo un launcher per questo.

E poi, scendendo sempre più nel dettaglio... per quanto riguarda la finestrella della shell aperta... boh, vale la risposta che ti ho già dato... e del resto prova con uno script python semplice che non emette nessun output nella shell, dagli un nome in *.pyw e vedi che parte senza mostrare la finestrella. Nel tuo caso... mah, forse effettivamente os.system apre la finestrella... Non saprei, os.system è deprecato da talmente tanto tempo che non ricordo più bene... anche qui, il motivo per cui tu stai usando os.system quando invece dovresti usare subprocess.run, è che stai pescando a caso cose in rete (senza curarti che sono vecchie di anni) che copi e incolli senza capire bene che cosa fanno...


Il che ci riporta al problema iniziale: credo che dovresti mettere in ordine le tue priorità. Primo, decidere che vuoi procedere in python. Secondo, studiare python. Terzo, studiare le gui in python. Quarto, riscrivere il tuo programma come una gui python. Quinto (e solo quinto!) affrontare dettagli come l'istanza singola, la finestrella della shell, eccetera.

Carissimo,
apprezzo molto la tua disponibilità nei miei confronti.
Tutte le tue considerazioni sono assolutamente corrette e non farebbero una grinza, se io fossi uno sviluppatore di professione ... ma forse ti è sfuggita una cosetta che ho scritto nel primo post, ovvero che non sviluppo più per lavoro da parecchi anni e ora mi limito a realizzare software per mio uso personale ... quindi non devo e non voglio costringere nessuno ad usare software antichi, desueti o specifici sistemi operativi.
Ci mancherebbe.

Il motivo per cui la mia priorità primaria, in questo momento, è il lanciatore di programmi, sta nel fatto di essere nato, come informatico, all'epoca delle schede perforate e dei terminali a caratteri.
Il mio strumento principale di interazione con il pc è la tastiera ... detesto con tutte le mie forze il topo!!!! (detto anche "mouse") ... e cerco di scoprire tutte le combinazioni di tasti di scelta rapida possibili, per attivare/chiudere/scegliere/inserire etc. qualsiasi cosa da tastiera.
Tutti i miei programmi sono utilizzabili completamente tramite la tastiera, e la mia più grande soddisfazione, durante il periodo di programmatore professionista, era vedere la velocità con cui alcune utenti interagivano con il programma e quindi con i loro clienti. Semplicemente spettacolare!

Siccome da Windows 7 in poi e da Kubuntu 16 in poi i menù di start sono dotati di quella, per me, "famigerata" casella di ricerca, che cattura qualsiasi tasto io pigi dopo la fantastica sequenza <Ctrl><Esc> ... per selezionare una qualsiasi voce della struttura di menù e sotto-menù che mi creo e personalizzo, DEVO per forza usare il topo!! E questo lo detesto, anche perché è di una lentezza esasperante, rispetto alla velocità con cui eseguo le stesse cose da tastiera.

Fino ad ora sui PC dove ho dovuto, per vincoli HW, installare Windows 8.1, ho rimediato con ClassicShell.
Su kubuntu purtroppo ho trovato solo classicmenu-indicator, che però non consente la navigazione tra i sotto-menù tramite la pressione delle iniziali delle corrispondenti voci.

Il "passare a Linux", per me, significa abbandonare definitivamente l'ambiente Microsoft, di cui sono strastufo (mia opinione personale), e usare su tutti i miei pc, le varie distribuzioni di GNU/Linux come appunto Kubuntu o altre e quindi in definitiva avere "la libertà di scelta".

A questo punto entra in gioco il discorso della singola istanza, perché quando premo la fatidica combinazione <Ctrl><Esc> o equivalente, deve attivarsi la finestra del lanciatore, ma non partire una seconda istanza del lanciatore, esattamente come fa il menù Start di Windows XP e ClassicShell.

Anche qui hai ragionaissima quando dici che questa funzionalità dovrebbe essere gestita all'interno del programma stesso, e la soluzione dell'ascoltare su una porta specifica l'avevo già letta sul web, ma siccome l'argomento socket, per me, al momento, é ancora un totale mistero, ecco scaturire la ricerca di una soluzione sbrigativa (vedi script python) in attesa di farmi una cultura specifica con Python.
Ed ecco perché anche usare il deprecato os.system poteva andarmi bene, visto che lo stavo usando su sistemi operativi anch'essi obsoleti e che non supportano la versione 3 di Python.
Quindi momentaneamente mi andava bene fare il copia e incolla di esempi copiati dal web.

Se però, in base a ciò che mi dici, non c'è altra soluzione, mi sa che mi dovrò rassegnare ad aspettare di approfondire, anzi, studiare di sana pianta Python, che da quello che ho visto e letto fin'ora mi sembra molto più semplice di Java.
Ovviamente l'ambiente .net non lo prendo nemmeno in considerazione per le stesse ragioni di cui sopra, rispetto agli ambienti MS.

Spero di aver chiarito meglio il mio punto di vista, che resta comunque il mio punto di vista, e non pretendo che sia condiviso o seguito da altri.

Se comunque riesci a darmi una mano, te ne sarò immensamente grato.

Mah, abbi pazienza ma francamente mi sembra tutto campato in aria... "voglio un launcher perché non mi va di usare il mouse" è una delle linee di ragionamento più attorcigliate che ho visto di recente. A parte il fatto che questo forum (e tutto il browser che lo circonda) lo starai ben usando con il mouse, o sbaglio? Boh...


Comunque... non sono sicuro di aver capito, ma... boh? tutto il problema è che "ctrl+esc" innesca qualcosa nel sistema operativo? Ora, direi di non usare "ctrl+esc" come shortcut nei tuoi programmi... finita lì. E poi guarda che (sorpresa, sorpresa) "ctrl+esc" è una shortcut del sistema operativo anche in windows xp... quindi non capisco di preciso di che cosa stiamo parlando.


E se poi tutto il problema di "ctrl+esc" ce l'hai solo quando avvi il tuo programma... e capirai la fatica... quante centinaia di volte devi avviare il tuo programma in un giorno?

Ma poi, davvero, dico io... "devo proprio restare fermo a windows xp (o passare direttamente a linux) perché altrimenti c'è ctrl+esc che mi blocca"... ma ti sembra una ragione? Cioè, ma lo sai che in windows puoi rimappare gli shortcut del sistema operativo, se ti va? Tu decidi tutto il tuo stack tecnologico in base a che cosa fa "ctrl+esc"? Ok, per carità, ciascuno è libero.





Detto questo, sicuramente ci sono altri sistemi per avere un'istanza singleton del programma, oltre ad ascoltare su una porta... per esempio in windows è prassi comune acquisire un named mutex per questo scopo... se hai più familiarità con questi, allora puoi acquisire un named mutex anche attraverso python (è un pelino più difficile però, data la natura crossplatform di python). Altrimenti, in generale non ci sono scorciatoie alla programmazione che non passano per imparare la programmazione.





In conclusione, potrò sbagliarmi, ma la mia impressione è: stai decidendo quale macchina acquistare fissandoti a esaminare i diversi tipi di leva del tergicristalli. Intanto però, non hai ancora preso la patente. Il mio discreto consiglio sarebbe: organizzati intorno a un sistema operativo moderno (io lavoro su windows, ma ovviamente è molto tipico per gli sviluppatori usare linux...). Impara una versione moderna di python seguendo un buon libro passo-passo, mettici il tempo che ci vuole, e poi vedrai che questi piccoli dettagli si risolvono praticamente da soli.

Ok, mi rendo conto di non essermi spiegato bene, e che ho generato una sequenza di disquisizioni "filosofiche" che ci hanno portato ampiamente fuori tema.

La mia domanda iniziale era molto tecnica:

C'è il modo di evitare l'apertura della shell quando si lancia uno script Python dal menù Start di WIndowsXP?
La cosa succede anche dal menù Start di Windows 8.1
ma non succede su Kubuntu 14.04.

Se su questo quesito nessuno sa aiutarmi non importa, sicuramente, come hai detto tu, me lo risolverò da solo quando avrò imparato meglio Python.

Grazie di tutto.


--- Ultima modifica di ZioCrick in data 2019-11-17 22:27:34 ---

Sì sì, ho capito la domanda tecnica e ti ho già tecnicamente ampiamente aiutato. Devi far girare lo script con l'interprete pythonw.exe invece di python.exe. Tecnicamente, questo funziona e basta. Dal lato python, questo è il modo.


Se poi lo script di suo apre un altro processo, e per qualche tua ragione vuoi pure usare os.system che apre una subshell, beh questo è un problema separato (molti problemi separati, in effetti). Per dire, se almeno usassi subprocess questo non ti succederebbe (almeno, boh... non credo). Ma se anche subprocess non rientra nelle cose che sai, cosa possiamo farci. Oppure, e questo mi è venuto in mente in questo istante, potresti anche fare qualche magheggio direttamente con la shell, tipo passare attraverso "start /b" o "start /min"... questo *potrebbe* funzionare anche chiamato da os.system, mi viene in mente, anche se francamente qui ci stiamo arrampicando su una catasta di hack che prima o poi verrà giù...


E questo per quanto riguarda il problema tecnico. Per tutto ciò che circonda il problema tecnico, beh ti ho ampiamente aiutato e stra-aiutato e ri-aiutato anche su questo... ma alla fine della giornata non c'è niente da fare... non è che puoi sperare nella ricettina miracolosa trovata su internet pronta da copincollare e perfettamente adatta al tuo caso specifico. Oh, intendiamoci... talvolta funziona, eh? Ma in definitiva, non c'è davvero un sostituto alla programmazione, se non la programmazione. Parti dalle basi, segui un buon libro passo-passo, e vedrai che i dubbi si sciolgono poco per volta.