Filtillägg för unix-skalskript [stängt]

Jag skulle bara kalla .sh något som är tänkt att vara bärbar (och förhoppningsvis är bärbar).

Annars tycker jag att det bara är bättre att dölja språket. Den noggranna läsaren kommer hitta den i shebang-raden ändå. (I praktiken används .bash eller .zsh, osv … suffix används sällan.)

Kommentarer

• Från denna sida ensam kan vi redan se en ganska liten mängd människor som använder den. Varför säger du att de är " används sällan "? Några citat? Eller är det bara baserat på din erfarenhet?
• Jag skulle använda .bash om det ' är avsett att hämtas med ett annat skript och är endast kompatibelt med bash, etc. Om det kan hämtas från något borne-kompatibelt skal som sh, dash , eller bash, skulle jag ge det en .sh -tillägg. Om det ' är avsett att köras skulle jag inte ' inte lägga till ett tillägg.

Jag skulle säga att det inte finns några ”goda metoder” för filtillägg, helt på ett tekniskt sätt: Unix / Linux / * BSD-filsystem inte supporttillägg i sig. Det du kallar ett tillägg är bara ett suffix av ett enda filnamn. Det skiljer sig från VM / CMS-, VMS-, MS-DOS- och Windows-filsystem och OSS där en speciell plats i inoden- moral-ekvivalent är reserverat för en förlängning.

Det lilla rantet nu över, jag tycker att det är ”lite dumt att lägga ett” .sh ”eller” .ksh ”eller” .bash ”suffix på ett skal skriptfilnamn. Ett program är ett program: det finns ingen fördel med att skilja vad som körs. Ingen unix eller linux eller vilken kärna som helst har beslutat att ringa en tolk på någon fil bara på grund av ett filnamnssuffix. Det är allt gjort av #! -rad eller någon annan ”magiskt nummer” -sekvens av byte vid början av filen. Att bestämma vad som ska köras baserat på filnamnet ”förlängning” är faktiskt en av de faktorer som gör Windows till en skadlig magnet. Titta på hur många Windows-malware-bedrägerier som involverar en fil med namnet ”something.jpg.exe” – som standard visar nyare Windows inte ”.exe” -tillägget och uppmuntrar en användare att bara dubbelklicka på ”bilden”. en bildvy som körs, skadlig programvara körs.

Vad du kanske tänker på som ett rakt framåtkommando är ofta ett skalskript ändå. Ibland har cc varit en sh-script, firefox är ett sh-script, startx är ett sh-script. Jag tror inte att det finns en kognitiv eller organisatorisk fördel med att markera ett skript med suffixet ”.sh”.

Kommentarer

• Jag håller inte med! Mitt jobb består i att packa in en applikation som omfattar tusentals filer som sträcker sig från binära körbara filer till shell-skript (ksh, bash och lite äldre csh). För mig, tro mig det gör en skillnad för att kunna få veta en blick (eller i en regex) vad typ av fil vi diskuterar och vi letar efter. Min poäng är att det kan b e en fördel med att urskilja vad som exciteras och en bästa praxis bör uppmuntra till att uttryckligen ange typ av fil.
• @rahmu: skriv upp det som ett svar. Ge några detaljer om hur regex-urskiljbara namn hjälper dig att paketera (och kanske underhålla) den applikationen. Observera specifikt interaktionen mellan vad som tolkar filen och filnamnet ' s suffix och hur det hjälper dig att utföra uppgifter. Jag ' är intresserad av allvarliga argument mot min synpunkt och jag ' är villig att ändra om jag ' jag är övertygad. Jag röstade upp din kommentar för att bevisa det.
• Jag skulle gärna vilja, tyvärr kan jag bara tala om min nuvarande erfarenhet av mitt nuvarande jobb.Jag ' vet inte mycket om god praxis och standarder i allmänhet ; Jag känner att jag borde undersöka innan jag skickar ett svar här. Jag ' Jag tittar på det ikväll efter jobbet 🙂
• @rahmu " -filen " -kommandot finns för att bestämma filtyp. Den kan skilja skript skrivna för olika skal.
• Om du ger ett skalskript ett .sh -tillägg, ' ll måste skriva det .sh som en del av kommandonamnet när du startar det. Att ' är den främsta anledningen till att jag inte ' inte gillar att sätta den förlängningen i (samma sak med allt som har en shebang-linje). BTW, problemet i Windows är inte .exe prefixet per se (det ' är trivialt för att göra en körbar med namnet image.jpg trots allt i Linux), men det faktum att Windows vanligtvis döljer tillägget, kombinerat med det faktum att åtgärden som behövs för att starta en körbar och för att öppna ett dokument är exakt densamma.

Som en som har arbetat i en mängd? nix-miljöer har jag varit tvungen att skriva i en mängd olika skal. Tro det eller ej, över plattformarna är skalen inte desamma. Så om du underhåller ditt personliga bibliotek i flera skal (vid behov) är det till stor hjälp att använda tillägg för att identifiera skalen. På det sättet när du flyttar till en annan plattform och skalet är något annorlunda, vet du vilka skript du ska rikta dig till modifieringar. .sh .ksh .bsh .csh …

Kommentarer

• Detta verkar stämma överens med unix.stackexchange.com/questions/31760/ …
• Har du inte #! i början av skriptet (t.ex. #!/bin/bash)?
• Gnu / Linux, BSD och UNIX är alla Unix. Inget behov av? Nix. Linux är en kärna, Android används Linux men är inte en Unix (såvida du inte lägger till extra programvara, i vilket fall du har en Unix-app).
• @ ctrl-alt-delor: " Unix " är ett varumärke . Människor använder ofta "? Nix " för att undvika varumärkesproblemet (och pedanterna).
• @JS ` UNIX ' är ett varumärke som tillhör The Open Group. Unix och unix är inte greens.org/about/unix.html

Du bör inte använda ett tillägg för körbara filer, eftersom de inte är utbytbara. Tänk dig att du har ett skalskript a.sh, skriv sedan om i python a.py, du måste nu ändra alla program som kallar dig skript , du har läckt ut implementeringsdetaljer.

Hela filnamnstillägget i Mircosofts Windows är en röra: till exempel vad som kunde ha varit a.audio, b.audio, c.audio är a.mp3, b.wav, c.ogg och d.picture, e.picture, f.picture är d.jpeg, e.png, f.gif. För det mesta bryr vi oss inte om vilket format ljudet eller bilden är inne. Vi måste också spendera lång tid på att lära nya användare alla filtillägg.

Kommentarer

• En annan anledning inte att använda *.sh Jag stötte på just det är att Debian ' s run-parts vann ' t kör skript med tillägg, till exempel i /etc/cron.*/: archive.oreilly.com/pub /post/runparts_scripts_a_note_about.html

Som du sa är Unix-filtilläggen rent information. Du behöver bara ditt skript för att ha rätt shebang och vara körbar.

Du kan antingen inte ha något tillägg eller använda .sh.

I personligen använder följande konventioner, oavsett vilket skal som används (csh, tcsh, bash, sh, …):

• inget tillägg för system- eller högkvalitetsskript (extremt sällsynt).
• .sh för klassiska skript, låg till hög kvalitet.

Kommentarer

• Vad menar du med " klassiska manus, låg till hög grad "?
• tror jag Jag menade abstraktion eller organisationsnivå med det. Det är så att du inte bryr dig ' vilket språk / skriptverktyg som används bakom vissa kommandon: så att du inte ' inte använder något tillägg. För andra är det bra att veta att det är ett bash eller något exotiskt ksh-skalskript (med rätt tillägg). … men det var för två år sedan;)

Shell-skripttillägg är ganska användbara. Till exempel skriver jag ofta skript som har flera filer på flera språk (t.ex.bash, awk och lua) i samma katalog. Om jag bara behöver söka efter en sträng i bash-filerna, gör tillägget det här mycket praktiskt för att minska falska positiva effekter. Eller om jag vill göra en radräkning av all min baskod för det projektet.

Det är ont att behöva skriva tillägget när jag kör programmet, så jag gör också en symlänk utan tillägget till den huvudsakliga körbara filen, för att redigera / köra den utan att behöva skriva tillägget varje gång. Symlänkar är billiga och enkla.

Kommentarer

• Detta verkar överensstämma med unix.stackexchange. com / frågor / 31760 / …

Som andra har sagt bryr sig skalet inte om förlängningar. Det tillåter dock snabb mänsklig identifiering av filer. Jag ser filer som slutar på .py eller .sh och jag vet snabbt vad de (åtminstone) borde vara. Som Steve säger är det också praktiska överväganden att söka efter filtillägg eller göra en radräkning.