- Shell - lists.asyd.net

Substitution zsh avec sudo
by Bruno Bonfils 24 Fév '06

24 Fév '06

Bonjour, alors voilà, comme sans doutes beaucoup de sysop (comme Marc aime à les appeler :) je ne me logge quasiment en root et privilégie l'utilisation de sudo. Alors voici ma problématique : Soit un alias vi sur vim (si celui ci est disponible) définis dans le .zshrc de mon user, je voudrais faire en sorte que quand je tappe sudo vi fichier l'alias soit substitué avant d'executé la commande sudo, ce qui n'est pas le cas (du moins avec ma conf, mais à premiere vue je ne vois rien de relatif) alors que sudo vi *~*.db* est bien substitué avant l'appel de sudo (sans même faire tab) Connaissez vous une solution ? Merci d'avance -- http://asyd.net/home/

3 4

debianworld is no more, it has ceased to live, it is an ex-mailing-list.
by Philippe Jacquot 23 Fév '06

23 Fév '06

De mieux en mieux sur shellscript@debianworld. Maintenant on se prend une trentaine de retours d'erreur MailerDaemon quand on poste dessus. :-) pj

3 2

à propos du wiki
by Bruno Bonfils 23 Fév '06

23 Fév '06

Juste quelques petits trucs sur dokuwiki : - éviter les espaces dans les noms des pages - RESPECTER la hiérarchie au possible. Pour maintenir des wikis depuis quelques temps déjà, mon plus gros problème constanté est les gens qui mettent les infos pas à leur place, et qui ne visionnement même pas le rendu une fois l'édition terminée. - faire apercu avant de valider votre modification. - il n'est actuellement pas disponible (il le sera dans la semaine) mais vous pouvez utilisez le tag ~~DISCUSSION~~ pour activer le mode discussion sur une page (commentaires sans avoir besoin d'être enregistré) - dès que vous avez des caractères bizarres, utilisez les balises <code> et </code>. Néanmoins, il est possible d'invalider le parsing en mettant du texte en utilisant %%. Par exemple --8<-- * ls récursif # ls %%**/*%% --8<-- - Ne pas hésitez à jouer avec la sandbox : http://cli.asyd.net/home/doku.php?id=sandbox Si l'un d'entre vous dispose d'une solution de sauvegarde fiable (bande, support optique) merci de me le faire savoir ! merci à vous, et vive la CLI ! -- http://asyd.net/home/

5 10

[cli] matchit : quel interet ?
by Marc Chantreux 23 Fév '06

23 Fév '06

salut, http://cli.asyd.net/home/outils/vim/plugins?rev=1140609960 quel interet puisque matchit fait partie de la distribution standard depuis .... mc

2 3

Choisissez un shell remanié
by Marc Chantreux 21 Fév '06

21 Fév '06

Choisissez un shell : Le choix est polémique, certain d'entre nous pronnent zsh, d'autres bash. Dans la majorité des distributions linux, bash est le bourne shell par défaut. Zsh est moins populaire mais plus puissant. En pratique les premiers pas sont identiques sous les deux shells (tous deux dérivés du bourne shell traditionnel (sh)). Pour plus d'informations, lire le [[shell:comparatif]].

5 14

Wiki... bien plus loin ?
by Bruno Bonfils 21 Fév '06

21 Fév '06

Je viens de me poser la question, on va parler de vim/emacs/mutt etc sur le wiki a priori (ce qui ne me dérange pas du tout, bien au contraire). Vous pensez que ca peut être utile qu'on parle d'autres outils tel que des outils réseaux ? (je peux par exemple donner une réponse à une des questions qui tuent du genre : comment faire un "telnet" sur une socket unix, et plein de tips d'autres turcs) -- http://asyd.net/home/

3 2

Cohérence des termes sur le wiki
by Bruno Bonfils 21 Fév '06

21 Fév '06

Bonjour, je suis en train de compléter le wiki, et par exemple il me vient le problème suivant : comment traduisez vous regex ? Expression régulière ou expression rationnelle ? Quelque soit la réponse, il serait intéressant de disposer d'une page où l'on centralise nos choix de traduction afin de garder une cohérence au sein du Wiki. Merci de consulter/compléter la page : http://cli.asyd.net/home/howto -- http://asyd.net/home/

2 3

paul et mickey ...
by Marc Chantreux 21 Fév '06

21 Fév '06

salut a tous, je viens de copier/coller une partie du comparatif des shells de mon site. Je n'ai pas relu mais comme c'est a mon avis source ce debats explosif et que je ne veux heurter les sensibilités de personne, *moi* ;), je vous demande d'y faire un tour afin que nous ajustions collectivement le texte. cordialement mc

2 1

[HS] livres et sur les shells scripts
by Jeremy Monnet 20 Fév '06

20 Fév '06

Salut tout le monde, Je rebondis sur la question qui vient d'être posée. Vu qu'on est en train de discuter site web pour recenser les commandes utiles etc, je pense qu'il serait pas mal aussi de faire un point sur la doc en ligne, les livres existant. En effet, la documentation "de référence" n'est pas forcément la plus adaptée pour un débutant par exemple. J'en viens donc à mes conseils du jour ;-) : - Le livre de Christophe Blaess "les scripts shell" a été pour moi une mine de renseignements sur les possibilités des shells, je le recommande. - l'ABSG est intéressant pour comprendre les syntaxes inconnues (donc dans l'étude de l'existant) mais pas pour l'apprentissage. Probablement parce qu'il n'a pas été pensé dans ce sens. Quid de la doc de Zsh ? - Pour apprendre le shell, et surtout pour avoir des "trucs et astuces", l'étude des scripts d'une distribution est probablement une bonne chose : ils ont été écrits par plusieurs personnes, avec des habitudes différentes, des conventions "presque" communes. (Pour l'exemple, j'ai appris des syntaxes bash comme les ${maVar##bla} en relisant les scripts réseaux de ma lfs pour y intégrer le support pour le wireless) Voila, tout commentaire bienvenu ! Jeremy PS : Je cause d'un livre, et du bash parce que je connais qu'eux. Je ne fais aucun sectarisme, cela va de soi ! :-) -- Linux Registered User #317862 Linux From Scratch Registered User #16571 Please do not send me .doc, .xls, .ppt, as I will *NOT* read them.

5 35

attente d'un signal
by Vincent Lefevre 20 Fév '06

20 Fév '06

Une petite question... avec un shell POSIX (sans supposition supplémentaire), est-il possible d'attendre un signal pour terminer avec un code de retour nul une fois le signal en question reçu? Évidemment, je veux une méthode suffisamment élégante et sans défaut (pas d'attente active consommant du temps CPU et la terminaison du processus doit être immédiate au sens strict du terme). C'est bien le processus shell qui doit recevoir le signal, pas un de ses fils. C'était le genre de script plus simple à écrire en shell qu'en Perl, surtout qu'il doit faire un "source" pour récupérer des variables d'environnement (à passer à un des processus fils du script). Pour le moment, je pense terminer le script par un "exec perl ..." où le petit script Perl contient un trap et fait un "POSIX::pause" (voire un sleep si le module POSIX est inexistant). -- Vincent Lefèvre <vincent(a)vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / SPACES project at LORIA

2 9