Un cordiale saluto a tutta la lista.
-----
[Usando: Debian 5.9.9-1 (2020-11-19) x86_64 GNU/Linux]
[N.B. Premetto '###' alle righe di comando per scongiurare incidenti...]
-----
Con questo comando avevo convertito da utf-8 a iso-8859-1 il file '01mag':
### iconv -f utf-8 01mag -t iso-8859-1 > 01mag_iso

Qualche giorno dopo, volendo fare la conversione inversa, ho dato prima il comando:
### iconv -f iso-8859-1 01mag -t utf8 > 01mag_utf
sbagliato nel nome del file, indicato come '01mag' anziché '01mag_iso'.

Accortomi dell'errore ho dato il comando che mi sembrava giusto:
### iconv -f iso-8859-1 01mag* -t utf8 > 01mag_utf
Ma quando sono andato a rileggere il file 'nuovo' mi sono accorto che non esisteva,
perché avevo scritto 'utf8' invece di di 'utf-8':

2971 less 01mag_utf
2972 rm 01mag_utf

Finalmente ho scritto quello che mi sembrava il comando 'buono':

### iconv -f iso-8859-1 01mag* -t utf-8 > 01mag_utf

A questo punto ho constatato che il file '01mag_utf' non era stato creato oppure
non era significativo e che il file di partenza - '01mag_iso' - era svuotato del suo contenuto originario e conteneva solo la riga:
### iconv -f utf-8 01mag -t iso-8859-1
che, guarda caso, è il primo comando che avevo dato qualche giorno prima!

Ri-consultando 'man iconv' ho visto che il comando corretto da dare è:

----- Quote -----

"" EXAMPLES
"" Convert text from the ISO/IEC 8859-15 character encoding to UTF-8:

"" $ iconv -f ISO-8859-15 -t UTF-8 < input.txt > output.txt
----- unquote -----

ma non vedo avvertimenti circa un malaccorto uso del comando stesso.


L'unica cosa che mi viene in mente è il famigerato semplice ma subdolo comando
######## > ########
che 'ingoia', come un enorme buco nero, tutto ciò che lo segue sulla riga
di comando.
Nel caso specifico, esso sarebbe entrato in funzione dopo la 'inconsistenza' del comando che lo precedeva e - se così fosse -,potremmo essere in presenza di
un bug?

Vi ringrazio dell'attenzione fin qui riservatami e sarò grato a chi vorrà confortarmi con i suoi suggerimenti.

Mi piace intanto pensare che questo post possa impedire, in particolare a chi fa i primi passi in questo straordinario Sistema Operativo, di doversi pentire di non aver seguito il generico - ma sovente ripetuto - consiglio di avere sempre a disposizione copie di riserva dei file su cui si lavora ...

Saluti, Ennio

--
[Perché usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?//
Fà qualche cosa di cui non sei capace!" (diceva Henry Miller) (°|°)
[Why use Win$ozz (I say) if ... "even a fool can do that. .)=(.
Do something you aren't good at!" (as Henry Miller used to say)] /_____\

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ennio-Sr

L'unica cosa che mi viene in mente è il famigerato semplice ma subdolo comando
######## > ########
che 'ingoia', come un enorme buco nero, tutto ciò che lo segue sulla riga di comando.

è quello il suo scopo

Nel caso specifico, esso sarebbe entrato in funzione dopo la 'inconsistenza' del comando che lo precedeva e - se così fosse -,potremmo essere in presenza di
un bug?

non è un bug, tu puoi usare il comando per fare quello che vuoi, poi in realtà
tu stai dado più comandi insieme o meglio esegui un comando che butta su standard output e redirige in un file

Quindi se tu dai un comando che è sintatticamente valido è corretto che venga eseguito.

Per esempio io uso

$ echo "Ciao" > /tmp/mio_file.txt
$ cat /tmp/mio_file.txt
Ciao
$ :> /tmp/mio_file.txt
$ cat /tmp/mio_file.txt
$

come vedi il penultimo comando svuota il file.

Bisogna stare sempre attenti quando si usano i comandi di ridirezione e, soprattutto, bisogna prima aver ben chiaro cosa fanno.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ciao Ennio-Sr,

Il giorno dom, 26/05/2024 alle 10.05 +0200, Davide Prina ha scritto:

Ennio-Sr

L'unica cosa che mi viene in mente è il famigerato semplice ma subdolo comando
######## > ########
che 'ingoia', come un enorme buco nero, tutto ciò che lo segue sulla riga di comando.

è quello il suo scopo

[...]

aggiungo solo una nota: le redirezioni vengono applicate dalla shell prima di fare partire il comando vero e proprio, quindi in questo caso il tuo file è stato svuotato a causa del > finale prima che eseguisse iconv.

Se vuoi usare lo stesso file come input e output puoi usare il comando sponge del pacchetto moreutils. In pratica legge completamente l'input dalla pipe e
lo tiene in RAM finché non è completo. A quel punto apre il file destinazione (che nel tuo caso ha lo stesso nome del file di input) e ci scrive tutto.

esempio 1: iconv -f latin1 -t utf-8 nomefile | sponge nomefile
esempio 2: iconv -f latin1 -t utf-8 < nomefile | sponge nomefile

Ciao,
Giuseppe


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Volevo solo ringraziare Giuseppe Sacco e Davide Prina per le risposte fornitemi. In particolare quella di Giuseppe mi sembra risponda al mio
dubbio, nel senso di tener conto della 'sintassi' del comando prima di distruggere tutti i file chiamati in causa dal comando sbagliato!
Molto interessante il comando 'sponge' di cui consulterò il 'man'...

Mi preme chiedere anche scusa del ritardo della mia risposta, dovuto solo al fatto di non aver 'visto' le risposte nella mia console durante il periodico scarico della posta, per 'eccessivo affollamento' di messaggi arretrati.


--
[Perché usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?//
Fà qualche cosa di cui non sei capace!" (diceva Henry Miller) (°|°)
[Why use Win$ozz (I say) if ... "even a fool can do that. .)=(.
Do something you aren't good at!" (as Henry Miller used to say)] /_____\

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)