J'ai quelques scripts a ecrire en Bourne Shell standard, c'est a dire sans les extentions de bash...
Donc j'ai chercher une doc du sh[1], et j'ai feuilleter, bilan : aucune reference au fonctions. J'en deduit donc que, soit la grosse majorite des script que j'ai vu ne meritent pas le #!/bin/sh qu'ils portent, soit je me suis planter de doc.
Si c'est bien un gauffrage de doc, est-ce que quelqu'un aurais un pointeur sur une doc du standard ?
merci d'avance
[1] http://cm.bell-labs.com/7thEdMan/(...)
Forum Programmation.shell fonction en bourne shell
30
mar.
2005
# meme que bash ou ksh
Posté par totof2000 . Évalué à 2.
ma_fonction() {
echo "Coucou"
}
# man sh
Posté par totof2000 . Évalué à 2.
FUNCTIONS
A shell function, defined as described above under SHELL GRAMMAR,
stores a series of commands for later execution. When the name of a
shell function is used as a simple command name, the list of commands
associated with that function name is executed. Functions are executed
in the context of the current shell; no new process is created to
interpret them (contrast this with the execution of a shell script).
When a function is executed, the arguments to the function become the
positional parameters during its execution. The special parameter # is
updated to reflect the change. Positional parameter 0 is unchanged.
The FUNCNAME variable is set to the name of the function while the
function is executing. All other aspects of the shell execution envi-
ronment are identical between a function and its caller with the excep-
tion that the DEBUG trap (see the description of the trap builtin under
SHELL BUILTIN COMMANDS below) is not inherited unless the function has
been given the trace attribute (see the description of the declare
builtin below).
Variables local to the function may be declared with the local builtin
command. Ordinarily, variables and their values are shared between the
function and its caller.
If the builtin command return is executed in a function, the function
completes and execution resumes with the next command after the func-
tion call. When a function completes, the values of the positional
parameters and the special parameter # are restored to the values they
had prior to the function's execution.
Function names and definitions may be listed with the -f option to the
declare or typeset builtin commands. The -F option to declare or type-
set will list the function names only. Functions may be exported so
that subshells automatically have them defined with the -f option to
the export builtin.
Functions may be recursive. No limit is imposed on the number of
recursive calls.
[^] # Re: man sh
Posté par totof2000 . Évalué à 3.
http://www.rt.com/man/sh.1.html(...)
Functions
The syntax of a function definition is
name ( ) command
A function definition is an executable statement; when executed it in-
stalls a function named name and returns an exit status of zero. The
command is normally a list enclosed between ``{'' and ``}''.
Variables may be declared to be local to a function by using a local com-
mand. This should appear as the first statement of a function, and the
syntax is
local [ variable | - ] ...
Local is implemented as a builtin command.
When a variable is made local, it inherits the initial value and exported
and readonly flags from the variable with the same name in the surround-
ing scope, if there is one. Otherwise, the variable is initially unset.
The shell uses dynamic scoping, so that if you make the variable x local
to function f, which then calls function g, references to the variable x
made inside g will refer to the variable x declared inside f, not to the
global variable named x.
The only special parameter than can be made local is ``-''. Making ``-''
local any shell options that are changed via the set command inside the
function to be restored to their original values when the function re-
turns.
The syntax of the return command is
return [ exitstatus ]
It terminates the currently executing function. Return is implemented as
a builtin command.
# standard ?
Posté par xavier . Évalué à 1.
bourne shell standard, voir entre autres :
http://www.in-ulm.de/~mascheck/bourne/(...)
s'il faut travailler dans le contexte d'un standard/norme
pour /bin/sh c'est plutot du coté POSIX qu'il faut aller voir,
un bash compilé en --enable-minimal-config n'est pas
trop mauvais de ce point de vue :)
[^] # Re: standard ?
Posté par totof2000 . Évalué à 2.
[^] # Re: standard ?
Posté par beagf (site web personnel) . Évalué à 1.
Impossible de trouver la doc, normal si mes souvenirs sont bon elle est payante... Mais vu que debian recomande fortement d'ecrire les scripts des paquets en shell posix, il doit bien exister une doc quelque part.
Je suis donc partit a la recherche de cette doc, bilan : rien trouver sur le site de debian (il demande la compatibilite d'un truc que l, on ne connait pas ?) donc une petite recherche sur le net, et la pas plus de succes, on trouve des shell compatible mais avec des extentions et sans une doc claire et precise de ces modifications. On trouve aussi des infos comme quoi ce serais le korn shell qui serait posix...
Donc deux questions comment font les dev qui doivent faire des script standard (ici l'objectif est que les scripts doivent tourner sur le plus de platforme possible ie. tout ce qui est a peu pres posix). Et deuxieme question est-ce qu'il existe un truc du style lint mais pour les scripts shell?
[^] # Re: standard ? - en cherchant un peu:
Posté par totof2000 . Évalué à 2.
Tu y trouve ce qui est commun au Korn Shell et aux shelmls posix, plus les extensions propres a ksh. En theorie, si tu developpes en suivant ce qui est inddiqué pour les shells posix, ca devrait fonctionner pour tout shell se prétendant posix (je dis bien devrait car ilm me semble que parfois il y a des petites incompatibilités, faire une recherche sur fr.comp.os.unix, le sujet y est abordé de temps en temps).
Par exemple les 'builtin command':
http://www.rz.uni-hohenheim.de/betriebssysteme/unix/aix/aix_4.3.3_d(...)
Korn Shell or POSIX Shell Built-In Commands
Special commands are built in to the Korn shell and POSIX shell and executed in the shell process. Unless otherwise indicated, the output is written to file descriptor 1 and the exit status is 0 (zero) if the command does not contain any syntax errors. Input and output redirection is permitted. There are two types of built-in commands, special built-in commands and regular built-in commands.
Refer to the List of Korn Shell or POSIX Shell Built-in Commands for an alphabetical listing of these commands.
Special built-in commands differ from regular built-in commands in the following ways:
A syntax error in a special built-in command may cause the shell executing the command to end. This does not happen if you have a syntax error in a regular built-in command. If a syntax error in a special built-in command does not end the shell program, the exit value is non-zero.
Variable assignments specified with special built-in commands remain in effect after the command completes. This is not the situation with regular built-in commands.
I/O redirections are processed after parameter assignments.
In addition, words that are in the form of a parameter assignment following the export, readonly, and typeset special commands are expanded with the same rules as a parameter assignment. This means that tilde substitution is performed after the = (equal sign), and word splitting and file name substitution are not performed.
Special Built-in Command Descriptions
The Korn Shell provides the following special built-in commands:
: eval newgrp shift
. exec readonly times
break exit return trap
continue export set typeset
unset
Chaque commande posix y est détaillée, je te laisse y jeter un oeil ....
Attention, ce n'est pas parce que tu écriras tes scripts en suivant la norme posix que ca fonctionnera partout. Il ne faut pas oublier que le shell est un outil qui appelle d'autres commandes, et selon les systèmes il existe des variantes pour ces commandes (par ex, les outils GNU implémentent des extensions que les autres outils UNIX n'implémentent pas).
[^] # Re: standard ?
Posté par totof2000 . Évalué à 2.
Tout dépend de ce que tu entends par plate forme. shell? OS+shell? OS?
Dans le cas ou la plate forme est OS+shell:
solution 1: Ils choisissent un dénominateur commun (par exemple ksh ou sh que l'on retrouve sur la plupart des unix) et ils lisent les pages de man correspondant a chaque implémentation pour repérer les divergences, et adapter leur script en conséquence.
solution 2: ils installe la même implémentation d'un shell partout (par ex. bash ou pdksh) et développent avec.
Comme dit dans mon post précédent, le problème ne vient pas uniquement du shell mais aussi des commandes utilisées (par exemple awk, nawk, gawk, sont des implémentations différentes de awk, sur hp on utilise bdf pour obtenir le même résultat qu'un df -k sous solaris ou linux, un ps system5 n'aura pas les memes options qu'un ps bsd, ...).
Personnellement je fais ainsi:
- pour tout ce qui concerne les traitements propres au système (scripts d'arret/relance de services, bascule, etc ...) je développe en utilisant le shell par défaut de root.
- pour le reste (traitement exécutés lorsque la machine est bien démarrée, par exemple rapports, analyse de logs, automatisation divzerses et variées ...), si disponible j'utilise (par ordre de priorité):
- perl (intégré d'office dans la plupart des Unix) ou python (si je peux l'installer)
- bash
- ksh
- sh
[^] # Re: standard ?
Posté par xavier . Évalué à 1.
http://www.unix.org/version3/ieee_std.html(...)
ce n'est certe pas libre et implique un enregistrement, mais cela
reste gratuit, de plus a l'exception de shells relativement recents
et activement maintenus la compatibilité POSIX fait generalement
reference aux anciennes versions de la norme, mais ce n'en est
pas moins une bonne base. un pti coup de wget sur le lien
fournit apres enregistrement et hop...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.