Dovrei mettere le estensioni di file * .sh e * .rb su tutti i miei script?

Ho un sacco di script eseguibili arrotolati a mano nella mia directory $ HOME / bin. Alcuni sono scritti in bash, altri in Ruby. Tutti hanno la linea shebang in alto che dice alla shell quale interprete usare (bash o Ruby, nel mio caso).

Mi chiedo se è meglio mettere estensioni di file su questi script per indicare in quale linguaggio di scripting sono scritti? Ad esempio, gli script in Ruby avrebbero il suffisso * .rb e quelli bash avrebbero il suffisso * .sh.

Attualmente, questi script hanno solo nomi semplici senza estensione di file.

Qual è la migliore pratica?

È possibile eseguire comandi con caratteri jolly come ls *.rbo cp *.shse si desidera organizzare gli script in futuro.

Inizia presto o rimpiango più tardi, secondo me.

I redattori come vimsaranno anche in grado di applicare l'evidenziazione della sintassi corretta in base allo shebang o all'estensione del file.

Questo può essere realizzato anche usando modeline in vari editor. Ad esempio per Vim:

# vim: ft=sh

Bene - come la maggior parte delle cose nella vita: dipende dalle tue esigenze.

Hai dichiarato che questi script risiedono in una directory bin e presumo che questi script debbano essere chiamati dalla riga di comando. Come utente lo considero fastidioso se devo digitare bla.ksh o foo.bash. Anche se il codificatore decide di trasferirsi in annother interprete il nome del comando cambierebbe troppo e avrei dovuto modificare altri script che fanno uso di questi strumenti - molto fastidioso, anche se utente e coder sono la stessa persona.

Ma d'altra parte uso estensioni come .sh o .tcl nelle mie directory di build del progetto. In questo modo posso utilizzare le funzionalità di creazione per distribuire i file nelle loro directory di destinazione, ma in questa fase rimuovo il suffisso del file.

Ovviamente ci sono alcune differenze tra i file eseguibili nelle bindirectory e i file "sorgente" modificabili.

• Per i file di origine, è utile disporre di un suffisso in modo da poter vedere cosa è cosa e per aiutare alcuni strumenti meno intelligenti che non riescono a scansionare la #!linea.
• Per i moduli, vengono utilizzati solo da una serie di programmi correlati, che utilizzano tutti lo stesso interprete (o nessun interprete), ed è convenzionale includere .pm, .sho .soin tali casi.
• Per i programmi eseguibili, il suo nome fa parte del "contratto di programmazione" con cui gli utenti e altri script lo invocano. È importante che il nome non cambi anche se l'implementazione lo fa; quindi ovviamente il nome del file non dovrebbe avere un suffisso

Nel caso di un programma compilato, la differenza tra "sorgente" ed "eseguibile" è evidente: uno contiene il codice sorgente, l'altro contiene il linguaggio macchina o interpretato dal codice. Nel caso di uno script, non c'è alcuna differenza evidente, ma il makecomando mantiene una separazione nozionale tra il "codice sorgente per uno script" e la "versione eseguibile di uno script": il suo "compilatore" predefinito per "shell script" è semplicemente cp.

Consiglierei di tenere una $HOME/sourcedirectory separata e:

• mantenere un collegamento simbolico, come quello creato da ln -s ../source/foo.sh $HOME/bin/foo; o
• copiarli manualmente dopo aver apportato modifiche (e testarle), utilizzando install -m 755 foo.sh ../bin/foo; o
• utilizzando una Makefileregola per eseguire un controllo della sintassi prima di copiare il file sorgente da $HOME/sourcein$HOME/bin

Nota a piè di pagina: un modulo di script di shell è utilizzabile solo da un altro script di shell e modifica il contesto interno di quello script mediante i comandi integrati .o source. Questo è diverso da uno script eseguibile, che (come qualsiasi programma) viene eseguito come processo separato e non può modificarne il processo padre. Come convenzione approssimativa, i moduli entrano /usr/lib/name_of_program/name_of_module.shmentre i comandi entrano /usr/bin/name_of_command(senza alcun suffisso).

Non è necessario. Il kernel è già informato dell'interprete corretto da usare (per #!linea) e anche tutti i più diffusi editor di testi lo leggono, quindi aggiungere un'estensione non farebbe nulla di utile, solo aumentare la digitazione. L'unica volta in cui un programma eseguibile ha un'estensione è quando è in qualche modo importante (per il programma o l'utente o entrambi).

I moduli e le librerie, d'altra parte, hanno quasi sempre estensioni ( .rbper i moduli Ruby, .soper le librerie condivise ELF e così via).