/* Topic des codeurs [6] */

tshirtman · Le 26/09/2011, à 19:54

yep, faut définir une fonction…

HP · Le 26/09/2011, à 19:55

helly a écrit :

Comment faire un alias duree pour que ça puisse s’invoquer :
duree fichier.avi

tu fais pas un alias mais une fonction… à l'usage ça ne change rien.

helly · Le 26/09/2011, à 20:01

Ras' a écrit :

http://forum.ubuntu-fr.org/viewtopic.php?id=171993

Cool ~~story~~ merci bro’ .
(et aussi aux autres qui ont été gentillement grillés )
Je trouve quand même ça étrange qu’on ne puisse pas faire d’alias pour ça, m’enfin bon, it works, c’est me principal.

tshirtman · Le 26/09/2011, à 20:04

ben un alias, c'est pas très intelligent, c'est juste un remplacement de texte…

Elzen · Le 26/09/2011, à 20:11

Tiens, tant qu'on est dans la conf bash… j'n'aime pas que ce que je tape soit dans l'historique sans que j'lui ai demandé. Alors je peux (et je le fais, d'ailleurs) taper un espace devant chaque truc, mais c'est quand même un peu lourd, et surtout ça fait qu'on n'a plus d'historique du tout, même dans le shell en cours.

Vous savez s'il y a une option pour que bash se comporte comme l'interpréteur python, qu'il prenne les commandes dans son historique en cours, mais qu'il n'enregistre ça nulle part ?

Sinon, j'peux aussi essayer de me débrouiller pour supprimer le .bash_history après chaque appel ou un truc comme ça, mais j'aimerais bien pouvoir quand même garder un fichier d'historique dans certains cas (en fait j'utilise deux terminaux différents, j'voudrais en lancer un avec l'option pour qu'il ne mémorise pas et l'autre normalement)

J'suis clair ? J'ai pas l'impression

helly · Le 26/09/2011, à 20:12

Nan, c’était pas du bash, mais du zsh !
Sinon, en redirigeant l’historique vers /dev/null, je crois que ça marche.

edit : testé, ça marche .
C’est lisible pour le terminal en cours, mais dès qu’on le ferme l’historique s’efface .

Dernière modification par helly (Le 26/09/2011, à 20:14)

Elzen · Le 26/09/2011, à 20:14

Ouais, mais t'as pas précisé et dans le lien de Ras' c'était du bash

Rediriger l'historique, t'peux préciser ? Les entrée, sortie et sortie d'erreur, je sais les rediriger, mais l'historique, je sais pas faire

helly · Le 26/09/2011, à 20:15

Bhé par exemple, pour mon zshrc, je met

HISTFILE=/dev/null

ça doit être la même chose pour bashrc je pense.

Elzen · Le 26/09/2011, à 20:29

Yep, merci ^^

Du coup, j'ai réglé mon terminal dans lequel j'veux pas d'historique pour qu'au lieu de me lancer bash, il me lance sh -c HISTFILE=/dev/null bash (comme il me lançait déjà sh -c PYTHONSTARTUP=$HOME/.pyrc python au lieu de python tout seul), et dans l'autre, je laisse le truc par défaut.

Ça a l'air d'être bon, merci ^^

Rolinh · Le 26/09/2011, à 20:37

Hop les gens

ça fait longtemps que je n'étais pas passé (examens, ré-emménagement, rentrée universitaire toussa) mais me revoilà.

Je suis donc repartis un petit coup sur LinCopier (aaaah, que ça fait du bien un petit peu de C).
Donc:
@Grim: j'ai corrigé les erreurs que tu as relevées avant ton poste du 6 juillet dernier.
En ce qui concerne le poste en question, tu avais soulevé le "problème" de MAXPATHLEN. En fait, j'en avais pas mal discuté avec quelques amis codeurs dont Kaworu qui en avait fait un blog post qui t'intéressera sûrement.
Voilà le commit

Allez, kawa et je ré-attaque

Pylades · Le 26/09/2011, à 21:00

Ouais, je plussoie en retard pour la fonction.

Elzen · Le 26/09/2011, à 21:05

Tiens, j'en ai profité pour me refaire mon .pyrc :

#! /usr/bin/python
# coding: Utf-8

print "\033]0;seth@fadreils: Python\007"

import sys, rlcompleter, readline
readline.parse_and_bind("tab: complete")
sys.ps1 = "\033[1;32m~~~> \033[0m"
sys.ps2 = "\033[32m ~~> \033[0m"

(Ouais, les ~~ symbolisent le serpent, ç'pour ça qu'ils sont en vert ^^)
Z'en dites quoi ? Vous avez d'autres trucs à me conseiller ?

Dernière modification par ArkSeth (Le 26/09/2011, à 21:06)

Pylades · Le 26/09/2011, à 21:12

Comme ce n’est pas un exécutable, je doute de l’utilité du shebang…

Elzen · Le 26/09/2011, à 21:13

Bah c'est surtout pour la coloration syntaxique dans Vim et dans ElzEdit, vu qu'il n'y a pas de « .py » à la fin (j'trouvais ça moche avec un .py)

HP · Le 26/09/2011, à 21:26

ArkSeth a écrit :

Bah c'est surtout pour la coloration syntaxique dans Vim […]

Avec emacs on a les Local Variables pour çà, par exemple à la fin de mon bashrc :

# Local Variables:
# mode: sh
# sh-shell: bash
# coding: utf-8
# End:

Il existe sûrement un truc similaire pour vim.

Elzen · Le 26/09/2011, à 21:32

Ouais, mais est-ce vraiment utile de faire plusieurs lignes de conf spécifiques à un éditeur donné, alors que le shebang seul suffit à ce que le fichier soit reconnu comme de type mime text/x-python et donc coloré correctement partout ?

HP · Le 26/09/2011, à 21:39

ArkSeth a écrit :

Ouais, mais est-ce vraiment utile de faire plusieurs lignes de conf spécifiques à un éditeur donné, […]

çà, c'est mon choix… j'aime bien comme ça ; y a certainement moyen de faire plus court .
De plus avec l'exemple du bashrc, il faut savoir que le mode Shell (ou sh) a une grand quantité de sous-mode, dont bash, mais aussi sh, zsh, ksh… etc. Le coding utf-8 est accessoire, et n'est qu'une redite de la première ligne du même fichier… donc, bon, une fois de plus tu t'emballes un peu beaucoup pour rien !

tshirtman · Le 26/09/2011, à 21:40

oui, l'équivalent pour vim s'appelle les modlines… mais perso je préfère les trucs reconnus par tous les éditeurs, surtout s'ils sont parfaitement inoffensifs (un commentaire).

HP · Le 26/09/2011, à 21:41

tshirtman a écrit :

oui, l'équivalent pour vim s'appelle les modlines…

Ah ouais, exact… à ne pas confondre avec la modeline de emacs, ce qui n'a rien à voir du tout.

Pylades · Le 26/09/2011, à 21:45

HP a écrit :

Il existe sûrement un truc similaire pour vim.

Yep.

#vim:ft=python

Mais maintenant, je comprends ArkSeth.

Elzen · Le 26/09/2011, à 21:45

@HP : j'm'emballe pas, je pose une question

J'reformule, si tu préfères : étant donné que de toute façon, avec le shebang, on a le bon type mime, donc le fichier est reconnu comme un truc python par à peu près tout ce qui est susceptible de l'ouvrir proprement, est-ce que mettre plusieurs lignes spécifiques à un éditeur apportent réellement un plus, et si oui, lequel ?

Vu que j'n'utilise pas Emacs, et que de toute façon mon .pyrc n'a pas nécessairement vocation à être souvent ouvert par un éditeur en particulier, je n'pense pas que ce soit la peine de faire de la conf' spécifique, mais ça pourrait éventuellement être intéressant que j'sache ça pour d'autres fichiers.

(D'ailleurs, en parlant du « # coding: utf-8 », il me semblait avoir lu (sur ce topic, justement, en plus) que les trucs bizarres genre « -*- » que les gens mettent souvent dans leur déclaration d'encodage étaient spécialement destinés à ce que le commentaire soit lu d'une certaine manière par Emacs… ça sert vraiment ou pas, du coup ?)

HP · Le 26/09/2011, à 21:47

Version condensée :

;; -*- mode: Lisp; fill-column: 75; comment-column: 50; -*-

tirée de la doc… donc, ça doit fonctionner, par contre, je ne m'en sers pas ainsi… donc, j'en sais rien.

Pylades · Le 26/09/2011, à 21:50

@ ArkSeth :
(Ça ne sert strictement à rien, Emacs est sensé être capable de deviner tout seul l’encodage, comme tout éditeur de texte qui se respecte.)
(En fait ça sert juste à indiquer ce qui va advenir de l’encodage si on sort du codeset actuel ; mais c’est rarement spécifique à un fichier, ça…)

Dernière modification par Πυλάδης (Le 26/09/2011, à 21:50)

HP · Le 26/09/2011, à 21:52

ArkSeth a écrit :

(D'ailleurs, en parlant du « # coding: utf-8 », il me semblait avoir lu (sur ce topic, justement, en plus) que les trucs bizarres genre « -*- » que les gens mettent souvent dans leur déclaration d'encodage étaient spécialement destinés à ce que le commentaire soit lu d'une certaine manière par Emacs…

Je ne pense pas… en Python, python se sert de çà :

# -*- coding: utf-8 -*-

c'est très bien expliqué pourquoi et comment dans un PEP quelconque… de toute façon, il est nécessaire et indispensable d'annoncer l'encodage d'un fichier texte, ça devrait sembler évident pour tout le monde ; emacs le comprend, lui aussi, même si il peut s'en passer… mais alors, il va certainement essayer de bosser avec l'encodage par défaut défini par l'utilisateur ; le résultat n'est donc pas garanti.

HP · Le 26/09/2011, à 21:53

Πυλάδης a écrit :

(Ça ne sert strictement à rien, Emacs est sensé être capable de deviner tout seul l’encodage, comme tout éditeur de texte qui se respecte.)

Le divination d'encodage… bien ! Un concept amusant…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#376 Le 26/09/2011, à 19:54

Re : /* Topic des codeurs [6] */

#377 Le 26/09/2011, à 19:55

Re : /* Topic des codeurs [6] */

#378 Le 26/09/2011, à 20:01

Re : /* Topic des codeurs [6] */

#379 Le 26/09/2011, à 20:04

Re : /* Topic des codeurs [6] */

#380 Le 26/09/2011, à 20:11

Re : /* Topic des codeurs [6] */

#381 Le 26/09/2011, à 20:12

Re : /* Topic des codeurs [6] */

#382 Le 26/09/2011, à 20:14

Re : /* Topic des codeurs [6] */

#383 Le 26/09/2011, à 20:15

Re : /* Topic des codeurs [6] */

#384 Le 26/09/2011, à 20:29

Re : /* Topic des codeurs [6] */

#385 Le 26/09/2011, à 20:37

Re : /* Topic des codeurs [6] */

#386 Le 26/09/2011, à 21:00

Re : /* Topic des codeurs [6] */

#387 Le 26/09/2011, à 21:05

Re : /* Topic des codeurs [6] */

#388 Le 26/09/2011, à 21:12

Re : /* Topic des codeurs [6] */

#389 Le 26/09/2011, à 21:13

Re : /* Topic des codeurs [6] */

#390 Le 26/09/2011, à 21:26

Re : /* Topic des codeurs [6] */

#391 Le 26/09/2011, à 21:32

Re : /* Topic des codeurs [6] */

#392 Le 26/09/2011, à 21:39

Re : /* Topic des codeurs [6] */

#393 Le 26/09/2011, à 21:40

Re : /* Topic des codeurs [6] */

#394 Le 26/09/2011, à 21:41

Re : /* Topic des codeurs [6] */

#395 Le 26/09/2011, à 21:45

Re : /* Topic des codeurs [6] */

#396 Le 26/09/2011, à 21:45

Re : /* Topic des codeurs [6] */

#397 Le 26/09/2011, à 21:47

Re : /* Topic des codeurs [6] */

#398 Le 26/09/2011, à 21:50

Re : /* Topic des codeurs [6] */

#399 Le 26/09/2011, à 21:52

Re : /* Topic des codeurs [6] */

#400 Le 26/09/2011, à 21:53

Re : /* Topic des codeurs [6] */

Pied de page des forums