j'étais familier de la commande truss sur FreeBSD 4.x, et je viens de
m'apercevoir qu'elle ne fonctionne pas sur 5.4 :
$ truss ls
truss: cannot open /proc/4509/mem: No such file or directory
$ truss ls
truss: PIOCWAIT: Input/output error
...
est ce connu ? Mon procfs est bien monté, mais j'ai des soucis avec son
contenu qui semble limité a 128 process (ps en retourne bien plus, mais
ls -1 /proc/ | wc -l retourne invariablement 128.)
Bah en 92 j'ai bien fait des TP de shell avec un sh sans fonctions (Ultrix pour ceux qui ont quelques souvenirs...)
Oui, mais nous sommes en 2006 et maintenant les shells peuvent avoir des fonctions, des tableaux et des constructions un peu moins spartiates qu'auparavant.
Vouloir faire croire que rien n'est mieux depuis l'origine des temps, ce n'est pas ma tasse de thé. Cela n'empêche pas (bien au contraire, d'ailleurs) d'insister sur le pb de la portabilité. -- Eric Jacoboni, ne il y a 1441638132 secondes
Erwan David <erwan@rail.eu.org> writes:
Bah en 92 j'ai bien fait des TP de shell avec un sh sans fonctions
(Ultrix pour ceux qui ont quelques souvenirs...)
Oui, mais nous sommes en 2006 et maintenant les shells peuvent avoir
des fonctions, des tableaux et des constructions un peu moins
spartiates qu'auparavant.
Vouloir faire croire que rien n'est mieux depuis l'origine des temps,
ce n'est pas ma tasse de thé. Cela n'empêche pas (bien au contraire,
d'ailleurs) d'insister sur le pb de la portabilité.
--
Eric Jacoboni, ne il y a 1441638132 secondes
Bah en 92 j'ai bien fait des TP de shell avec un sh sans fonctions (Ultrix pour ceux qui ont quelques souvenirs...)
Oui, mais nous sommes en 2006 et maintenant les shells peuvent avoir des fonctions, des tableaux et des constructions un peu moins spartiates qu'auparavant.
Vouloir faire croire que rien n'est mieux depuis l'origine des temps, ce n'est pas ma tasse de thé. Cela n'empêche pas (bien au contraire, d'ailleurs) d'insister sur le pb de la portabilité. -- Eric Jacoboni, ne il y a 1441638132 secondes
totof2000
Erwan David writes:
Bah en 92 j'ai bien fait des TP de shell avec un sh sans fonctions (Ultrix pour ceux qui ont quelques souvenirs...)
Oui, mais nous sommes en 2006 et maintenant les shells peuvent avoir des fonctions, des tableaux et des constructions un peu moins spartiates qu'auparavant.
Cela dit, sur la plupart des OS récents, y a bien un Perl installé en standard qui peut prendre en charge ce genre de choses ...
Erwan David <erwan@rail.eu.org> writes:
Bah en 92 j'ai bien fait des TP de shell avec un sh sans fonctions
(Ultrix pour ceux qui ont quelques souvenirs...)
Oui, mais nous sommes en 2006 et maintenant les shells peuvent avoir
des fonctions, des tableaux et des constructions un peu moins
spartiates qu'auparavant.
Cela dit, sur la plupart des OS récents, y a bien un Perl installé en
standard qui peut prendre en charge ce genre de choses ...
Bah en 92 j'ai bien fait des TP de shell avec un sh sans fonctions (Ultrix pour ceux qui ont quelques souvenirs...)
Oui, mais nous sommes en 2006 et maintenant les shells peuvent avoir des fonctions, des tableaux et des constructions un peu moins spartiates qu'auparavant.
Cela dit, sur la plupart des OS récents, y a bien un Perl installé en standard qui peut prendre en charge ce genre de choses ...
Eric Jacoboni
"totof2000" writes:
Cela dit, sur la plupart des OS récents, y a bien un Perl installé en standard qui peut prendre en charge ce genre de choses ...
Oeuf corse...
Cela dit, apprendre le shell avec Perl/Python/Ruby, c'est pas joué :)
-- Eric Jacoboni, ne il y a 1441642753 secondes
"totof2000" <cdesquesnes@ifrance.com> writes:
Cela dit, sur la plupart des OS récents, y a bien un Perl installé en
standard qui peut prendre en charge ce genre de choses ...
Oeuf corse...
Cela dit, apprendre le shell avec Perl/Python/Ruby, c'est pas joué :)
Aprés vérification ça marche avec bash et zsh, mais pas csh ni sh,
Ben non, pas tant que ça... ce sont des extensions au shell POSIX et ça date au moins de 93 puisque ksh93 en dispose déjà
(( ... )), qui est une forme alternative de la commande « let », est une invention de ksh88; donc
while (( i < 5 )); do ...; done
etc.
La forme triple avec « for », c'est ksh93.
-- Christian "naddy" Weisgerber
Marwan Burelle
In article , Eric Jacoboni wrote:
Moi je veux bien, mais cite-moi un système où l'on ne pourrait pas installer bash ou zsh ou ksh ? C'est sûr que si tu veux rester avec le sh de base, ça va pas le faire.
Je suis d'accord, le point que je soulevais, c'est que quand tu commence à faire des scripts plus ou moins évolués (surtout si tu dois les fournir aux étudiants) tu cherches (de temps en temps ;) la portabilité, donc un shell commun à toutes les plateformes et ça réduit pas mal le champ.
En gros, j'ai rencontré des machines qui avait un csh/tcsh, un ksh et un sh "de base" et c'est tout, d'autres qui n'avait que bash (et un lien hard pour sh), d'autres encore avec juste sh et tcsh (un FreeBSD brut d'installe par exemple) ... En prime, même si plusieurs shell sont installés, les chemins ne sont pas toujours les même, c'est pas bien pratique pour commencer un script avec #!/... (et devoir commencer tous ses scripts par un bout de script qui teste la présence des shells et le chemin d'accès d'un shell, bon voila ...
Donc, il y avait ksh, non ?
Oui (même que les étudiants, débutant sous Unix, avaient droit à ksh en mode vi comme shell par défaut, sans possibilité d'en changer ... )
La construction for ((...)) n'a absolument rien à voir avec GNU, hein. Et si elle n'y est pas, il n'y aura pas non plus jot ou autres seq... donc à moins de leur apprendre le Bourne Shell de 70, il te reste peu d'alternatives parce que je suppose qu'en ce cas, ce shell ne sera même pas POSIX (ah si, il y en a une : si on ne me donne pas les moyens de bosser, moi, je ne bosse pas).
J'ai pas dit que c'était gnu, hein, j'ai juste dit que ksh n'est pas plus un dénominateur commun sur tous les OS, après ça dépend, s'il s'agit de faire des manips directes en shell ou d'écrire des scripts réutilisables. Après je suis d'accord, si on ne me donne pas les moyens de bosser je bosse pas non plus (j'ai eu le cas aussi, on m'a mis dans un salle de TP où portmap ne tournait pas pour faire un TP de Sun-RPC ... pratique, d'autant plus que pour je ne sais quelle obscure raison, il n'y avait pas de ssh sur ces machines, et forcément les machines avec portmap, elles n'avaient que un sshd qui tournait et pas de serveur telnet ... )
Enfin tout ce que je voulais dire c'est que le dénominateur commun aux différents Unix est assez restreint (jot ou seq pas sur toutes les systèmes, ksh, bash ou zsh n'étant pas partout ... )
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <m2u0bsh16g.fsf@titine.jacoboni.fr>, Eric Jacoboni wrote:
Moi je veux bien, mais cite-moi un système où l'on ne pourrait pas
installer bash ou zsh ou ksh ? C'est sûr que si tu veux rester avec le
sh de base, ça va pas le faire.
Je suis d'accord, le point que je soulevais, c'est que quand tu
commence à faire des scripts plus ou moins évolués (surtout si tu dois
les fournir aux étudiants) tu cherches (de temps en temps ;) la
portabilité, donc un shell commun à toutes les plateformes et ça
réduit pas mal le champ.
En gros, j'ai rencontré des machines qui avait un csh/tcsh, un ksh et
un sh "de base" et c'est tout, d'autres qui n'avait que bash (et un
lien hard pour sh), d'autres encore avec juste sh et tcsh (un FreeBSD
brut d'installe par exemple) ... En prime, même si plusieurs shell
sont installés, les chemins ne sont pas toujours les même, c'est pas
bien pratique pour commencer un script avec #!/... (et devoir
commencer tous ses scripts par un bout de script qui teste la présence
des shells et le chemin d'accès d'un shell, bon voila ...
Donc, il y avait ksh, non ?
Oui (même que les étudiants, débutant sous Unix, avaient droit à ksh
en mode vi comme shell par défaut, sans possibilité d'en changer ... )
La construction for ((...)) n'a absolument rien à voir avec GNU,
hein. Et si elle n'y est pas, il n'y aura pas non plus jot ou autres
seq... donc à moins de leur apprendre le Bourne Shell de 70, il te
reste peu d'alternatives parce que je suppose qu'en ce cas, ce shell
ne sera même pas POSIX (ah si, il y en a une : si on ne me donne pas
les moyens de bosser, moi, je ne bosse pas).
J'ai pas dit que c'était gnu, hein, j'ai juste dit que ksh n'est pas
plus un dénominateur commun sur tous les OS, après ça dépend, s'il
s'agit de faire des manips directes en shell ou d'écrire des scripts
réutilisables. Après je suis d'accord, si on ne me donne pas les
moyens de bosser je bosse pas non plus (j'ai eu le cas aussi, on m'a
mis dans un salle de TP où portmap ne tournait pas pour faire un TP de
Sun-RPC ... pratique, d'autant plus que pour je ne sais quelle obscure
raison, il n'y avait pas de ssh sur ces machines, et forcément les
machines avec portmap, elles n'avaient que un sshd qui tournait et pas
de serveur telnet ... )
Enfin tout ce que je voulais dire c'est que le dénominateur commun aux
différents Unix est assez restreint (jot ou seq pas sur toutes les
systèmes, ksh, bash ou zsh n'étant pas partout ... )
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Moi je veux bien, mais cite-moi un système où l'on ne pourrait pas installer bash ou zsh ou ksh ? C'est sûr que si tu veux rester avec le sh de base, ça va pas le faire.
Je suis d'accord, le point que je soulevais, c'est que quand tu commence à faire des scripts plus ou moins évolués (surtout si tu dois les fournir aux étudiants) tu cherches (de temps en temps ;) la portabilité, donc un shell commun à toutes les plateformes et ça réduit pas mal le champ.
En gros, j'ai rencontré des machines qui avait un csh/tcsh, un ksh et un sh "de base" et c'est tout, d'autres qui n'avait que bash (et un lien hard pour sh), d'autres encore avec juste sh et tcsh (un FreeBSD brut d'installe par exemple) ... En prime, même si plusieurs shell sont installés, les chemins ne sont pas toujours les même, c'est pas bien pratique pour commencer un script avec #!/... (et devoir commencer tous ses scripts par un bout de script qui teste la présence des shells et le chemin d'accès d'un shell, bon voila ...
Donc, il y avait ksh, non ?
Oui (même que les étudiants, débutant sous Unix, avaient droit à ksh en mode vi comme shell par défaut, sans possibilité d'en changer ... )
La construction for ((...)) n'a absolument rien à voir avec GNU, hein. Et si elle n'y est pas, il n'y aura pas non plus jot ou autres seq... donc à moins de leur apprendre le Bourne Shell de 70, il te reste peu d'alternatives parce que je suppose qu'en ce cas, ce shell ne sera même pas POSIX (ah si, il y en a une : si on ne me donne pas les moyens de bosser, moi, je ne bosse pas).
J'ai pas dit que c'était gnu, hein, j'ai juste dit que ksh n'est pas plus un dénominateur commun sur tous les OS, après ça dépend, s'il s'agit de faire des manips directes en shell ou d'écrire des scripts réutilisables. Après je suis d'accord, si on ne me donne pas les moyens de bosser je bosse pas non plus (j'ai eu le cas aussi, on m'a mis dans un salle de TP où portmap ne tournait pas pour faire un TP de Sun-RPC ... pratique, d'autant plus que pour je ne sais quelle obscure raison, il n'y avait pas de ssh sur ces machines, et forcément les machines avec portmap, elles n'avaient que un sshd qui tournait et pas de serveur telnet ... )
Enfin tout ce que je voulais dire c'est que le dénominateur commun aux différents Unix est assez restreint (jot ou seq pas sur toutes les systèmes, ksh, bash ou zsh n'étant pas partout ... )
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Eric Jacoboni
Marwan Burelle writes:
Enfin tout ce que je voulais dire c'est que le dénominateur commun aux différents Unix est assez restreint (jot ou seq pas sur toutes les systèmes, ksh, bash ou zsh n'étant pas partout ... )
C'est bien pour ça aussi que j'ai cessé de conseiller l'utilisation du shell pour des trucs un tant soi peu complexes... Quand on dispose de Perl/Python/Ruby, vouloir persister en shell, c'est vouloir se faire du mal, àmha.
-- Eric Jacoboni, ne il y a 1441813213 secondes
Marwan Burelle <burelle@lri.fr> writes:
Enfin tout ce que je voulais dire c'est que le dénominateur commun aux
différents Unix est assez restreint (jot ou seq pas sur toutes les
systèmes, ksh, bash ou zsh n'étant pas partout ... )
C'est bien pour ça aussi que j'ai cessé de conseiller l'utilisation du
shell pour des trucs un tant soi peu complexes... Quand on dispose de
Perl/Python/Ruby, vouloir persister en shell, c'est vouloir se faire
du mal, àmha.
Enfin tout ce que je voulais dire c'est que le dénominateur commun aux différents Unix est assez restreint (jot ou seq pas sur toutes les systèmes, ksh, bash ou zsh n'étant pas partout ... )
C'est bien pour ça aussi que j'ai cessé de conseiller l'utilisation du shell pour des trucs un tant soi peu complexes... Quand on dispose de Perl/Python/Ruby, vouloir persister en shell, c'est vouloir se faire du mal, àmha.
