Differenze tra CP e CAT nell'installazione del kernel

[aLvArO]

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.

[conraid]

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

[mauro]

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

[conraid]

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...

[414N]

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:

Codice: Seleziona tutto

# cat instead of copy leaves the original owner and permissions alone

Mi sembra però una vaccata...

[sid77]

Mi sembra però una vaccata...

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

[mauro]

Facendo una prova non noto differenze pero'

Codice: Seleziona tutto

maurog@maurog:~/prova$ touch a b c
maurog@maurog:~/prova$ chmod 755 a
maurog@maurog:~/prova$ ls -l
total 0
-rwxr-xr-x 1 maurog users 0 2008-02-18 15:51 a
-rw-r--r-- 1 maurog users 0 2008-02-18 15:51 b
-rw-r--r-- 1 maurog users 0 2008-02-18 15:51 c
maurog@maurog:~/prova$ cp a b
maurog@maurog:~/prova$ cat a > c
maurog@maurog:~/prova$ ls -l
total 0
-rwxr-xr-x 1 maurog users 0 2008-02-18 15:51 a
-rw-r--r-- 1 maurog users 0 2008-02-18 15:52 b
-rw-r--r-- 1 maurog users 0 2008-02-18 15:52 c
maurog@maurog:~/prova$ su 
Password: 
bash-3.1# cp a b
bash-3.1# cat a > c
bash-3.1# ls -l
total 0
-rwxr-xr-x 1 maurog users 0 2008-02-18 15:51 a
-rw-r--r-- 1 maurog users 0 2008-02-18 15:52 b
-rw-r--r-- 1 maurog users 0 2008-02-18 15:52 c
bash-3.1# chown root.root a
bash-3.1# cp a b
bash-3.1# cat a > c
bash-3.1# ls -l
total 0
-rwxr-xr-x 1 root   root  0 2008-02-18 15:51 a
-rw-r--r-- 1 maurog users 0 2008-02-18 15:53 b
-rw-r--r-- 1 maurog users 0 2008-02-18 15:53 c
bash-3.1# echo mah...

[414N]

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...)

[conraid]

Ma avevi già C, devi partire in una situazione dove hai solo A.
Però anche io non noto differenze

Codice: Seleziona tutto

blank@slack:~$ cd prova
blank@slack:~/prova$ ls
blank@slack:~/prova$ touch a
blank@slack:~/prova$ ls -l
totale 0
-rw-r--r--   1 blank users     0 2008-02-18 16:11 a
blank@slack:~/prova$ su
Password:
root@slack:/home/blank/prova# cat a > b
root@slack:/home/blank/prova# cp a c
root@slack:/home/blank/prova# ls -l
totale 0
-rw-r--r-- 1 blank users 0 2008-02-18 16:11 a
-rw-r--r-- 1 root  root  0 2008-02-18 16:12 b
-rw-r--r-- 1 root  root  0 2008-02-18 16:12 c
root@slack:/home/blank/prova#

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...

[conraid]

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

[mauro]

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.

Ma avevi già C, devi partire in una situazione dove hai solo A.

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:

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