Quando mi trovo a dover analizzare un file di testo, un txt o un log, molto lungo che contiene centinaia, se non migliaia, di righe, spesso e volentieri mi perdo qualche pezzo importante e così non capisco perché è fallita l'installazione di un programma o perché si è generato un errore nel sistema. Inoltre aprire con Notepad dei file di testo di dimensioni molto grandi può essere lento e pesante (ci sarebbe Notepad++ ma in ufficio non è sempre permesso installare e usare programmi di terze parti così mi devo arrangiare con Notepad). [continua..]
---
Cosa ne pensi? Lascia il tuo commento qui sotto.
These users thanked the author crazy.cat for the post:
ctsvevo ha scritto: lun dic 15, 2025 7:54 pm
Perdonami, crazy.cat ma... non puoi utilizzare Notepad++ Portable?
Sicuramente, ma tu non sai quanti allarmi assurdi fa scattare cortex antivirus aziendale in ufficio, appena vede un eseguibile strano (per lui) ti bloccano il pc e costringono a formattarlo.
Poi sai che ormai studio e apprezzo powershell per tutto quello che può fare.
La prima legge della dietetica sembra essere: se il sapore è buono, a te fa male.
Ah, se la situazione è quella, allora comprendo meglio l'uso di PowerShell (che comunque rimane più ostico per noi "comuni mortali" rispetto a Notepad++)...
"Ask Me Anything": il Direttore di Thunderbird risponde alle vostre domande:
https://forum.mozillaitalia.org/index.php?topic=79685.0
ctsvevo ha scritto: mar dic 16, 2025 9:09 am
Ah, se la situazione è quella,
Figurati che ultimamente si è messo a considerare come pericoloso l'applicativo ninja, quello che usiamo noi tecnici per collegarci agli altri pc, solo perché due sconosciuti antivirus lo segnalano come pericoloso su virustotal.
Powershell non morde comunque, neanche io mi considero certo un esperto, gratto ancora solo lo strato iniziale per ricavare qualche script utile.
La prima legge della dietetica sembra essere: se il sapore è buono, a te fa male.
Proposito, ma per gli script su powershell, che editor usi? Il notepad di Windows?
Sapevo che c'era un editor apposito, di casa Microsoft, ma da quanto capito è "deprecato".
@crazycat: tu apprezzi powershell per validi motivi professionali ma è indubbio che sia piuttosto complesso e ostico per gli utenti comuni.
Rilevo poi che il comando in oggetto ignora i file di testo .DOC .DOCX .ODT .PDF(anche OCR) e non li scansiona.
Anche l'esposizione del risultato della ricerca è piuttosto ostico, con il testo mixato da caratteri di formattazione.
Personalmente (ma è solo una conclusione soggettiva, assolutamente opinabile) ne concludo che solo il comando Get-ChildItem offre un risultato utile, obiettivamente leggibile, chiaro e agevolmente interpretabile.
"Utilizzando il cmdlet Get-Content ... ma sicuramente più leggibile": "più leggibile" (??? ): Get-Content può avere qualche utilità ricercando solo in un file specifico ma non restituisce il num.della riga in cui è presente la stringa cercata; indicando invece * (anziché un solo file specifico) e non restituendo né il num.della riga né il nome del file, il risultato (sequenza di righe appartenenti a diversi file) è un caos !
"Il cmdlet Get-ChildItem permette la ricerca della stringa ... in tutti i file .TXT e .LOG":
per essere precisi, anche file .RTF
Certamente! ed è quanto dico nella mia premessa ("per validi motivi professionali"), non avevo nessun intento critico, solo considerazioni da utente comune.
L'articolo mi aveva interessato per la possibilità di ricercare, all'interno di una intera cartella, dove potevo reperire una determinata stringa e ho testato il comando per verificarne la reale utilità.
Da utente comune, se devo cercare in un solo specifico file, mi è più utile e comodo aprirlo ed eseguire "trova" che evidenzia ogni stringa trovata e lo posso usare anche in file di testo consueti (DOC, DOCX, ODT) ed anche in fogli di calcolo o PDF (tramite "trova nella pagina" di EDGE).
Un'ultima precisazione in riferimento al precedente post in cui dico "testo mixato da caratteri di formattazione": è così ma solo per file.RTF per i quali indica anche un num.riga errato. Confermo invece la carenza di Get-Content indicando * nel path (anziché un file specifico) poiché non restituisce né il num.della riga né il nome del file.
Inserendo un messaggio, dichiari di aver letto e accettato il regolamento di partecipazione.
Nello specifico, sei consapevole che ti stai assumendo personalmente la totale responsabilità delle tue affermazioni, anche in sede civile e/o penale,
manlevando i gestori di questo sito da ogni coinvolgimento e/o pretesa di rivalsa.
Dichiari inoltre di essere consapevole che il messaggio sarà visibile pubblicamente, accetti di diffonderlo con licenza
CC BY-NC-SA 3.0 (con attribuzione a "TurboLab.it") e rinunci ad ogni forma di compensazione (economica o altro).
Rinunci inoltre esplicitamente a qualsiasi pretesa di cancellazione del messaggio.
