Filutvidelser for unix shell-skript [lukket]

Jeg vil bare kalle .sh noe som er ment å være bærbar (og forhåpentligvis er bærbar).

Ellers synes jeg det bare er bedre å skjule språket. Den nøye leseren vil finn det i shebang-linjen uansett. (I praksis brukes .bash eller .zsh, osv … suffikser sjelden.)

Kommentarer

• Fra denne siden alene kan vi allerede se ganske mange mennesker som bruker den. Hvorfor sier du at de er " sjelden brukt "? Noen sitater? Eller er dette bare basert på din erfaring?
• Jeg vil bruke .bash hvis det ' er ment å hentes av et annet skript og er bare kompatibelt med bash osv. Hvis det kan hentes fra et hvilket som helst bourne-kompatibelt skall, for eksempel sh, dash , eller bash, vil jeg gi den en .sh utvidelse. Hvis det ' skulle utføres, ville jeg ikke ' ikke legge til en utvidelse.

Jeg vil si at det ikke finnes noen «god praksis» for filutvidelser, strengt tatt teknisk: Unix / Linux / * BSD-filsystemer ikke støtteutvidelser i seg selv. Det du kaller en utvidelse er bare et suffiks av et enkelt filnavn. Det er forskjellig fra VM / CMS-, VMS-, MS-DOS- og Windows-filsystemene og operativsystemene der det er et spesielt sted i inode- moral-ekvivalent er reservert for en utvidelse.

Det lille rantet nå over, jeg synes det er «litt dumt å sette et» .sh «eller» .ksh «eller» .bash «suffiks på et skall scriptfilnavn. Et program er et program: det er ingen fordel ved å skille hva som blir utført. Ingen unix eller linux eller hvilken som helst kjerne har bestemt seg for å ringe en tolk på en fil bare på grunn av et filnavn-suffiks. Det er alt gjort av #! linje, eller en annen «magisk nummer» -sekvens av byte på begynnelsen av filen. Å bestemme hva som skal utføres basert på filtypen «utvidelse» er faktisk en av faktorene som gjør Windows til en malware-magnet. Se på hvor mange Windows-malware-svindel som involverer en fil som heter «something.jpg.exe» – som standard nyere Windows ikke viser «.exe» -utvidelsen, og oppfordre en bruker til å dobbeltklikke på «bildet». en bildevisning som kjører, kjører skadelig programvare.

Det du kanskje tenker på som en rett frem-kommando, er ofte et skallskript uansett. Noen ganger har cc vært en sh-script, firefox er et sh-script, startx er et sh-script. Jeg tror ikke det er en kognitiv eller organisatorisk fordel ved å markere et skript med «.sh» -suffiks.

Kommentarer

• Jeg er uenig! Jobben min består i å pakke inn en applikasjon som involverer tusenvis av filer som strekker seg fra binære kjørbare filer til skallskript (ksh, bash og noe eldre csh). For meg, tro meg det gjør en forskjell for å kunne vite et øyeblikk (eller i et regex) hva slags fil vi diskuterer og vi leter etter. Poenget mitt er at det kunne b e en fordel ved å skille hva som blir ekskludert, og en best practice bør oppmuntre til eksplisitt å angi filtypen.
• @rahmu: skriv det opp som svar. Gi noen detaljer om hvordan regex-skillbare navn hjelper deg med å pakke (og kanskje vedlikeholde) applikasjonen. Legg spesielt merke til samspillet mellom hva som tolker filen og filnavnet ' s suffiks og hvordan det hjelper deg å utføre oppgaver. Jeg ' er interessert i seriøse argumenter mot mitt synspunkt, og jeg ' er villig til å endre hvis jeg ' er overbevist. Jeg oppstemte din kommentar for å bevise det.
• Det vil jeg gjerne, dessverre kan jeg bare snakke om min nåværende erfaring i min nåværende jobb.Jeg vet ikke ' om god praksis og standarder generelt ; Jeg føler at jeg burde undersøke meg før jeg legger ut et svar her. Jeg ' Jeg ser på det i kveld etter jobb 🙂
• @rahmu " filen " -kommandoen finnes for å bestemme filtypen. Den er i stand til å skille skript skrevet for forskjellige skall.
• Hvis du gir et skallskript en .sh -utvidelse, ' må skrive den .sh som en del av kommandonavnet når du starter det. At ' er hovedgrunnen til at jeg ikke ' ikke liker å sette den utvidelsen inn (samme med alt som har en shebang-linje). BTW, problemet i Windows er ikke .exe prefikset per se (det ' er trivielt å lage en kjørbar som heter image.jpg i Linux, tross alt), men det faktum at Windows vanligvis skjuler utvidelsen, kombinert med det faktum at handlingen som trengs for å starte en kjørbar fil og for å åpne et dokument er nøyaktig den samme.

Som en som har jobbet i en rekke? nix-miljøer, har jeg måttet skrive i en lang rekke skjell. Tro det eller ei, på tvers av plattformer er skjellene ikke det samme. Så hvis du vedlikeholder ditt personlige bibliotek i flere skall (når det er nødvendig), er det veldig nyttig å bruke utvidelser for å identifisere skallene. På den måten når du flytter til en annen plattform og skallet er litt annerledes, vet du hvilke skript du vil målrette for modifikasjoner. .sh .ksh .bsh .csh …

Kommentarer

• Dette ser ut til å stemme overens med unix.stackexchange.com/questions/31760/ …
• Har du ikke #! i starten av skriptet (f.eks. #!/bin/bash)?
• Gnu / Linux, BSD og UNIXes er alle Unix. Ingen behov for? Nix. Linux er en kjerne, Android brukte Linux, men er ikke en Unix (med mindre du legger til ekstra programvare, i så fall har du en Unix-app).
• @ ctrl-alt-delor: " Unix " er et varemerke . Folk bruker ofte "? Nix " for å unngå varemerkeproblemet (og pedantene).
• @JS ` UNIX ' er et varemerke for The Open Group. Unix og unix er ikke greens.org/about/unix.html

Du bør ikke bruke en utvidelse for kjørbare filer, da de ikke kan byttes ut. Tenk deg at du har et skallskript a.sh, og skriv deretter om i python a.py, du må nå endre hvert program som kaller deg skript , har du lekket implementeringsdetaljer.

Hele filtypen i Mircosoft Windows er et rot: for eksempel hva som kunne ha vært a.audio, b.audio, c.audio, er a.mp3, b.wav, c.ogg og d.picture, e.picture, f.picture er d.jpeg, e.png, f.gif. Det meste av tiden bryr vi oss ikke om hvilket format lyden eller bildet er i. Vi må også bruke lang tid på å lære nye brukere alle filtypene.

Kommentarer

• En annen grunn til ikke å bruke *.sh Jeg nettopp kjørte på er at Debian ' s run-parts vant ' t kjør skript med utvidelser, for eksempel i /etc/cron.*/: archive.oreilly.com/pub /post/runparts_scripts_a_note_about.html

Som du sa det, er Unix-filtypene utelukkende informasjon. Du trenger bare skriptet ditt for å ha riktig shebang og være kjørbar.

Du kan enten ikke ha noen utvidelse eller bruke .sh.

I personlig bruker følgende konvensjoner, uavhengig av skallet som brukes (csh, tcsh, bash, sh, …):

• ingen utvidelse for system- eller høykvalitetsskript (ekstremt sjelden).
• .sh for klassiske skript, lav til høy karakter.

Kommentarer

• Hva mener du med " klassiske skript, lav til høy klasse "?
• Jeg tror Jeg mente abstraksjon eller organisasjonsnivå med det. Det er at du ikke ' bryr seg hvilket språk / skriptverktøy som brukes bak noen kommandoer: så du ' t bruker noen utvidelse. For andre er det godt å vite at det er et bash eller noe eksotisk ksh shell-skript (med riktig utvidelse). … men det var for to år siden;)

Shell-skriptutvidelser er ganske nyttige. For eksempel skriver jeg ofte skript som har flere filer på flere språk (f.eks.bash, awk og lua) i samme katalog. Hvis jeg bare trenger å søke etter en streng i bash-filene, gjør utvidelsen dette veldig nyttig for å redusere falske positive. Eller hvis jeg vil gjøre en linjetelling av all baskoden min for det prosjektet.

Det er vondt å måtte skrive utvidelsen når jeg kjører programmet, så jeg lager også en symlink uten utvidelsen til den viktigste kjørbare, for å redigere / kjøre den uten å måtte skrive utvidelsen hver gang. Symlinker er billige og enkle.

Kommentarer

• Dette ser ut til å stemme overens med unix.stackexchange. no / spørsmål / 31760 / …

Som andre har sagt, bryr skallet seg ikke om utvidelser. Det tillater imidlertid rask menneskelig identifikasjon av filer. Jeg ser filer som slutter på .py eller .sh og jeg vet raskt hva de (i det minste) burde være. Som Steve sier, er det også praktiske hensyn å søke etter filtypen eller gjøre en linjetelling.