Estensioni di file per script shell unix [chiuso]

45

Su Wikipedia, l'articolo per .sh dice:

Per il tipo di estensione di file .sh, vedere Bourne shell .

Che ne dici di altre shell unix?

So che lo shebang è usato all'interno del file per indicare un interprete per l'esecuzione, ma mi chiedo:

Quali sono i vantaggi e gli svantaggi delle estensioni di file rispetto a nessuna estensione di file?

— Amelio Vazquez-Reina
fonte

4

A volte, è possibile trovare script di shell senza shebang (o senza autorizzazioni exec). In tal caso, un nome che termina con .sh può essere un suggerimento per l'utente con cui eseguirlo bash script.sh(o sh, ovviamente).

— Ansgar Esztermann,

3

Se uno script di shell ha un'estensione è comunemente .sh. Non ho mai visto uno script .ksh o .bash. La maggior parte degli script di shell non ha estensione, come tutti gli script in /etc/init.d/* come esempio.

— Richard Holloway,

Mentre una conclusione semplicistica (sì o no) è opinione, le cose da considerare non lo sono.

— ctrl-alt-delor

35

Chiamerei solo .shqualcosa che dovrebbe essere portatile (e si spera sia portatile).

Altrimenti penso sia meglio nascondere la lingua. Il lettore attento lo troverà comunque nella linea shebang. (In pratica, .basho .zsh, ecc., I suffissi vengono usati raramente.)

— Stéphane Gimenez
fonte

1

Da questa sola pagina, possiamo già vedere un numero piuttosto non banale di persone che lo utilizzano. Perché dici che sono "usati raramente"? Qualche citazione? O è semplicemente basato sulla tua esperienza?

— Pacerier,

23

Direi che non esistono "buone pratiche" per le estensioni di file, rigorosamente per un aspetto tecnico: i file system Unix / Linux / * BSD non supportano le estensioni di per sé. Quello che stai chiamando un'estensione è semplicemente un suffisso di un singolo nome di file. È diverso rispetto ai file system e ai sistemi operativi VM / CMS, VMS, MS-DOS e Windows in cui un posto speciale nell'inode-morale-equivalente è riservato per un'estensione.

Quel piccolo rant ora finito, penso che sia un po 'sciocco mettere un suffisso ".sh" o ".ksh" o ".bash" sul nome di un file di script di shell. Un programma è un programma: non esiste alcun vantaggio nel distinguere ciò che viene eseguito. Nessun unix o linux o qualunque kernel abbia deciso di chiamare un interprete su un file solo a causa del suffisso del nome di un file. È tutto fatto dalla #!linea o da qualche altra sequenza di byte "numero magico" all'inizio del file. In effetti, decidere cosa eseguire in base a un'estensione di nome file è uno dei fattori che rendono Windows un magnete del malware. Guarda quante truffe di malware di Windows coinvolgono un file chiamato "something.jpg.exe": per impostazione predefinita, le versioni più recenti di Windows non mostrano l'estensione ".exe" e incoraggiano un utente a fare doppio clic su "

Quello che potresti pensare come un comando diretto è spesso comunque uno script di shell. A volte ccè stato uno sh-script, firefoxè uno sh-script, startxè uno sh-script. Non credo ci sia un vantaggio cognitivo o organizzativo nel contrassegnare una sceneggiatura con il suffisso ".sh".

— Bruce Ediger
fonte

24

Non sono d'accordo! Il mio lavoro consiste nel confezionare un'applicazione che coinvolge migliaia di file che vanno da eseguibili binari a script di shell (ksh, bash e alcuni csh legacy). Per me, credimi, fa la differenza poter sapere in un colpo d'occhio (o in una regex) che tipo di file stiamo discutendo e che stiamo cercando. Il mio punto è che potrebbe esserci un vantaggio nel distinguere ciò che viene escluso e una buona pratica dovrebbe incoraggiare a dichiarare esplicitamente il tipo di file.

— Rahmu,

4

@rahmu: scrivilo come una risposta. Fornisci alcuni dettagli su come i nomi distinguibili da regex ti aiutano a impacchettare (e forse a mantenere) quell'applicazione. Nota in particolare l'interazione tra ciò che interpreta il file e il suffisso del nome del file e come ciò ti aiuta a svolgere le attività. Sono interessato a seri argomenti contro il mio punto di vista e sono disposto a cambiare se ne sono convinto. Ho votato il tuo commento per dimostrarlo.

— Bruce Ediger,

3

Mi piacerebbe, purtroppo posso solo parlare della mia attuale esperienza nel mio attuale lavoro. Non so molto di buone pratiche e standard in generale ; Sento che dovrei fare qualche ricerca prima di pubblicare una risposta qui. Lo esaminerò stasera dopo il lavoro :)

— Rahmu,

2

@rahmu Il comando "file" esiste per determinare il tipo di file. È in grado di distinguere gli script scritti per diverse shell.

— Matt,

3

Se si dà a uno script shell .shun'estensione, è necessario digitarla .shcome parte del nome del comando all'avvio. Questo è il motivo principale per cui non mi piace inserire tale estensione (lo stesso con qualsiasi cosa che abbia una linea shebang). A proposito, il problema in Windows non è il .exeprefisso di per sé (è banale creare un eseguibile chiamato image.jpgin Linux, dopo tutto), ma il fatto che Windows di solito nasconda tale estensione, combinato con il fatto che l'azione doveva avviare un eseguibile e aprire un documento è esattamente lo stesso.

— Celtschk,

12

Come uno che ha lavorato in una moltitudine di ambienti? Nix, ho dovuto scrivere in un'ampia varietà di shell. Che ci crediate o no, attraverso le piattaforme, le conchiglie non sono uguali. Quindi se mantenete la vostra libreria personale in più shell (quando necessario) è molto utile usare le estensioni per identificare le shell. In questo modo quando ti sposti su un'altra piattaforma e la shell è leggermente diversa, sai quali script scegliere come target per le modifiche. .sh .ksh .bsh .csh ...

— Jumpylodo
fonte

Ciò sembra concordare con unix.stackexchange.com/questions/31760/…

— Pacerier

Non hai un #!all'inizio dello script (ad es. #!/bin/bash)?

— ctrl-alt-delor

Gnu / Linux, BSD e UNIX sono tutti Unix. Non c'è bisogno di? Nix. Linux è un kernel, Android ha utilizzato Linux ma non è Unix (a meno che non si aggiunga software aggiuntivo, nel qual caso si dispone di un'app Unix).

— ctrl-alt-delor

@ ctrl-alt-delor: "Unix" è un marchio registrato . Le persone usano spesso "? Nix" per evitare il problema del marchio (e dei pedanti).

— JS.

@JS `UNIX 'è un marchio di The Open Group. Unix e unix non sono greens.org/about/unix.html

— ctrl-alt-delor

6

Non è necessario utilizzare un'estensione per gli eseguibili, in quanto non sono intercambiabili. Immagina di avere uno script di shell a.sh, quindi riscrivere in Python a.py, ora devi cambiare ogni programma che ti chiama script, hai fatto trapelare i dettagli dell'implementazione.

L'intera estensione del nome file in Windows di Mircosoft è un casino: per esempio ciò che avrebbe potuto essere a.audio, b.audio, c.audio, è a.mp3, b.wav, c.ogged d.picture, e.picture, f.pictureè d.jpeg, e.png, f.gif. Il più delle volte non ci interessa in quale formato sia l'audio o l'immagine. Dobbiamo anche passare molto tempo a insegnare ai nuovi utenti tutte le estensioni dei file.

— ctrl-alt-Delor
fonte

Un altro motivo per non usarlo *.shmi sono imbattuto nel fatto che Debian run-partsnon eseguirà script con estensioni, come in /etc/cron.*/: archive.oreilly.com/pub/post/runparts_scripts_a_note_about.html

— Ross Patterson

5

Come hai detto, le estensioni dei file Unix sono puramente informative. Hai solo bisogno del tuo script per avere un shebang corretto ed essere eseguibile.

Puoi non avere estensione o usare .sh.

Personalmente uso le seguenti convenzioni, indipendentemente dalla shell usata (csh, tcsh, bash, sh, ...):

nessuna estensione per script di sistema o di alta qualità (estremamente rara).
il .shper script classici, da basso ad alto grado.

— Ouki
fonte

Che cosa intendi con "script classici, da basso ad alto grado"?

— Pacerier,

Penso di voler dire astrazione o livello organizzativo con quello. Cioè non ti interessa quale strumento di linguaggio / script sia usato dietro alcuni comandi: quindi non usi alcuna estensione. Per altri, è bene sapere che si tratta di uno script di shell bash o esotico ksh (con l'estensione appropriata). ... ma è stato 2 anni fa;)

— Ouki,

3

Le estensioni degli script Shell sono abbastanza utili. Ad esempio, scrivo spesso script con più file in più lingue (ad es. Bash, awk e lua) nella stessa directory. Se ho bisogno di cercare una stringa solo nei file bash, l'estensione lo rende molto utile, per ridurre i falsi positivi. O se voglio fare un conteggio di riga di tutto il mio codice bash per quel progetto.

È difficile dover digitare l'estensione durante l'esecuzione del programma, quindi creo anche un collegamento simbolico senza l'estensione dell'eseguibile principale, per modificarlo / eseguirlo senza dover digitare l'estensione ogni volta. I link simbolici sono economici e facili.

— Steve
fonte

Ciò sembra concordare con unix.stackexchange.com/questions/31760/…

— Pacerier,

2

Come altri hanno già detto, alla shell non interessano le estensioni. Tuttavia, consente una rapida identificazione umana dei file. Vedo i file che finiscono in .pyo .she so rapidamente cosa dovrebbero (almeno) essere. Come dice Steve, anche la ricerca per estensione di file o il conteggio delle righe sono considerazioni pratiche.

— QWR
fonte