Newsgroup: it.comp.os.linux.iniziare
Titolo: funzione per customizzare un comando già esistente

Ad esempio:
 
rsync() {
     command rsync \
         "$@" \
         --backup
         --backup-dir "$XXX"
}
 
È una buona pratica usare una funzione omonima per modificare un comando 
già esistente a proprio piacimento?
 
Per queste cose di solito vengono usati gli alias.
Ma anche le funzioni vanno bene, o no?

 Ma anche le funzioni vanno bene, o no?
 
Con nome diverso, forse vanno bene.
 
bye,
 
-- 
 
piergiorgio

 Ma anche le funzioni vanno bene, o no?
 
quello che ti è più funzionale va bene. le funzioni possono ad esempio 
eseguire più comandi e possono implementare una logica.
 

 Con nome diverso, forse vanno bene.
 
$ alias grep
 
cosa ti dice?
 
Ora non sono davanti al mio pc e non ricordo bene, ma a me sembra che mi 
dà questo output:
 
alias grep='grep --color=auto'
 
e me lo son trovato così da quando ho installato ubuntu: io non ci ho 
messo mano.


E questo cosa vuol dire?
 
Hai capito perche` hanno fatto in quel modo?
 
Ti consideri al livello di quelli che hanno
creato quell'alias?
 
Programma in maniera pulita, forse, dopo,
puoi permetterti di fare cose di quel tipo.
 
bye,
 
-- 
 
piergiorgio

   
 
Potrei azzardare
 
$ command rsync
 
se non è una buona idea non sputatemi in faccia :D

 creato quell'alias?
 
Certo che no :)



che vuoi ti dica? il sistema è tuo, ci devi lavorare te e se piace a te 
buona camicia a tutti. 
io uso zsh e questo 
https://github.com/ohmyzsh/ohmyzsh
 con questi plugin 
disponibili 
https://github.com/ohmyzsh/ohmyzsh/wiki/Plugins
 
 

 Per migliorare _solo_ l'output senza alterare il funzionamento originale?
 
Una buona ipotesi.
 
Il mio consiglio, per quello che puo`
valere, e` di programmare in maniera
pulita, lineare, consistente e facile.
 
C'e` sempre tempo per essere poco
ortodossi, ma bisogna sapere esattamente
quello che si sta facendo.
 
Evitare:
 
https://en.wikipedia.org/wiki/Cargo_cult_programming
 
 
bye,
 
-- 
 
piergiorgio


P.S. Premesso che sarebbe meglio una funzione con nome rsync_my.
 
Puoi farlo tranquillamente, quello di dichiarare una funzione con nome 
uguale a quello di un comando è usato proprio per personalizzare il 
comando, sia per gli operatori, che per altri programmi (a volte gli 
alias non bastano o non vengono visti).
 
Alla fine se funziona e ti va bene, è ok.

 Una buona ipotesi.
 
Ipotesi...?!?!?
Diciamo che solo una mia *teoria*, e dato che hai introdotto il 
discorso, vorrei conoscere la tua, o meglio, quella comune.
 
"Hai capito perche` hanno fatto in quel modo?"
 
Perchè?

 Perchè?
 
Dai per scontato che io l'abbia capito.
 
Secondo me hai ragione, interessava mantenere
l'interfaccia, con un *minimo* cambiamento.
 
Qui credo sia fondamentale il "minimo".
Cioe` il cambiamento non causa funzionamenti
differenti, solo un output colorato (quando
possibile).
 
Sarebbe stato molto diverso se avessero
aggiunto, chesso`, un "-i".
 
Pero`, non avendo ricercato sull'argomento, e
quindi non potendo confermare o negare tale
teoria, suggerirei di non prendere come esempio
quella configurazione.
 
bye,
 
-- 
 
piergiorgio

 aggiunto, chesso`, un "-i".
 
Esatto.
 


perché evidentemente lo ritengono utile e sufficientemente generico.
l'esempio che invece avevi fatto te di rsync non era generico ma 
specializzato ad un determinato contesto / uso. 


Un esempio banale di una stortura che si può toccare con mano:
 
ls --color |less
 
Cosa vedete?
Avvertenza per vedere come sono richiamati dalla shell:
- alias ls
- alias less
 
 
 
Quindi:
se io avessi un alias del tipo:
 
alias ls='ls --color'
 
E provassi a fare:
 
ls | less
 
Cosa molto utile e ricorrente, avrei un output del cavolo.
Pertanto quell’alias “ls --color” che è tanto carino perché
colorato ecc... Porta però con se delle limitazioni.
 
Niente di ché visto che si possono aggirare, ad esempio con
 
less -R
 
cioè intendo:
 
ls --color | less -R
 
Però bisogna saperlo...
Personalmente uso quella roba liscia, senza alias e quando
mi serve il colore al limite uso l’opzione --color manualmente.

 Cosa molto utile e ricorrente, avrei un output del cavolo.
 
a onor del vero non riscontro differenze ne tantomeno problemi.
 

 ne trarremmo dei grandi vantaggi!!!
 
Non mi pare che la mia frase fosse "scorretta".
 
Ci sono errori?
Se si, quali?
 
Diciamo che *tu* non la capisci.
Puo` essere che sia poco chiara in generale
o solo per te, non saprei.
 
Dovresti, pero`, anche tu impegnarti
in questo senso.
Soprattutto nel fornire piu` dettagli
quando chiedi consigli.
 
bye,
 
-- 
 
piergiorgio


Perche` l'alias e` "ls --color=auto", mentre
lui usa "ls --color" che di default e` "always".
 
Ci stavo cascando anche io... :-)
 
bye,
 
-- 
 
piergiorgio

 default e` "always".
 
less mostra a terminale la lista colorata, che non mi sembra un problema.
semmai può essere un problema se l'output non è un terminale (es. un 
file) o se l'output deve essere parsato visto che ci sono i caratteri di 
escape.
 
 


Da me, Fedora, "ls | less" mostra la
lista senza colori.
"ls --color | less" mostra la lista
con i codici di escape per i colori,
ma nessun colore.
"ls --color | less -R" mostra la lista
con i colori.
 
Non ho nessun alias per "less", forse
questa e` la differenza.
 
bye,
 
-- 
 
piergiorgio

Il 31/05/20 15:08, rootkit ha scritto:

Beh era un esempio però :D


Infatti avevo messo delle “avvertenze”, col comando
alias per verificare se ls e less sono gli eseguibili
lisci o degli alias.
 
Ricapitolando per rootkit, lancia:
 
alias ls
 
e poi
 
alias less
 
E vedi cosa ritornano in output. Se sono lisci, ovvero
se non vengono trovati aliases, allora il comportamento
dovrebbe, ragionevolmente essere quello descritto da
Piergiorgio. Che poi è lo stesso che ho anche io.
 
Ulteriore verifica paranoica:
andare a vedere se ls o less per qualche santo fossero
in realtà dei wrapper agli eseguibili veri:
 
which ls
which less
 
E poi andare a vedere se fossero esempio degli script
 
file /usr/bin/ls
 
Ed eventualmente: less /usr/bin/ls
 
Ma non dovrebbe, sono due componenti di base del sistema.

 Con nome diverso, forse vanno bene.
 
  Dipende.  Servisse di sostituire tutte le esecuzioni del comando
nativo allora il nome *deve* essere uguale.
 
 
  Ciao,
 
 
Alessandro
 
 
 

 eseguire più comandi e possono implementare una logica.
 
  Infatti.
 
 
  Ciao,
 
 
Alessandro
 

 nativo allora il nome *deve* essere uguale.
 
Per prima cosa, non credo sia un
caso proprio comune.
 
Secondariamente, sarebbe il caso
sempre e comunque di programmare
in modo pulito.
 
E soprattutto, come gia` scritto, di
sapere quello che si stia facendo.
 
Quindi, che sia possibile scrivere
programmi con "goto" e variabili
globali, non vuol dire si debba fare.
 
Qui siamo su "iniziare", diamo consigli
da "iniziare".
 
bye,
 
-- 
 
piergiorgio

 è stato impostato così proprio per farlo.
 
Ma cosa scrivi?
 
Quando, dopo un anno, si da un "rsync"
chi si ricorda se e` alias, funzione
o comando?
E se qualcun altro prende in mano il
sistema? Sai che caos...
 
Non e` una buona cosa creare queste
situazioni, a meno che non vi siano
delle ragioni ben specifiche e chiare.
 
Che sia possibile fare porcherie e`
chiaro, che a volte si debbano fare
anche, ma non deve essere la norma.
 
bye,
 
-- 
 
piergiorgio

 /usr/bin/rsync o un alias.
 
certo, a condizione che abbia buona memoria e se lo ricordi.

Il 01/06/20 17:39, rootkit ha scritto:

Comunque tanto per restare in tema, è il caso anche di aggiungere un 
prefisso ***my-*** anche per i file contenuti nella dir ~/bin ?

 prefisso ***my-*** anche per i file contenuti nella dir ~/bin ?
 
è il caso di applicare ad ogni problema la sua soluzione. che senso hanno 
queste domande? non è che strumenti come alias uno li deve usare per 
forza, pensa prima a cosa vuoi ottenere e poi capiamo *se* e *come* gli 
alias possono essere la soluzione.
 
per esempio, l'uso tipico è per *semplificare* la digitazione. in 
quest'ottica che senso ha mettere un prefisso che la complica? se vuoi 
creare un alias/funzione di rsync che esegue un backup la chiami, ad 
esempio, rb. 
 
se usi bash installando questo tool potresti trovare un sacco di cose già 
fatte:
https://github.com/ohmybash/oh-my-bash
 
omologo del più famoso per zsh, shell che personalmente preferisco:
https://github.com/ohmyzsh/ohmyzsh
 
 
 

 anche, ma non deve essere la norma.
 
  La norma è che chiunque debba essere libero di personalizzare il
proprio ambiente, le intefacce statiche e non modificabili sono una
delle facce del male.
 
 
Alessandro
 
 

 certo, a condizione che abbia buona memoria e se lo ricordi.
 
  Sapere quello che si fa è sempre molto importante in qualunque
contesto.  Che ci sia gente che invece non lo9 fa non è na buona ragione
per imepdire a tutti di personalizzare la propria shell secondo le
proprie preferenze o necessità.
 
 
Alessandro
 

 avere delle conseguenze gravi.
 
  Ho scritto male:
 
  Se quello è l'uso che faccio sempre o quasi di rsync, voglio essere
sicuro che per errore *non* salti la creazione del backup, la cui
assenza potrebbe avere delle conseguenze gravi.
 
 
Alessandro
 

 da "iniziare".
 
  alias e funzioni sono infatti l'ABC della shell Unix.
 
 
  Ciao,
 
 
Alessandro
 

 proprie preferenze o necessità.
 
sapere quello che si fa è diverso dal doversi ricordare quello che si è 
fatto.
 

 fatto.
 
  Anche ricordarsi che cosa fa uno script è difficile, non meno del
ricordarsi che cosa fa un alias o una funzione.  Se uno non ricorda che
cosa ha fatto allora è meglio che si dedichi al gioco delle bocce e
lasci perdere i computer e l'amministrazione di sistema.
 
 
Alessandro
 

 lasci perdere i computer e l'amministrazione di sistema.
 
ma se io chiamo l'alias/funzione con un nome o acronimo univoco e 
sigificativo poi non ho alcun bisogno di ricordare quello che fa. per me 
gp sta per "git push", gup sta per "git pull --rebase" e così decine e 
decine di altri comandi (*). altro discorso è se chiamo l'alias/funzione 
rsync perché allora sì mi devo ricordare di averlo sovrascritto e in che 
modo ne ho modificato il comportamento. ho dubbi su chi debba dedicarsi 
al gioco delle bocce.
 
(*) 
https://github.com/ohmyzsh/ohmyzsh/wiki/Plugins
 
 
 
 
 

 (*) 
https://github.com/ohmyzsh/ohmyzsh/wiki/Plugins
 
 
  E quindi?
 
 
  Ciao,
 
 
Alessandro
 

   E quindi?
 
quindi nulla, è un rimando.

 ricordare nulla. 
 
  Stiamo parlando di alias e funzioni di shell.  Che se proprio la tua
memoria fa a gara con quella dei pesci rossi puoi comunque mettere in
ansible pure loro.
P.S. tu non ti ricordi nulla di ansible quando lo usi?  Non ti aiuti mai
con alias e funzioni per usarlo?
 
 
Alessandro
 
 

 delle facce del male.
 
Ah! Quindi se un domani "libc" od il "kernel"
cambiassero interfacce pubbliche (come faresti
tu per "rsync") andrebbe, per te, bene?
Nessuno programma funziona piu`, ma "le interfacce
statiche e non modificabili sono una delle
facce del male".
 
Di conseguenza "we do not break user space" e`
anche una malvagita`.
 
Tra due scelte equivalenti (rsync o rsync_backup)
conviene sicuramente prendere quella con meno
rischi (a meno di non avere una ragione precisa,
chiara e valida, per scegliere l'altra).
 
bye,
 
-- 
 
piergiorgio

    alias e funzioni sono infatti l'ABC della shell Unix.
 
Cosi come evitare problemi.
Almeno per i non esperti.
 
Quindi, perche` dare suggerimenti che
_sicuramente_ causano problemi ai non
esperti?
 
bye,
 
-- 
 
piergiorgio

 caso proprio comune.
 
Nel 95% (o più) delle distro "ls" è un alias.
In molte altre (per esempio Ubuntu) anche "grep" è un alias.
 
-- 
Cio' che si vede, e'.
 

 In molte altre (per esempio Ubuntu) anche "grep" è un alias.
 
Abbiamo gia` discusso questo.
 
E la domanda era: avete capito perche`?
 
bye,
 
-- 
 
piergiorgio

 con alias e funzioni per usarlo?
 
anche sì, ma quello che è certo non per sovrascrivere il comando. 

 infatti voleva ridefinire il comando originale.
 
Mai detto nulla di simile.


Io rispondevo solo al fatto che tu dicessi che non era un caso molto
comune.


 distribuzioni installando alias per i comandi ls, which o grep, ad esempio.
 
Ma lo fanno in modo trasparente/innoquo (lavorando solo sull'aspetto, 
sulla colorazione, ecc.), e senza creare _interferenze_.
 
Hai presente due macchine uguali con colore diverso?
Stessa motorizzazione, stesse omologazioni, ecc.
 
Nessuna delle due osa violare/alterare i principi di guidabbilità, 
sicurezza, ecc.
 
L'unica differenza è soddisfare i gusti personali del proprietario, e 
sempre stando entro certi limiti.


io credo si sia fatta molta confusione in questa discussione e chi legge 
non ne trae molto giovamento.
 
siamo partiti da un esempio e una domanda di un neofita: l'esempio era 
palesemente scorretto, ma si è finiti a discutere del concetto generale 
al punto che l'op potrebbe a questo punto concludere che il suo esempio è 
corretto.
 
se io sono un neofita e chiedo se è prassi accettabile customizzare con 
una funzione/alias un comando esistente la risposta è certamente sì: ma 
se io corredo la domanda con un esempio del tipo 
"alias rm='rm -rf $PIPPO'" 
qualcuno dovrà pure dirmi che non lo sto intendendo nel modo giusto. 

 comune.
 
Infatti non lo e`.
 
Quante volte capita che *l'utente* cambi
un comando di *sistema*?
 
"ls" o "grep" come alias sono gia` forniti
cosi` dalla distribuzione.
Sono _standardizzati_ in questo modo.
 
E` irrilevante, per l'utente, come siano
effettivamente realizzati.
 
E` invece molto rilevante il caso in cui
sia *necessario* per l'utente andare a
modificare uno *standard* del sistema.
 
byem,
 
-- 
 
piergiorgio

 corretto.
 
La mia conclusione: salvo eccezioni, non sovrascrivere i comandi originali.
Contento? :D

 un comando di *sistema*?
 
Forse, forse, .... hanno convertito ls e grep in alias perché se non
l'avessero fatto loro il 99% degli utenti l'avrebbe comunque fatto.
Forse, eh.


 Forse, eh.
 
il 99% degli utenti non sa nemmeno che esistono le directory escluse 
dall'alias di grep.
 

Intendi dire che per te rsync non ha molteplici impieghi quotidiani? Perchè
altrimenti stai negando ciò che hai scritto e quindi "o ci sei o ci fai".

 esperti?
 
  Perché ne provocano solo alle capre.
 
 
  Ciao,
 
 
Alessandro
 
 

Il 06/06/20 13:56, Marco ha scritto:

  In RedHat/CentOS/Fedora anche which.
 
 
Alessandro
 
 
 

 modificare uno *standard* del sistema.
 
  La necessità è la solita: "Perché così voglio fare *io* sul *mio*
sistema".
 
 
 
  Ciao,
 
 
Alessandro
 
 

Il 06/06/20 14:48, rootkit ha scritto:

  Far rielvare i possibili usi erronei dell'alias è una cosa diversa dal
dire che ridefinire i comandi di sistema non sarebbe standard e che
alias e funzioni non sono stati pensati per ridefinire i comandi interni
o i file eseguibili di sistema.
  Sottolineo: ridefinire, non sostituire, perché nel caso degli alias è
facilissimo dire alla shell di eseguire il comando originale ignorando
eventuaoli alias.
 
 
  Ciao,
 
 
Alessandro.
 
 


Vero, e per molto tempo mi ricordo che molte distro creavano alias di rm e
mv per eseguirli con l'opzione -i.


 chiara e valida, per scegliere l'altra).
 
  E ho ripetutaemnte scritto infatti che è la cosa da fare quando serve
di ridefinire il comportamento di default di rsync, ma da quell'orecchio
non ci hai mai sentito.
 
 
  Ciao,
 
 
Alessandro
 
 
 

 anche sì, ma quello che è certo non per sovrascrivere il comando. 
 
  Alias e funzioni non sovrascrivono il comando originale che rimane
comunque sempre a disposizione.  Nel caso degli alias anzi è
particolarmente facile usarlo senza ricorrere agli alias, e la cosa è
stata fatta proprio per questa ragione: perché è sia possibile che
frequente che un comando sia ridefinito con un alias.
 
 
  Ciao,
 
 
Alessandro
 
 

 È una buona pratica usare una funzione omonima per modificare un comando già esistente a proprio piacimento? 
 
  La ridefinizione era già fatta, e quindi era evidentemente tua
intenzione ridefinire il comando.
  Sulla "buona pratica" la risposta è sicuramente si, perché le shell
Unix sono state fatte apposta sia per definire alias e funzioni che
precedono i comandi interni e i file eseguibili, sia per saltare
facilmente la ricerca di un comando negli alias.
 
  Un amministratore ha tutta la libertà di ridefinire i comandi che
vuole nel modo che vuole, farlo è buona pratica.  Se uno lo fa male o
trova che ridefinire comandi lo porta a frequenti errori allora non lo
fa.  Sono scelte personali, ognuno fa quello che lo fa lavorare meglio
con qualsiasi strumento che il sistema gli mette a disposizione.
 
 
  Ciao,
 
 
Alessandro
 

 sempre stando entro certi limiti.
 
  Nei *miei* sistemi, sia miei personali che quelli che sono posti sotto
la mia esclusiva pertinenza e responsabilità, i limiti li definisco io.
 Gli altri limiti, quelli si che sono interferenze.
 
 
  Ciao,
 
 
Alessandro
 
 

 intenzione ridefinire il comando.
 
Proprio per niente: hai dato tutto per scontato.
Era solo un disegno/schizzo su ciò che ***avrei*** voluto, o meglio 
***proposto***, di fare.

   Gli altri limiti, quelli si che sono interferenze.
 
????
boh

   Trasparente in che senso?  
 
nel senso che sono degli enhancement del comando.

Il 07/06/20 13:04, rootkit ha scritto:

Ma neanche questo: non viene *aggiunto* ne *tolto* niente.
Ad esempio vengono solo fatte delle sostituzioni dal punto di vista 
estetico: il rosso al posto del colore di default, ecc.
L'unica cosa che viene pseudo-aggiunta (sottolineo *pseudo*) all'output 
sono solo i caratteri di escape per cambiare la colorazione.
Il contenuto dell'output resta assolutamente inalterato: non una virgola 
in più, non una virgola in meno.
Cambia l'aspetto, non il contenuto.


Premesso che non ho seguito tutto il topic.
Però occhio che se usi il comando in uno script e lo dai in
pipe a qualcos’altro potresti avere sorprese proprio perché
i caratteri di escape non sono solo aspetto ma anche contenuto.
 
Esempio che avevo già fatto o simile:
 
alias ls="ls --color"
ls -1 |grep "txt$"
 
In questo caso vado a cercare tutti i files della dir corrente
che terminano con txt, presumibilmente quindi dei file di testo,
ma non importa quello.
Se nella directory ho un effettivamente file del tipo "*txt",
questi dovrebbero apparire in output al secondo comando di cui
sopra.
Invece non appaiono, proprio a causa dei caratteri d’escape!
 
L’alias potrebbe essere impostato in .bashrc o da qualche altra
parte che non so o non ricordo. E quando uso il comando “ls” in
uno script, quell’alias mi conduce ad errori insidiosi, proprio
perché poi non si riesce facilmente a capirne la causa.
 
In altre parole sarebbe meglio ad esempio, fare un alias con altro
nome per ottenere un output bello colorato:
 
lsc
lls
lss
ecc ecc

 lss
 
Poi questi acronomi...
OK che i nomi brevi sono comodi, però...
 
Non sai quante volte invece di scrivere ls, scrivo ln.

 ***proposto***, di fare.
 
  Stessa cosa.  La risposta rimane uguale: si, è buona pratica, se è
quello che ti serve è quello che infatti si fa, tanto che è stato
appositamente reso facile farlo, di creare un alias che ridefinisca un
comando interno/su filesystem.
  Se invece il farlo interferisce con altri usi del comando no.  In ogni
caso, il punto è che ti sono resi disponibili gli strumenti per fare
quello che ti pare, secondo tua discrezione, comodità e responsabilità.
 Il che implica un certo numero di considerazione per noi terzi non
possibili da esprimere in assenza di informazioni come:
1) su che tipo di sistema dev'essere implementato l'alias, un sistema
desktop o un server;
2) il sistema è tuo personale o è usato da altri utenti;
3) l'alias sarà definito localmente in una procedura o per un utente o
globalmente per tutti gli utenti.
 
 
  Ciao,
 
 
Alessandro
 

Il 07/06/20 13:04, rootkit ha scritto:

  Miglioria/estensione e trasparente non sono sinonimi.
 
 
Alessandro
 
 

 boh
 
  Quello che non puoi fare nei *tuoi* sistemi informatici per limiti
imposti da terzi è un'ovvia e pesante interferenza su quello che tu
potresti voler o dover fare con i *tuoi* sistemi per i *tuoi* scopi.  Il
software libero è nato soprattutto per questa ragione.
 
 
  Ciao,
 
 
Alessandro
 

 Non sai quante volte invece di scrivere ls, scrivo ln.
 
Perché mai, se usi spesso la shell:
 
ls --> sta per list
ln --> sta per link
 
Ad ogni modo...
Hai ragione tu. L’alias in script effettivamente non funziona
ammenoché per qualche santo non venga richiamato in qualche
modo esotico:
 
bash -i pippo.sh
 
Mi pareva di ricordare diversamente. In passato mi era capitato
che per colpa di un alias nessuno riusciva più a venire fuori
ad un problema e da quella volta l’avevo eliminato.
 
Vero quello che riporti circa grep in pipe a ls, meglio usare
find in generale. Ma il mio era solo un esempio per mostrare
la stortura che può produrre.
 
Chi non ha mai dato a shell ls|grep qualcosa, scagli la prima
pietra!
 
(O un ls |less)
 
Io mi tengo il mio list “as is”.
 
PS.
Uso slackware-14.2

 frequente che un comando sia ridefinito con un alias.
 
ma se invece di tutto 'sto film visto che fa un'altra cosa lo chiamasse 
con un nome diverso non sarebbe ancora più semplice?
 

 ...
 
https://www.lopsicologoonline.it/manipolatore/
 

 software libero è nato soprattutto per questa ragione.
 
STUPIDO!!!

 bash -i pippo.sh
{...cut...}
 
Invece dell'alias, si può definire ed esportare una funzione, nel ~/.bashrc:
 
  mia_funzione() {
      echo "HELLO!"
  }
  export -f mia_funzione
 
così "mia_funzione" si può attivare dall'interno di uno script (AKA subshell).

 la stortura che può produrre.
 
Ma non succede nulla di grave alla fine.
Per quanto ne so grep (insieme a cat, ls, less, diff, ecc.) non sono 
comandi che dovrebbero far danni.
Poi c'è rsync, rm, mv, cp... che naturalmente sono tutt'altra cosa.
 

 Poi c'è rsync, rm, mv, cp... che naturalmente sono tutt'altra cosa.
 
Be’ possono far perdere tempo tanto per cominciare ed è
sempre un danno: più o meno grave dipende da chi lo perde.
In generale ritengo sensato per quel che mi riguarda, non
utilizzare alias/funzioni/scripts nominati come comandi già
esistenti quali ls, grep, less, rsync, rm, ecc ecc...
E mi pare con questo di rispondere al tuo messaggio iniziale,
poi tutto si può fare, ma nel tuo caso ti basta chiamare quella
funzione “backup” invece di rsync. Hai un comando semplice da
ricordare e richiamare e non coinvolgi il rsync originale in
eventuali dispute di omonimia.
Detto questo ovviamente libero di scegliere la soluzione che
più di aggrada.

 STUPIDO!!!
 
  Dillo cento volte davanti allo specchio.
 
 
  Ciao,
 
 
Alessandro
 

 
https://www.lopsicologoonline.it/manipolatore/
 
 
  Lo stupido che non sa prevalere dialetticamente ricorre all'insulto
nella sua frustrazione.
 
 
 

 con un nome diverso non sarebbe ancora più semplice?
 
  Si se lo può fare, se quello che gli serve non è quello di far
funzionare rsync in una maniera diversa ogni volta che sia eseguito con
il suo proprio nome.  O se preferisce farlo.  Rimane comunque il fatto
che ridefinire un comando con un alias o una funzione è pratica comune e
buona tutte le volte che aiuta.
 
 
  Ciao,
 
 
Alessandro
 

 Poi c'è rsync, rm, mv, cp... che naturalmente sono tutt'altra cosa.
 
  Neanche --backup può fare danni, perché esistessero file sulla
cartella di destinazione sarebbero rinominati, non sovrascritti.  Da man
rsync(1):
 
   -b, --backup
          With this option, preexisting destination files are renamedas
          each  file is transferred or deleted.
 
  Ciao,
 
 
Alessandro
 

 buona tutte le volte che aiuta.
 
comune non lo è e questo è dato oggettivo. sul "buona" non sono d'accordo 
e se prima potevo avere qualche dubbio dopo questa discussione me li sono 
tolti.
 

 tolti.
 
Ormai ho capito che questo A. Selli è un soggetto affetto da forte 
coglionagine, narcisismo, ecc. :D
 

Il 08/06/20 04:49, Alessandro Selli ha scritto:

Certo, e naturalmente è da intendere come affermazione autoreferenziata.
 

 eventuali dispute di omonimia.
 
Meglio my-backup: è ancor meno generico.
 

 tolti.
 
  Ri-sticazzi 
https://it.wiktionary.org/wiki/%27sti_cazzi
 
 
 
  Ciao,
 
 
Alessandro
 
 
 

Il 08/06/20 15:18, alex ha scritto:

  Studia, imberbe:
 
https://it.wikipedia.org/wiki/Proiezione_(psicologia)