Discussion :

[OlFo66]

Bonjour les amis,

J'ai fais un superbe script de sauvegarde centralisé pour l'ensemble de nos serveurs sous linux qui sont éparpillés entre plusieurs sites physiques.
Les serveurs sont sous plusieurs distributions linux différentes.

Une fois le script installé celui-ci est opérationnel sur tous les serveurs sauf UN: celui sous Debian SQUEEZE.

En gros, la substitution avec ":" ne fonctionne plus.

Après quelques recherches, je me suis rendu compte que nos amis de chez Debian ont créé un lien symbolique de /bin/sh vers /bin/dash.

La solution est très simple: j'appelle mon script avec /bin/bash au lieu de /bin/sh mais depuis, une question me brûle les lèvres: WTF ?!

-Pourquoi modifier quelque chose qui marche depuis des lustres pour des changements qui n'apportent au final pas énormément d'améliorations (en tout cas je ne les ai pas encore trouvée)?
- Pourquoi "obliger" les utilisateurs à l'utiliser avec ce lien symbolique depuis /bin/sh?
- Au risque de passer pour un traitre aux yeux des puristes de l'open source: pourquoi, quitte à faire des modifications de ce genre, ne pas implémenter un langage de type POWERSHELL, orienté objet.
Le gain de temps pour la rédaction d'un script est monstrueux.

Enfin voilà c'était mon coup de gueule du jour, sur ce, bonne journée.

[gangsoleil]

-Pourquoi modifier quelque chose qui marche depuis des lustres pour des changements qui n'apportent au final pas énormément d'améliorations (en tout cas je ne les ai pas encore trouvée)?
- Pourquoi "obliger" les utilisateurs à l'utiliser avec ce lien symbolique depuis /bin/sh?
- Au risque de passer pour un traitre aux yeux des puristes de l'open source: pourquoi, quitte à faire des modifications de ce genre, ne pas implémenter un langage de type POWERSHELL, orienté objet.

A mon grand damme, Debian s'ubuntu-ise, c'est a dire qu'ils font de plus en plus de choses orientees "tres grand publique", sans le mettre en avant ; c'est a dire que ce n'est pas cache, mais ce n'est pas non plus evident, comme le coup du lien.

Pourquoi ? Je ne sais pas. Surement un effet de mode. Mais ce qui est certain, c'est que c'est problematique.

[OlFo66]

Merci gangsoleil,

Est-ce qu'il existe une distribution Linux qui conserve l'emplacement des fichiers, les binaires etc au plus près de ce qu'il se faisait dans les débuts d'UNIX?... ou de ce qu'il se faisait dans les années 80-90 ?

Je travaille avec un informaticiens des débuts d'UNIX qui migre de plus en plus vers µSoft car il est fatigué de ce genre de modifications.

Il me semblait que SLAKWARE ou GENTOO étaient restés proche des origines... est-ce kle cas ?

[frp31]

Merci gangsoleil,

Est-ce qu'il existe une distribution Linux qui conserve l'emplacement des fichiers, les binaires etc au plus près de ce qu'il se faisait dans les débuts d'UNIX?... ou de ce qu'il se faisait dans les années 80-90 ?

Je travaille avec un informaticiens des débuts d'UNIX qui migre de plus en plus vers µSoft car il est fatigué de ce genre de modifications.

Il me semblait que SLAKWARE ou GENTOO étaient restés proche des origines... est-ce kle cas ?

slakeware oui
gentoo je sais pas
les BSD aussi mais c'est plus system V du coup

les LSB linux standard base avait été crée pour ce but justement d'imposer un guide de bonne pratique pour limiter la multiplication anarchique de distribs qui n'existent que pour satisfaire aux mauvaises habitude des types qui les développaient.... mais ça semble avoir été oublié/abandonné.

[thierry.chich]

Pour le pourquoi, voici:
https://wiki.ubuntu.com/DashAsBinSh

En résumé, bash est puissant, mais il est gros et mou pour le démarrage.
Je comprends ton agacement, mais pour ce qui est des ex-gourous qui passent chez Microsoft pour avoir la stabilité dans le temps, je dis: LOL, reLOL et megaLOL.

[gangsoleil]

Pour information, je me suis tourne vers FreeBSD ou OpenBSD (selon l'utilisation) et j'en suis tres content.

[jlliagre]

En gros, la substitution avec ":" ne fonctionne plus.

Un exemple concret de ce qui ne marche plus ?

Après quelques recherches, je me suis rendu compte que nos amis de chez Debian ont créé un lien symbolique de /bin/sh vers /bin/dash.

C'est leur droit. Ce changement n'est pas sensé impacter les scripts "bien écrits".

La solution est très simple: j'appelle mon script avec /bin/bash au lieu de /bin/sh mais depuis, une question me brûle les lèvres: WTF ?!

A priori, c'est un bug du script ou de dash. Assumer que /bin/sh est en fait /bin/bash est une erreur de programmation, fréquente mais une erreur quand même.

-Pourquoi modifier quelque chose qui marche depuis des lustres pour des changements qui n'apportent au final pas énormément d'améliorations (en tout cas je ne les ai pas encore trouvée)?

Dans ce cas précis, pour des raisons de performances.

- Pourquoi "obliger" les utilisateurs à l'utiliser avec ce lien symbolique depuis /bin/sh?

Parce que dash est un shell compatible "POSIX".

- Au risque de passer pour un traitre aux yeux des puristes de l'open source: pourquoi, quitte à faire des modifications de ce genre, ne pas implémenter un langage de type POWERSHELL, orienté objet.
Le gain de temps pour la rédaction d'un script est monstrueux.

Ca n'a rien à voir avec l'Open Source, /bin/sh n'a pas du tout besoin d'être Open Source. Il n'est non plus pas obligatoire d'utiliser le shell, il existe plein d'autres langages si le shell est inadapté au besoin. Cependant, seule la présence du shell standard est garantie

[thierry.chich]

Pour renchérir sur mon petit camarade, j'ajoute que por des scripts un peu compliqués, je passe systématiquement à Perl ou python. Ils sont tout aussi bien que powershell. D'ailleurs, à une époque où powershell n'existait pas, je scriptait en Perl pour administrer du windows 2000.

[OlFo66]

Un exemple concret de ce qui ne marche plus ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
# toto="tatatititoto"
# tutu=${$toto:0:6}
${$toto:0:6} : mauvaise substitution

Il est vrai que j'aurais pu utiliser cut.

C'est leur droit. Ce changement n'est pas sensé impacter les scripts "bien écrits".

Qu'est -ce que cela veut dire ?
Ce script tournait sur tout notre parc de serveurs, surement le plus hétérogène sur lequel j'ai pu travailler ^_^.

A priori, c'est un bug du script ou de dash. Assumer que /bin/sh est en fait /bin/bash est une erreur de programmation, fréquente mais une erreur quand même.

Mea culpa!
Il est vrai que je devrais appeler le script avec /bin/bash mais par habitude et flemme (oui oui, 2 lettres en plus me fatiguent ^_^) je note plus souvent /bin/sh.

Dans ce cas précis, pour des raisons de performances.
Parce que dash est un shell compatible "POSIX".

[...] L'amélioration des performances est-elle si importante que l'ajout de dash comme shelle par défaut est obligatoire ?

Ca n'a rien à voir avec l'Open Source, /bin/sh n'a pas du tout besoin d'être Open Source. Il n'est non plus pas obligatoire d'utiliser le shell, il existe plein d'autres langages si le shell est inadapté au besoin. Cependant, seule la présence du shell standard est garantie

Je me lance dans le Perl, il semble très puissant et les scripts ont l'air assez rapides à rédiger (flemme quand tu nous tiens :p)

Merci pour vos réponses les amis.

[jlliagre]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
# toto="tatatititoto"
# tutu=${$toto:0:6}
${$toto:0:6} : mauvaise substitution

Il est vrai que j'aurais pu utiliser cut.

Oui, cut aurait été portable.

Qu'est -ce que cela veut dire ?
Ce script tournait sur tout notre parc de serveurs, surement le plus hétérogène sur lequel j'ai pu travailler ^_^.

Il n'y avait donc pas de serveurs Solaris dans ce parc.
Par script bien écrit, je veux dire script qui n'utilise que ce qui est défini par le standard des commandes appelées. Pour le shell, les seules substitutions supportées sont décrites ici: http://pubs.opengroup.org/onlinepubs...l#tag_02_06_02
${chaine:debut:fin} est une extension disponible dans ksh et bash (et sûrement d'autres), mais n'est pas garanti dans un shell POSIX.

[...] L'amélioration des performances est-elle si importante que l'ajout de dash comme shelle par défaut est obligatoire ?

Pas obligatoire mais un choix qui se défend. Diminuer par exemple la durée de la séquence de boot d'un OS qui souvent lance un très grand nombre de scripts est légitime.

Je me lance dans le Perl, il semble très puissant et les scripts ont l'air assez rapides à rédiger (flemme quand tu nous tiens :p)

Je préfère ksh93 / awk / sed / tr / etc. mais c'est juste une opinion personnelle..

[OlFo66]

Merci jlliagre pour le lien et merci pour ces renseignements.
A bientôt les amis