Fájlkiterjesztések az unix shell parancsfájlokhoz [bezárva]

Csak úgy hívnám a .sh -t, hogy hordozhatónak hozták (és remélhetőleg is hordozható).

Egyébként úgy gondolom, hogy jobb elrejteni a nyelvet. A gondos olvasó úgyis megtalálja a shebang sorban. (A gyakorlatban .bash vagy .zsh stb. utótagokat ritkán használunk.)

Megjegyzések

• Csak ezen az oldalon már elég nem triviális mennyiségű embert láthatunk. Miért mondod, hogy ők " ritkán használt "? Van valami idézet? Vagy ez csak a tapasztalataidon alapszik?
• a következőt használnám: .bash ha ' származik egy másik szkript, és csak a bash-szal stb. kompatibilis. Ha bármilyen bourne-kompatibilis shell beszerezhető, például sh, dash , vagy bash, adnék neki egy .sh kiterjesztést. Ha ' végrehajtásra szánja, nem tennék ' kiterjesztést.

Azt mondanám, hogy nincsenek “jó gyakorlatok” a fájlkiterjesztésekre, szigorúan technikai szempontból: Unix / Linux / * BSD fájlrendszerek nem ” önmagában támogatja a kiterjesztéseket. Amit kiterjesztésnek hív, az csupán egyetlen fájlnév utótagja. Ez különbözik a VM / CMS, VMS, MS-DOS és Windows fájlrendszerektől és operációs rendszerektől, ahol az inode- az erkölcsi egyenérték egy kiterjesztés számára van fenntartva.

Az a kis csörgés, ami véget ért, szerintem “kissé butaság, ha egy” .sh “vagy” .ksh “vagy” .bash “utótagot teszünk egy héjra szkript fájlnév. A program egy program: nincs előnye annak, hogy megkülönböztessük a végrehajtandó programokat. Nincs unix, linux vagy bármilyen kernel, amely csak egy fájlnév utótag miatt döntött úgy, hogy tolmácsot hív valamilyen fájlra. Mindezt a #! sor, vagy valamilyen más “bűvös szám” bájtsorozat a a fájl eleje. Valójában a “kiterjesztés” fájlnév alapján történő végrehajtás eldöntése az egyik tényező, amely miatt a Windows rosszindulatú programmágnévé válik. Nézze meg, hány Windows malware csalás tartalmaz egy “valami.jpg.exe” nevű fájlt – alapértelmezés szerint az újabb Windows nem “mutatja az” .exe “kiterjesztést, és arra ösztönzi a felhasználót, hogy kattintson duplán a” képre “. egy képnézet fut, a rosszindulatú program fut.

Amit egyenesen végrehajtott parancsnak gondolhat, az egyébként is egy shell parancsfájl. Néha a cc sh-script, firefox egy sh-szkript, startx egy sh-szkript. Nem hiszem, hogy létezne kognitív vagy szervezeti előny, ha egy szkriptet “.sh” utótaggal jelölünk meg.

Megjegyzések

• Nem értek egyet! A munkám abból áll, hogy több ezer programot csomagolok a bináris futtatható fájloktól kezdve a shell szkriptekig (ksh, bash és néhány régi csh). Számomra hidd el, hogy tesz nek különbséget abban, hogy egy pillanat alatt (vagy egy regex segítségével) megtudhasam egyfajta fájl, amelyet megvitatunk és amit keresünk. Az a véleményem, hogy ott lehetne b e az előnyt megkülönböztető előny és a bevált gyakorlat ösztönöznie kell a fájl típusának egyértelmű megadását.
• @rahmu: ezt írja fel válaszként. Adjon meg néhány részletet arról, hogy a regex szerint megkülönböztethető nevek hogyan segítenek az alkalmazás csomagolásában (és esetleg karbantartásában). Megjegyzendő, hogy a fájl értelmezése és a ' utótag között milyen kölcsönhatás van, és hogy ez hogyan segít a feladatok elvégzésében. ' komoly érvek érdekelnek a nézőpontommal szemben, és ' hajlandó vagyok megváltozni, ha ' meg vagyok győződve. Megerősítettem kommentedet, hogy bebizonyítsam.
• Nagyon szeretném, sajnos csak a jelenlegi munkahelyemen szerzett jelenlegi tapasztalataimról beszélhetek.Nem ' nem sokat tudok a jó gyakorlatról és a szabványokról általában ; Úgy érzem, kutatnom kellene, mielőtt ide teszek választ. Ma ' utána nézek ma este munka után 🙂
• @rahmu A " fájl " parancs létezik a fájltípus meghatározásához. Képes megkülönböztetni a különböző héjakhoz írt szkripteket.
• Ha a shell parancsfájlnak .sh kiterjesztést ad, akkor ' ll-nek be kell írnia azt a .sh -t a parancsnév részeként, amikor elindítja. Ez ' az oka annak, hogy miért nem szeretem ' ezt a kiterjesztést (ugyanaz, mint bármi, aminek van egy shebang vonala). BTW, a Windows problémája nem önmagában a .exe előtag (ez ' s triviális egy végül is Linuxban), de az a tény, hogy a Windows általában elrejti ezt a kiterjesztést, azzal a ténnyel együtt, hogy a futtatható fájl indításához és a dokumentum megnyitásához szükséges művelet pontosan ugyanaz.

Mint aki? nix környezetek sokaságában dolgozott, sokféle nyelven kellett írnom kagyló. Higgye vagy sem, a platformok között a héjak nem ugyanazok. Tehát, ha személyes könyvtárát több kagylóban tartja (ha szükséges), akkor nagyon hasznos, ha kiterjesztéseket használ a héjak azonosításához. Így amikor másik platformra lép, és a shell kissé eltér, akkor tudja, hogy milyen szkripteket céloz meg a módosításokhoz. .sh .ksh .bsh .csh …

megjegyzések

• Úgy tűnik, ez egyetért a következővel: unix.stackexchange.com/questions/31760/ …
• Nincs #! a szkript elején (pl. #!/bin/bash)?
• A Gnu / Linux, a BSD és a UNIX mind Unix. Nem kell? Nix. A Linux egy kernel, az android Linuxot használt, de nem Unix (hacsak nem ad hozzá külön szoftvert, ebben az esetben Unix-alkalmazásod van).
• @ ctrl-alt-delor: Unix " egy védjegy . Az emberek gyakran használják a "? Nix " t, hogy elkerüljék a védjegyekkel kapcsolatos problémákat (és a pedánsokat).
• @JS ` A UNIX ' a The Open Group védjegye. A Unix és az unix nem greens.org/about/unix.html

Nem szabad kiterjesztést használni a futtatható fájlokhoz, mivel azok nem cserélhetők fel. Képzelje el, hogy van egy shell szkriptje a.sh, majd írjon újra a pythonba a.py, most minden programot meg kell változtatnia, amely szkriptnek hívja , kiszivárogtattad a megvalósítás részleteit.

A Mircosoft Windows rendszerében a fájlnévkiterjesztés egésze rendetlenség: például a.audio, b.audio, c.audio A a.mp3, b.wav, c.ogg és a d.picture, e.picture, f.picture d.jpeg, e.png, f.gif. Legtöbbször nem mindegy, milyen formátumban a hang vagy a kép be van töltve. Hosszú időt kell töltenünk az új felhasználóknak az összes fájlkiterjesztés megtanításával.

Megjegyzések

• Egy másik ok, amely nem a *.sh használatához éppen az jött össze, hogy a Debian ' s run-parts nyert ' ne futtasson szkripteket kiterjesztésekkel, például a /etc/cron.*/ fájlban: archive.oreilly.com/pub /post/runparts_scripts_a_note_about.html

Amint elmondta, a Unix fájlkiterjesztések pusztán információk. Szüksége van csak a parancsfájlra, hogy legyen helyes shebangja és futtatható legyen.

Vagy nem lehet kiterjesztése, vagy a .sh parancsot használhatja.

I a személyiség a használt héjatól függetlenül a következő konvenciókat használja (csh, tcsh, bash, sh, …):

• nincs kiterjesztés a rendszerhez vagy a kiváló minőségű szkriptekhez (rendkívül ritka).
• a .sh klasszikus szkriptekhez, alacsony vagy magas fokozatú.

Megjegyzések

• Mit értesz " klasszikus szkripteken, alacsony vagy magas fokozatú "?
• szerintem Absztrakciót vagy szervezeti szintet értettem ezzel. Ez azt jelenti, hogy nem ' nem érdekli, milyen nyelvet / szkript eszközt használnak egyes parancsok mögött: tehát nem használ ' semmilyen kiterjesztést. Mások számára jó tudni, hogy ez egy bash vagy valami egzotikus ksh shell script (megfelelő kiterjesztéssel). … de ez 2 évvel ezelőtt volt;)

A Shell szkriptbővítmények nagyon hasznosak. Például gyakran írok olyan szkripteket, amelyeknek több fájlja van több nyelven (pl.bash, awk és lua) ugyanabban a könyvtárban. Ha csak a bash fájlokban kell keresnem egy karakterláncot, akkor a kiterjesztés ezt nagyon hasznosá teszi a hamis pozitív eredmények csökkentése érdekében. Vagy ha meg akarom sorolni az összes bash kódomat az adott projekthez.

Fájdalmas, hogy a program futtatásakor be kell írnom a kiterjesztést, ezért egy symlinket is készítek a kiterjesztés nélkül a fő futtatható fájl, a szerkesztéshez / futtatáshoz anélkül, hogy minden egyes alkalommal be kellene írnia a kiterjesztést. A hivatkozások olcsók és egyszerűek.

Megjegyzések

• Úgy tűnik, ez egyetért a unix.stackexchange-lel. com / questions / 31760 / …

Mint mások mondták, a héj nem törődik a kiterjesztésekkel. Ugyanakkor lehetővé teszi a fájlok gyors emberi azonosítását. Látok .py vagy .sh és gyorsan tudom, hogy mik legyenek (legalábbis). Mint Steve mondja, gyakorlati szempont a fájlkiterjesztés szerinti keresés vagy a sorszámozás is.