sh

Från Wiki.linux.se
Hoppa till navigering Hoppa till sök

SH(1P)

POSIX Programmer's Manual

PROLOG

Denna manual är en del av POSIX Programmer's Manual. Implementeringen av detta gränssnitt i Linux kan skilja sig (konsultera motsvarande Linux-manual för detaljer om Linux-beteende), eller gränssnittet kanske inte är implementerat på Linux.

NAMN

sh — skal, standard kommandospråksinterpretator

SAMMANFATTNING

sh [-abCefhimnuvx] [-o option]... [+abCefhimnuvx] [+o option]...
    [kommando_fil [argument...]]

sh -c [-abCefhimnuvx] [-o option]... [+abCefhimnuvx] [+o option]...
    kommando_sträng [kommando_namn [argument...]]

sh -s [-abCefhimnuvx] [-o option]... [+abCefhimnuvx] [+o option]...
    [argument...]

BESKRIVNING

sh-verktyget är en kommandospråksinterpretator som utför kommandon lästa från en kommando-sträng, standardingång, eller en specificerad fil. Applikationen ska säkerställa att kommandona som ska utföras uttrycks i det språk som beskrivs i Kapitel 2, Shell Command Language.

Vägutvidgning får inte misslyckas på grund av filens storlek.

In- och utmatningsomdirigeringar i skalet har en implementation-definierad offset maxgräns som är fastställd i den öppna filbeskrivningen.

ALTERNATIV

sh-verktyget ska följa Basdefinitionerna i POSIX.1-2017, Sektion 12.2, Utility Syntax Guidelines, med en förlängning för stöd av ett ledande <plustecken> ('+') som noteras nedan.

Alternativen -a, -b, -C, -e, -f, -m, -n, -o option, -u, -v och -x beskrivs som en del av det inbyggda verktyget set i Sektion 2.14, Special Built-In Utilities. Alternativbokstäverna hämtade från det speciella inbyggda verktyget set ska också accepteras med ett ledande <plustecken> ('+') istället för ett ledande <bindestreck> (vilket innebär omvändning av alternativet som beskrivs i denna volym av POSIX.1-2017).

Följande ytterligare alternativ ska stödjas:

  • -c — Läs kommandon från kommando_sträng. Ställ in värdet för specialparametern 0 (se Sektion 2.5.2, Special Parameters) från värdet av kommando_namn och de positionsparametrar ($1, $2, och så vidare) i sekvens från de återstående argumentoperanderna. Inga kommandon ska läsas från standardingången.
  • -i — Ange att skalet är interaktivt; se nedan. En implementation kan behandla specifikationen av -i-alternativet som ett fel om den verkliga användar-ID:n för den anropande processen inte är lika med den effektiva användar-ID:n eller om den verkliga grupp-ID:n inte är lika med den effektiva grupp-ID:n.
  • -s — Läs kommandon från standardingången.

Om det inte finns några operander och alternativet -c inte är specificerat, ska alternativet -s antas.

Om alternativet -i är närvarande, eller om det inte finns några operander och skalets standardingång och standardfel är anslutna till en terminal, ska skalet betraktas som interaktivt.

OPERANDER

Följande operander ska stödjas:

  • - — Ett enda <bindestreck> ska behandlas som den första operanden och sedan ignoreras. Om både '-' och "--" ges som argument, eller om andra operander föregår det enda <bindestrecket>, är resultaten odefinierade.
  • argument — Positionsparametrarna ($1, $2, och så vidare) ska ställas in på argumenten, om några.
  • kommando_fil — Vägnamnet till en fil som innehåller kommandon. Om vägnamnet innehåller en eller flera <snedstreck> ska implementationen försöka läsa den filen; filen behöver inte vara körbar. Om vägnamnet inte innehåller ett <snedstreck>:
* Implementationen ska försöka läsa den filen från den aktuella arbetskatalogen; filen behöver inte vara körbar.

* Om filen inte finns i den aktuella arbetskatalogen, kan implementationen utföra en sökning efter en körbar fil med värdet av PATH, som beskrivs i Sektion 2.9.1.1, Command Search and Execution.

Specialparametern 0 (se Sektion 2.5.2, Special Parameters) ska ställas in på värdet av kommando_fil. Om sh anropas med en sammanfattningsform som utelämnar kommando_fil, ska specialparametern 0 ställas in på värdet av det första argumentet som skickas till sh från dess förälder (till exempel, argv[0] för ett C-program), vilket normalt är ett vägnamn som används för att köra sh-verktyget.

  • kommando_namn — En sträng som tilldelas specialparametern 0 när kommandona i kommando_sträng utförs. Om kommando_namn inte är specificerat, ska specialparametern 0 ställas in på värdet av det första argumentet som skickas till sh från dess förälder (till exempel, argv[0] för ett C-program), vilket normalt är ett vägnamn som används för att köra sh-verktyget.
  • kommando_sträng — En sträng som ska tolkas av skalet som ett eller flera kommandon, som om strängen var argumentet till funktionen system() definierad i System Interfaces-volymen av POSIX.1-2017. Om operanden kommando_sträng är en tom sträng, ska sh avsluta med en noll exit-status.

STANDARDINLÄSNING

Standardinläsningen ska endast användas om ett av följande är sant: 

* Alternativet -s är specificerat.

* Alternativet -c är inte specificerat och inga operander är specificerade.

* Skriptet utför ett eller flera kommandon som kräver indata från standardinläsningen (såsom ett read-kommando som inte omdirigerar sina indata).

Se sektionen INPUT FILES.

När skalet använder standardinläsning och det anropar ett kommando som också använder standardinläsning, ska skalet säkerställa att standardinläsningsfilens pekare pekar direkt efter det kommando det har läst när kommandot börjar exekveras. Det ska inte läsa i förväg på ett sådant sätt att några tecken som är avsedda att läsas av det anropade kommandot konsumeras av skalet (oavsett om de tolkas av skalet eller inte) eller att tecken som inte läses av det anropade kommandot inte ses av skalet. När kommandot som förväntas läsa standardinläsning startas asynkront av ett interaktivt skal, är det ospecificerat om tecken läses av kommandot eller tolkas av skalet.

Om standardinläsningen till sh är en FIFO eller terminalenhet och är inställd på icke-blockerande läsningar, ska då sh aktivera blockerande läsningar på standardinläsningen. Detta ska förbli i effekt när kommandot avslutas.

INMATNINGSFILER

Inmatningsfilen ska vara en textfil, förutom att radlängder ska vara obegränsade. Om inmatningsfilen består enbart av noll eller fler tomma rader och kommentarer, ska sh avsluta med en noll exit-status.

MILJÖVARIABLER

Följande miljövariabler ska påverka exekveringen av sh:

  • ENV — Denna variabel, endast när ett interaktivt skal anropas, ska vara föremål för parameterexpansion (se Sektion 2.6.2, Parameter Expansion) av skalet, och det resulterande värdet ska användas som ett vägnamn till en fil som innehåller skal-kommandon att exekvera i den aktuella miljön. Filen behöver inte vara körbar. Om det expanderade värdet av ENV inte är ett absolut vägnamn, är resultaten ospecificerade. ENV ska ignoreras om de verkliga och effektiva användar-ID:n eller verkliga och effektiva grupp-ID:n för processen är olika.
  • FCEDIT — Denna variabel, när den expanderas av skalet, ska bestämma standardvärdet för -e redigerarens alternativargument. Om FCEDIT är null eller ej satt, ska ed användas som redigerare.
  • HISTFILE — Bestämma ett vägnamn som anger en kommandologgfil. Om variabeln HISTFILE inte är satt, kan skalet försöka att få åtkomst till eller skapa en fil .sh_history i den katalog som refereras av miljövariabeln HOME. Om skalet inte kan få både läs- och skrivåtkomst till, eller skapa, loggfilen, ska det använda en ospecificerad mekanism som tillåter loggen att fungera korrekt. (Referenser till logg "fil" i denna sektion ska förstås som denna ospecificerade mekanism i sådana fall.) En implementation kan välja att få åtkomst till denna variabel endast vid initialisering av loggfilen; denna initialisering ska ske när fc eller sh först försöker hämta poster från, eller lägga till poster till, filen, som ett resultat av kommandon som utfärdats av användaren, filen som namnges av variabeln ENV, eller implementationens definierade system-startfiler. Implementationer kan välja att inaktivera logglistmekanismen för användare med lämpliga rättigheter som inte sätter HISTFILE; de specifika omständigheterna under vilka detta sker är implementation-definierade. Om mer än en instans av skalet använder samma loggfil, är det ospecificerat hur uppdateringar till loggfilen från dessa skal interagerar. När poster tas bort från loggfilen, ska de tas bort från den äldsta först. Det är ospecificerat när poster i loggfilen fysiskt tas bort från loggfilen.
  • HISTSIZE — Bestämma ett decimaltal som representerar gränsen för antalet tidigare kommandon som är tillgängliga. Om denna variabel är unset, ska en ospecificerad standard större än eller lika med 128 användas. Det maximala antalet kommandon i logglistan är ospecificerat, men ska vara minst 128. En implementation kan välja att få åtkomst till denna variabel endast vid initialisering av loggfilen, som beskrivs under HISTFILE. Därför är det ospecificerat om ändringar gjorda till HISTSIZE efter att loggfilen har initialiserats är effektiva.
  • HOME — Bestämma vägnamnet till användarens hemkatalog. Innehållet i HOME används i tilde-expansionen som beskrivs i Sektion 2.6.1, Tilde Expansion.
  • LANG — Ge ett standardvärde för de internationaliseringsvariabler som är unset eller null. (Se Basdefinitionerna i POSIX.1-2017, Sektion 8.2, Internationalization Variables för företrädet för internationaliseringsvariabler som används för att bestämma värdena för lokalekategorier.)
  • LC_ALL — Om satt till en icke-tom sträng, åsidosätt värdena för alla andra internationaliseringsvariabler.
  • LC_COLLATE — Bestämma beteendet för intervalluttryck, ekvivalensklasser, och multi-tecken kollationselement inom mönstermatchning.
  • LC_CTYPE — Bestämma lokal för tolkningen av byte-sekvenser av textdata som tecken (till exempel, en-byte i motsats till multi-byte tecken i argument och inmatningsfiler), vilka tecken som definieras som bokstäver (teckenklass alpha), och beteendet för teckenklasser inom mönstermatchning.
  • LC_MESSAGES — Bestämma lokalen som ska användas för att påverka formatet och innehållet i diagnostiska meddelanden skrivna till standardfel.
  • MAIL — Bestämma ett vägnamn till användarens postlådefil för ändamål av inkommande postmeddelanden. Om denna variabel är satt, ska skalet informera användaren om filen som nämns av variabeln skapas eller om dess modifieringstid har ändrats. Att informera användaren ska utföras genom att skriva en sträng med ospecificerat format till standardfel innan nästa primärprompt-sträng skrivs. Sådan kontroll ska utföras endast efter att intervallet definierat av variabeln MAILCHECK har passerat sedan senaste sådan kontroll. Användaren ska endast informeras om MAIL är satt och MAILPATH inte är satt.
  • MAILCHECK — Etablera ett decimaltal som anger hur ofta (i sekunder) skalet ska kontrollera för ankomst av post i filerna som anges av MAILPATH eller MAIL. Standardvärdet ska vara 600 sekunder. Om satt till noll, ska skalet kontrollera innan varje primärprompt utfärdas.
  • MAILPATH — Ge en lista över vägnamn och valfria meddelanden separerade med <kolon>-tecken. Om denna variabel är satt, ska skalet informera användaren om någon av filerna som nämns av variabeln skapas eller om någon av deras modifieringstider ändras. (Se föregående post för MAIL för beskrivningar av postankomst och användarinformation.) Varje vägnamn kan följas av '%' och en sträng som ska vara föremål för parameterexpansion och skrivas till standardfel när modifieringstiden ändras. Om ett '%' tecken i vägnamnet föregås av ett <backslash>, ska det behandlas som ett bokstavligt '%' i vägnamnet. Standardmeddelandet är ospecificerat.

MAILPATH-miljövariabeln har företräde över MAIL-variabeln.

  • NLSPATH — Bestämma placeringen av meddelandekataloger för bearbetning av LC_MESSAGES.
  • PATH — Etablera en sträng formaterad som beskrivs i Basdefinitionerna av POSIX.1-2017, Kapitel 8, Environment Variables, som används för att påverka kommandointerpretation; se Sektion 2.9.1.1, Command Search and Execution.
  • PWD — Denna variabel ska representera ett absolut vägnamn till den aktuella arbetskatalogen. Tilldelningar till denna variabel kan ignoreras.

ASYNKRONA HÄNDELSER

sh-verktyget ska vidta standardåtgärden för alla signaler (se Sektion 1.4, Utility Description Defaults) med följande undantag.

Om skalet är interaktivt, ska SIGINT signaler som tas emot under kommandoradsredigering hanteras som beskrivs i EXTENDED DESCRIPTION, och SIGINT signaler som tas emot vid andra tillfällen ska fångas men ingen åtgärd utföras.

Om skalet är interaktivt:

  • SIGQUIT och SIGTERM signaler ska ignoreras.
  • Om -m-alternativet är i kraft, ska SIGTTIN, SIGTTOU och SIGTSTP signaler ignoreras.
  • Om -m-alternativet inte är i kraft, är det ospecificerat om SIGTTIN, SIGTTOU och SIGTSTP signaler ignoreras, ställs in till standardåtgärden, eller fångas. Om de fångas, ska skalet, i signalfångstfunktionen, ställa in signalen till standardåtgärden och utlösa signalen (efter att ha vidtagit lämpliga åtgärder, som att återställa terminalinställningar).

Standardåtgärderna och åtgärderna som beskrivs ovan för interaktiva skal kan åsidosättas genom användning av det speciella inbyggda verktyget trap (se trap(1p) och Sektion 2.11, Signals and Error Handling).

STANDARDUTDATA

Se sektionen STDERR.

STANDARDFEL

Om inget annat anges (av beskrivningarna av några anropade verktyg eller i interaktivt läge) ska standardfel endast användas för diagnostiska meddelanden.

UTDATAFILER

Inga.

UTÖKAD BESKRIVNING

Se Kapitel 2, Shell Command Language. Funktionaliteten som beskrivs i resten av sektionen UTÖKAD BESKRIVNING ska tillhandahållas på implementationer som stöder användarportabilitetsverktyg (och resten av denna sektion är inte ytterligare skuggad för detta alternativ).

Kommandohistoriklista

När sh-verktyget används interaktivt, ska det upprätthålla en lista över kommandon som tidigare angavs från terminalen i filen som namnges av HISTFILE miljövariabeln. Typen, storleken och det interna formatet för denna fil är ospecificerade. Flera sh-processer kan dela åtkomst till filen för en användare, om filåtkomstbehörigheter tillåter detta; se beskrivningen av HISTFILE miljövariabeln.

Kommandoradsredigering

När sh används interaktivt från en terminal, kan den aktuella kommandot och kommandohistoriken (se fc(1p)) redigeras med hjälp av vi-läge för kommandoradsredigering. Detta läge använder kommandon, som beskrivs nedan, liknande en delmängd av de som beskrivs i vi-verktyget. Implementationer kan erbjuda andra kommandoradsredigeringslägen som motsvarar andra redigeringsverktyg.

Kommandot set -o vi ska aktivera vi-lägesredigering och placera sh i vi-insättningsläge (se Kommandoradsredigering (vi-läge)). Detta kommando ska också inaktivera alla andra redigeringslägen som implementationen kan tillhandahålla. Kommandot set +o vi inaktiverar vi-lägesredigering.

Vissa block-läge terminaler kan vara oförmögna att stödja skalets kommandoradsredigering. Om en terminal inte kan tillhandahålla något redigeringsläge, kanske det inte är möjligt att ställa in -o vi när man använder skalet på denna terminal.

Kommandoradsredigering (vi-läge)

I vi-redigeringsläge ska sh kunna växla mellan insättningsläge och kommandoläge.

När du är i insättningsläge, ska ett inmatat tecken infogas i kommandoraden, förutom som noteras i vi Line Editing Insert Mode. Vid inmatning till sh och efter avslutandet av föregående kommando, ska sh vara i insättningsläge.

Att skriva ett escape-tecken ska växla sh till kommandoläge (se vi Line Editing Command Mode). I kommandoläge ska ett inmatat tecken antingen anropa en definierad operation, användas som en del av en flerkaraktärsoperation, eller behandlas som ett fel. Ett tecken som inte känns igen som en del av ett redigeringskommando ska avsluta ett specifikt redigeringskommando och ska varna terminalen. Om sh tar emot en SIGINT-signal i kommandoläge (oavsett om den genereras genom att skriva interrupt-tecknet eller på annat sätt), ska den avsluta kommandoradsredigering på den aktuella kommandoraden, återutge prompten på nästa rad av terminalen, och återställa kommandohistoriken (se fc(1p)) så att det senaste körda kommandot är det föregående kommandot (det vill säga, kommandot som redigerades när det avbröts skrivs inte om i historiken).

I följande avsnitt, ska frasen "flytta markören till början av ordet" innebära "flytta markören till första tecknet i det aktuella ordet" och frasen "flytta markören till slutet av ordet" innebär "flytta markören till sista tecknet i det aktuella ordet". Frasen "början av kommandoraden" anger punkten mellan slutet av promptsträngen som utfärdats av skalet (eller början av terminalraden, om ingen promptsträng finns) och första tecknet i kommandotexten.

vi Line Editing Insert Mode

När du är i insättningsläge, ska alla tecken som skrivs in infogas i den aktuella kommandoraden, om de inte är från följande uppsättning.

  • <newline> — Utför den aktuella kommandoraden. Om den aktuella kommandoraden inte är tom, ska denna rad skrivas in i kommandohistoriken (se fc(1p)).
  • erase — Radera tecknet före den aktuella markörpositionen och flytta den aktuella markörpositionen tillbaka ett tecken. I insättningsläge ska tecken raderas från både skärmen och bufferten vid backspace.
  • interrupt — Om sh tar emot en SIGINT-signal i insättningsläge (oavsett om den genereras genom att skriva interrupt-tecknet eller på annat sätt), ska den avsluta kommandoradsredigering med samma effekter som beskrivs för avbrytande av kommandoläge; se vi Line Editing Command Mode.
  • kill — Rensa alla tecken från inmatningsraden.
  • <control>‐V — Infoga nästa inmatade tecken, även om tecknet annars är ett speciellt insättningsläge-tecken.
  • <control>‐W — Radera tecknen från ett före markören till det föregående ordgränsen. Ordgränsen i detta fall är den som ligger närmast markören av antingen början av raden eller ett tecken som inte är varken blankt eller punktsymbol i den aktuella lokalen.
  • end-of-file — Tolkad som slutet på inmatningen i sh. Denna tolkning ska endast ske i början av en inmatningsrad. Om slutet på filen anges någon annanstans än i början av raden, är resultaten ospecificerade.
  • <ESC> — Placera sh i kommandoläge.

EXIT STATUS

Följande exit-värden ska returneras: 

* 0 — Skriptet som ska köras bestod enbart av noll eller fler tomma rader eller kommentarer, eller båda.

* 1-125 — Ett icke-interaktivt skal upptäckte ett fel annat än att kommando_fil inte hittades eller kunde köras, inklusive men inte begränsat till syntax, omdirigering eller fel i variabeltilldelning.

* 126 — En angiven kommando_fil kunde inte köras på grund av ett [ENOEXEC] fel (se Sektion 2.9.1.1, Command Search and Execution, punkt 2).

* 127 — En angiven kommando_fil kunde inte hittas av ett icke-interaktivt skal.

I annat fall ska skalet returnera exit-status för det senaste kommandot det anropade eller försökte anropa (se även exit-verktyget i Sektion 2.14, Special Built-In Utilities).

KONSEKVENSER AV FEL

Se Sektion 2.8.1, Konsekvenser av skal-fel.

ANVÄNDNING

Standardinläsning och standardfel är filerna som avgör om ett skal är interaktivt när -i inte är specificerat. Till exempel: 

sh > file
och:

sh 2> file

skapar interaktiva och icke-interaktiva skal, respektive. Även om båda accepterar terminalinmatning, är resultaten av felvillkor olika, som beskrivs i Sektion 2.8.1, Konsekvenser av skal-fel; i det andra exemplet avbryter ett omdirigeringsfel som upptäcks av ett speciellt inbyggt verktyg skalet.

En överensstämmande applikation måste skydda sin första operand, om den börjar med ett <plustecken>, genom att föregå den med "--"-argumentet som betecknar slutet på alternativen.

Applikationer bör notera att den standardväg till skalet inte kan antas vara vare sig /bin/sh eller /usr/bin/sh, och bör bestämmas genom interrogation av PATH som returneras av getconf PATH, för att säkerställa att den returnerade vägen är ett absolut vägnamn och inte ett inbyggt skal.

Till exempel, för att bestämma platsen för det standard skal-verktyget: 

command -v sh

På vissa implementationer kan detta returnera: 

/usr/xpg4/bin/sh

Dessutom, på system som stöder körbara skript (konstruktionen "#!"), rekommenderas det att applikationer som använder körbara skript installerar dem med hjälp av getconf PATH för att bestämma skalvägnamnet och uppdatera "#!"-skriptet på lämpligt sätt när det installeras (till exempel med sed). Till exempel: 

#
# Installationsskript för att installera korrekt POSIX skalvägnamn
#
# Hämta lista över vägar att kontrollera
#
Sifs=$IFS
Sifs_set=${IFS+y}
IFS=:
set -- $(getconf PATH)
if [ "$Sifs_set" = y ]
then
   IFS=$Sifs
else
   unset IFS
fi
#
# Kontrollera varje väg för 'sh'
#
for i
do
   if [ -x "${i}"/sh ]
   then
       Pshell=${i}/sh
   fi
done
#
# Detta är listan över skript som ska uppdateras. De ska vara i form av '${name}.source' och kommer att omvandlas till '${name}'.
# Varje skript ska börja:
#
# #!INSTALLSHELLPATH
#
scripts="a b c"
#
# Omvandla varje skript
#
for i in ${scripts}
do
   sed -e "s|INSTALLSHELLPATH|${Pshell}|" < ${i}.source > ${i}
done

EXEMPEL

1. Kör ett skal-kommando från en sträng: 

sh -c "cat myfile"

2. Kör ett skal-skript från en fil i den aktuella katalogen: 

sh my_shell_cmds

MOTIVERING

sh-verktyget och det speciella inbyggda verktyget set delar en gemensam uppsättning alternativ.

Namnet IFS var ursprungligen en förkortning av "Input Field Separators"; dock är detta namn vilseledande eftersom IFS-tecknen faktiskt används som fältterminatorer. En rättfärdigande anledning för att ignorera innehållet i IFS vid inmatning till skriptet, bortom säkerhetshänsyn, är att hjälpa möjliga framtida skal-kompilatorer. Att tillåta att IFS importeras från miljön hindrar många optimeringar som annars kan utföras genom dataflödesanalys av skriptet självt.

Texten i avsnittet STDIN om icke-blockerande läsningar gäller ett fall där sh har anropats, troligtvis av ett C-språkprogram, med en standardinläsning som har öppnats med flaggan O_NONBLOCK; se open() i System Interfaces-volymen av POSIX.1-2017. Om skalet inte återställer denna flagga, skulle det omedelbart avslutas eftersom ingen indata skulle vara tillgänglig ännu och det skulle betraktas som slut på fil.

Alternativen associerade med ett begränsat skal (kommandonamn rsh och -r-alternativet) uteslöts eftersom standardutvecklarna ansåg att den underförstådda säkerhetsnivån inte kunde uppnås och de ville inte ge falska förväntningar.

På system som stöder set-user-ID-skript har en historisk fälla varit att länka ett skript till namnet -i. När det anropas av en sekvens som: 

sh -

eller genom: 

#!/usr/bin/sh -

har de historiska systemen antagit att inga alternativsbokstäver följer. Därför tillåter denna volym av POSIX.1-2017 det enda <bindestreck> att markera slutet på alternativen, förutom användningen av det reguljära "--"-argumentet, eftersom det ansågs att den äldre praxisen var så utbredd. Ett alternativt tillvägagångssätt antas av KornShell, där verkliga och effektiva användar-/grupp-ID:n måste matcha för ett interaktivt skal; detta beteende är specifikt tillåtet av denna volym av POSIX.1-2017.

Obs: Det finns andra problem med set-user-ID-skript som de två tillvägagångssätten som beskrivs här inte löser.

Initialiseringsprocessen för loggfilen kan vara beroende av system-startfilerna, eftersom de kan innehålla kommandon som effektivt förbigår användarens inställningar för HISTFILE och HISTSIZE. Till exempel spelas funktionsdefinitioner in i loggfilen, om inte set -o nolog-alternativet är satt. Om systemadministratören inkluderar funktionsdefinitioner i en system-startfil som kallas före ENV-filen, initialiseras loggfilen innan användaren får möjlighet att påverka dess egenskaper. I vissa historiska skal initialiseras loggfilen strax efter att ENV-filen har bearbetats. Därför är det implementation-definierat om ändringar gjorda till HISTFILE efter att loggfilen har initialiserats är effektiva.

Standardmeddelandena för de olika MAIL-relaterade meddelandena är ospecificerade eftersom de varierar mellan implementationer. Typiska meddelanden är: 

you have mail\n

eller: 

you have new mail\n

Det är viktigt att beskrivningarna av kommandoradsredigering hänvisar till samma skal som i POSIX.1-2008 så att interaktiva användare också kan vara applikationsprogrammerare utan att behöva hantera programmatiska skillnader i sina två miljöer. Det är också viktigt att verktygsnamnet sh anges eftersom detta explicita verktygsnamn är alltför djupt rotat i den historiska praxisen för applikationsprogram för att det ska kunna ändras.

Övervägande gavs till att kräva ett diagnostiskt meddelande när man försöker ställa in vi-läge på terminaler som inte stöder kommandoradsredigering. Men det är inte historisk praxis för skalet att vara medveten om alla terminaltyper och därmed kunna upptäcka olämpliga terminaler i alla fall. Implementationer uppmuntras att tillhandahålla diagnostik i detta fall när det är möjligt, snarare än att lämna användaren i ett tillstånd där redigeringskommandon fungerar felaktigt.

I tidiga förslag ingick det KornShell-härledda emacs-läget för kommandoradsredigering, även om själva emacs-redigeraren inte var inkluderad. Samhället av emacs-förespråkare var bestämt emot att den fullständiga emacs-redigeraren skulle standardiseras eftersom de var oroade över att ett försök att standardisera denna mycket kraftfulla miljö skulle uppmuntra leverantörer att leverera strikt överensstämmande versioner som saknar den flexibilitet som krävs av samhället. Författaren av det ursprungliga emacs-programmet uttryckte också sin önskan att utelämna programmet. Dessutom fanns det ett antal historiska system som inte inkluderade emacs, eller inkluderade det utan att stödja det, men det fanns mycket få som inte inkluderade och stödde vi. Skalets emacs-kommandoradsredigeringsläge utelämnades slutligen eftersom det blev uppenbart att KornShell-versionen och redigeraren som distribuerades med GNU-systemet hade avvikit i vissa avseenden. Författaren till emacs begärde att POSIX emacs-läget antingen skulle raderas eller ha ett betydande antal ospecificerade villkor. Trots att KornShell-författaren gick med på att överväga förändringar för att bringa skalet i linje, beslutade standardutvecklarna att skjuta upp specifikationen vid den tiden. Vid den tidpunkten antogs det att en överenskommelse om en acceptabel definition skulle ske för ett senare utkast, men det har inte hänt, och det verkar inte finnas något drivkraft att göra det. I vilket fall som helst är implementationer fria att erbjuda ytterligare kommandoradsredigeringslägen baserade på de exakta modeller av redigerare som deras användare är mest bekväma med.

Tidiga förslag hade följande listpost i vi Line Editing Insert Mode:

  • \ — Om det följs av erase eller kill-tecknet, ska det tecknet infogas i inmatningsraden. Annars ska <backslash> självt infogas i inmatningsraden.

Men detta är inte egentligen en funktion i sh kommandoradsredigeringsinsättningsläge, utan en av några historiska terminalraddrivrutiner. Vissa överensstämmande implementationer fortsätter att göra detta när stty iexten flaggan är satt.

I interaktiva skal ignoreras SIGTERM så att kill 0 inte dödar skalet, och SIGINT fångas så att wait är avbrytbart. Om skalet inte ignorerar SIGTTIN, SIGTTOU och SIGTSTP signaler när det är interaktivt och -m-alternativet inte är i kraft, ska dessa signaler avbryta skalet om det inte är en session-ledare. Om det är en session-ledare, ska signalerna kasseras om de skulle stoppa processen, som krävs av System Interfaces-volymen i POSIX.1-2017, Sektion 2.4.3, Signal Actions for orphaned process groups.

FRAMTIDA RIKTNINGAR

Inga.

SE ÄVEN

Sektion 2.9.1.1, Command Search and Execution, Kapitel 2, Shell Command Language, cd(1p), echo(1p), exit(1p), fc(1p), pwd(1p), invalid, set(1p), stty(1p), test(1p), trap(1p), umask(1p), vi(1p)

Basdefinitionerna i POSIX.1-2017, Kapitel 8, Environment Variables, Sektion 12.2, Utility Syntax Guidelines

System Interfaces-volymen i POSIX.1-2017, dup(3p), exec(1p), exit(3p), fork(3p), open(3p), pipe(3p), signal(3p), system(3p), ulimit(3p), umask(3p), wait(3p)

COPYRIGHT

Delar av denna text är återtryckta och reproducerade i elektronisk form från IEEE Std 1003.1-2017, Standard for Information Technology — Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 av Institute of Electrical and Electronics Engineers, Inc och The Open Group. Vid eventuella avvikelser mellan denna version och den ursprungliga IEEE och The Open Group Standard, är den ursprungliga IEEE och The Open Group Standard referensdokumentet. Den ursprungliga standarden kan erhållas online på http://www.opengroup.org/unix/online.html.

Eventuella typografiska eller formateringsfel som visas på denna sida är sannolikt introducerade under konverteringen av källfilerna till man-sidformat. För att rapportera sådana fel, se https://www.kernel.org/doc/man-pages/reporting_bugs.html.

IEEE/The Open Group 2017 SH(1P)

Sidslut

Det här är en maskinöversättning av linux kommando manualen till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till Datorhjälp som har sponsrat Linux.se med webserver.

Hämtad från "https://wiki.linux.se/index.php?title=sh&oldid=3513"