slacky.eu

dico la mia.
secondo me è una coincidenza.
scrivendo quel file magari sopra pensiero ha scritto cat e senza nemmeno pensarci poi ha continuato con cp.
personalmente a volte uso cat e a volte cp, senza un particolare motivo, se scrivessi uno script senza pensarci potrei usare a volte cat e a volte cp, senza farci nemmeno caso.

aLvArO ha scritto:dico la mia.
secondo me è una coincidenza.
scrivendo quel file magari sopra pensiero ha scritto cat e senza nemmeno pensarci poi ha continuato con cp.
personalmente a volte uso cat e a volte cp, senza un particolare motivo, se scrivessi uno script senza pensarci potrei usare a volte cat e a volte cp, senza farci nemmeno caso.

Lo fai in tutti i file install.sh delle diverse architetture. Anche se non tutte ce l'hanno.
Boh... ci terremo questo dubbio

Ho trovato una differenza per cui in alcuni casi e' preferibile usare cat al posto di cp, solo che.... in questo caso non centra niente

comunque la trovo interessante, per cui la posto:
pare che cp da una certa versione in poi non riesca a copiare file da /proc

mauro ha scritto:Ho trovato una differenza per cui in alcuni casi e' preferibile usare cat al posto di cp, solo che.... in questo caso non centra niente

comunque la trovo interessante, per cui la posto:
pare che cp da una certa versione in poi non riesca a copiare file da /proc

Codice: Seleziona tutto

$ cp /proc/uptime .
$ cat uptime 
$ rm uptime 
rm: remove write-protected regular empty file `uptime'? y
$ cat /proc/uptime > ./uptime
$ cat uptime
22543.35 13488.74

Alcuni file in /proc non puoi nemmeno modificarli con un editor ma solo con echo > in quando non sono "veri" file. Quindi quel comportamente è normale. Ma come dici tu... in quell'altro caso no...

Cercando una risposta, ho trovato questa pagina (che non c'entra una mazza col kernel):http://wiki.dovecot.org/Migration/MailFormat.
In particolare, se scorrete nel codice, troverete una riga di commento su cat: Mi sembra però una vaccata...

414N ha scritto:Mi sembra però una vaccata...

invece è corretto
ed è l'unico motivo che conosco per usare cat al posto di cp su un file.

Facendo una prova non noto differenze pero'

Temo tu abbia fatto le prove al contrario.
Dovevi provare a fare un più che da 'a' a 'c', per vedere se 'a' manteneva i permessi impostati precedentemente nonostante il cambio di contenuto (che con touch è molto esiguo...)

Ma avevi già C, devi partire in una situazione dove hai solo A.
Però anche io non noto differenze
Entrambi i nuovi file hanno stess permessi e stesso prorietario.
Infatti pensavo che siccome si può compilare il kernel da utente ed installarlo da root, fosse l'input buono, invece non sembra...

414N ha scritto:Temo tu abbia fatto le prove al contrario.
Dovevi provare a fare un

Codice: Seleziona tutto

cat b > a

più che da 'a' a 'c', per vedere se 'a' manteneva i permessi impostati precedentemente nonostante il cambio di contenuto (che con touch è molto esiguo...)

Ma nel kernel si rinomina prima il vecchio file con mv, e poi si copia il file in /boot
Non si va a sovrascrivere niente, quindi non si può prendere come esempio valido nel caso specifico una situazione in cui sovrascrive un file

414N ha scritto:Temo tu abbia fatto le prove al contrario.
Dovevi provare a fare un

Codice: Seleziona tutto
cat b > a


più che da 'a' a 'c', per vedere se 'a' manteneva i permessi impostati precedentemente nonostante il cambio di contenuto (che con touch è molto esiguo...)

touch non l'ho usato per cambiare i file ma per crearli. Dato che i permessi di a sono diversi dai permessi di b mi sfugge la differenza tra dare cat a > b e cat b > a per mostrare che gli stessi non vengono modificati.

conraid (1) ha scritto:Ma avevi già C, devi partire in una situazione dove hai solo A.

conraid (2) ha scritto:Ma nel kernel si rinomina prima il vecchio file con mv, e poi si copia il file in /boot

ecco, mi era sfuggito il punto 2, quindi ho creato un esempio con l'intento non di verificare i permessi ottenuti creando un file ma sovrascrivendone di esitenti.

Ma se lo scopo fosse preservare gli attibuti perche' non usare:

man cp ha scritto: --preserve[=ATTR_LIST]
preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: links, all