Reprise du message précédent :
*PAN*

 
Il y a une boite (dont j'ai oublie le nom et je ne connais personne qui a utilise ses services) qui s'est specialisee dans la fourniture d'adresses aux US et la reexpedition des colis qui y sont envoyes.

vous avez mieux ?

Ne me dis pas que tu veux acheter un de ces peignes à la con, qu'on trouve dans n'importe quel magasin de farce et attrape

I get up at seven, yeah,  
And I go to work at nine.  
I got no time for livin'.  
Yes, I'm workin' all the time.  
 
It seems to me  
I could live my life  
A lot better than I think I am.  
I guess that's why they call me,  
They call me the workin' man.  
 
   
 
allez, enchainement sur UFO  

Utiliser n'importe quel autre langage de script que le shell, mais sinon, sans getopt, non.

edit, en fait si: plutôt que de prendre $1, ce qui oblige l'utilisateur à positionner -d en première position, et ne sera pas commode si tu as plus d'une option, tu devrais plutôt utiliser $@ qui prend tous les arguments, et itérer sur chacun d'entre eux, en t'inspirant de l'exemple page 63 du cours de Sve@r.

$? Pour la valeur de sortie

 
Ne pas chercher "Thermal Neckwrap" sur google image

PAS DE BRAS PAS DE CHOCOLAT

Putain j'ai l'impression d'être le twitter d'ackboo.

Youpi, réintroduisons de la prog en bash \o/

Je ne vois rien de spécial ?

 
Pour la valeur de retour il faut regarder $? juste après la commande. Sinon ya pas de boolean en shell, tout est string (même si declare peut te filer un très faible typage)
 
 

 
Tu peux utiliser les opérateurs logiques && et || si tu veux un truc plus compact (mais pas forcément plus lisible).
Sinon je sais qu'en bash tu as le droit à :

 
Oué quand j'ai pas getopt je fais ça en général, boucle sur $@, remplissage d'une table.

 
getopts est un builtin de bash.  Tu es sur qu'il s'agit de bash et non pas d'un autre shell (dash p.e. qui se veut simplement un shell posix sans extension).

la question qui tue
je sais pas trop, c'est sur le CD d'install, du coup c'est possible que ce soit pas le shell habituel.
ou alors c'est getopt sans "s" que j'ai essayé

getopts est un builtin de sh, depuis Unix SVR3 (1986). Et il fait partie de SUSv4 (Commands and Utilities Issue 7) / POSIX:2008

Bah merde alors.

j'ai rien vu de choquant, à part des tas de gens qui portent des neck wraps...
 

speaking of which, j'ai vu Intouchables hier...et c'est pas mal du tout
Ce truc va nous refaire Bienvenu chez les ch'tits...
 

^2

 
Ca me fait verifier un peu plus. Il est dans Unix98 (alias SUSv2), j'ai pas la un de disponible.  Et il est dans le /bin/sh de Solaris, qui est le pire shell que j'ai a utiliser.
 
En passant, fournir getopts sans en faire un buitin ne me semble pas possible.
 

 
Wild guess: which dans un bourne shell lance la commande csh dans un process separe, Il faut  utiliser type.

je pense que j'avais testé le sans "s", mais tester un truc me prend 20 min

 
Un grand brûlé sur une table d'opération à qui il manquait certains morceaux.
Si le client avait demandé saignant il l'aura probablement renvoyé en cuisine.
 

link

 
Alors autantemps pour moi, c'était "APERTURE THERMAL NECK WRAP" la recherche et l'image est ICI [NSFL].

 
Mmm la biafine va ptet pas suffire là ^^'

Oui la différence est importante. Le builtin shell est getopts, getopt(3) est la fonction C et getopt(1) est un utilitaire externe existant en deux versions (originel et GNU, la première est beaucoup plus limitée que le builtin)

Je sais pas, getopt(1)/GNU a plus de fonctionnalités que getopts(1), donc niveau flexibilité ça devrait être possible. Après je sais pas si ça ajoute des limitations autres, mais si true(1) peut être aussi bien un builtin qu'un utilitaire, je vois pas pourquoi getotps(1) pourrait pas.

 
C'est comme read, l'interface de getopts demande de modifier une variable d'environnement.  C'est plutot difficile de le faire sans etre dans le process.
 

bash est devenu au fil du temps utilisable ( enfin au moins autant que le PHP   )
 
tu as même des tableaux associatifs avec bash 4:
http://tldp.org/LDP/abs/html/bashver4.html

c'est quoi les avantages/inconvenients de ces 2 techniques ?

en php ça s'arrête quand il y a une erreur, en Shell ça passe à la ligne suivante.

mais qu'est ce que tu racontes

c'est pourtant l'impression que j'ai. Explique-moi mon erreur ?

si t'appelle un programme externe et qu'il y a une erreur bien sûr ça continue, comme dans n'importe quel langage
 
si t'utilise du bash pur et qu'il y a une erreur de syntaxe ça s'arrête.
 
c'est juste qu'en bash tu as tendance à beaucoup plus appeller des programmes externes mais c'est très facile de s'en protéger, exemple:
 

function die()
{
  echo "$@"
  exit 1
}
 
tree $directory || die "error: tree on directory: $directory failed"

 
Je suppose que tu ne fais pas
 

ou
 

function die()
{
  echo "$@"
  exit 1
}
 
tree $directory || die "error: tree on directory: $directory failed"

j'avais jamais vu ça sous cet angle.  

non, j'avais un peu demandé et personne ne semblait connaître non plus c'est intéressant.

3ème truc que j'apprends de rang : tous les Lyon - strass ne s'arretent pas à Montbé, coucou de Belfort  

 
C'est pour moi une des deux bases de l'ecriture de scripts.  L'autre etant de mettre toutes les variables entre quotes par defaut. et de n'enlever ceux-ci que quand on veut la decoupe qui va s'en suivre.