/* Topic des codeurs couche-tard [2] */

cm-t · Le 12/12/2010, à 16:25

'Plop && HDP

Pylades · Le 12/12/2010, à 16:31

grim7reaper a écrit :

@Pylade
char vi[PATH_MAX];
C'est mieux (même si tu dois définir PATH_MAX à la main, vu que POSIX ne garantis pas sa présence, c'est toujours mieux qu'une constante magique).
Sinon il y a bien _PC_PATH_MAX, mais je ne sais pas où elle se situe en terme de standard.
[…]

J'ai dit que c'était encore crado, hein !
Et puis comme PATH_MAX n'est pas garanti, ce n'est magique…

grim7reaper · Le 12/12/2010, à 16:32

Pylade a écrit :

Et puis comme PATH_MAX n'est pas garanti, ce n'est magique…

Gné !?

Pylades · Le 12/12/2010, à 16:33

Ben on n'est pas sûr que PATH_MAX soit défini, donc il va falloir trouver une meilleure solution…

Rolinh · Le 12/12/2010, à 16:34

ArkSeth a écrit :

Avec ton zsh, ça t'arrive bien quand même de temps en temps de lancer parted, python, ou un autre interpréteur de commandes dynamique de temps en temps, non ? Là ce serait pareil, mais avec un truc dédié à (et donc optimisé pour) la gestion de fichiers

oui, ça m'arrive évidemment

ArkSeth a écrit :

J'ai fadrienn (et j'ai un serveur web sur fadreils aussi au cas où).

Connais pas. Malheureusement, je n'ai pas trop le temps juste maintenant. Je suis à la bourre pour un TP sur les réseaux de Petri colorés (modélisation d'un OS mobile... C'est vraiment atroce en Petri!!). Mais je ne t'oublies pas pour autant

@Pylade: pense aux macros Notamment ça.

EDIT: j'ai mis trop de temps à répondre ^^
mais visiblement, j'ai tout de suite buté sur la même chose que grim7reaper...

Dernière modification par Rolinh (Le 12/12/2010, à 16:36)

grim7reaper · Le 12/12/2010, à 16:34

@Pylade :

grim7reaper a écrit :

@Pylade
char vi[PATH_MAX];
C'est mieux (même si tu dois définir PATH_MAX à la main, vu que POSIX ne garantis pas sa présence, c'est toujours mieux qu'une constante magique).[…]

@Rolinh : j'en suis arrivé à la même conclusion que dans ton lien. POSIX s'est chié dessus sur ce coup-là (il n'exige pas les constante mais donne des fonctions qui se basent dessus…)

Dernière modification par grim7reaper (Le 12/12/2010, à 16:39)

Elzen · Le 12/12/2010, à 16:39

Pylade a écrit :

Ben on n'est pas sûr que PATH_MAX soit défini, donc il va falloir trouver une meilleure solution…

#ifndef ?

Rolinh a écrit :

Connais pas.

fadrienn

grim7reaper · Le 12/12/2010, à 16:40

@ArkSeth : ouais, c'est plus ou moins à ça que je pensais

Pylades · Le 12/12/2010, à 17:00

Bon, je vais peut-être faire comme ça, mais RMS ne va pas aimer. Selon lui, je devrais accepter n'importe quelle longueur…

grim7reaper · Le 12/12/2010, à 17:12

Tu peux faire en sorte d'accepter n'importe quelle longueur si tu veux, mais le fait est que getcwd renvoie une chaîne dont la taille est bornée donc ça n'a que peu d'intérêt ici.

Pylades · Le 12/12/2010, à 17:37

Oui, mais si cette valeur est trop petite, errno vaut ERANGE, et du coup tu peux allouer un tampon plus grand.

Et phoque :

mkdir: ne peut créer le répertoire `longpath000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001': Nom de fichier trop long

grim7reaper · Le 12/12/2010, à 17:43

Pylade a écrit :

Et phoque :

mkdir: ne peut créer le répertoire `longpath000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001': Nom de fichier trop long

Elzen · Le 12/12/2010, à 17:47

Hmm, comment on fait une liste de diff, déjà ?

J'ai fait un espace de documents sur mon site pour que mon groupe mette les documents pour le projet annuel, mais pour le cas où j'ai besoin de leur envoyer un mail, ç't'un peu naze de devoir réécrire toutes les adresses. J'aimerais bien un truc genre projet@fadrienn.irlnc.org, qui renvoie le mail vers chacune de nos messageries.

Pylades · Le 12/12/2010, à 17:58

Het, tshirtman, ça existe les boucles do while en Python ? Sinon, existe-t-il une manière propre de les émuler ?

compte supprimé · Le 12/12/2010, à 18:04

i = 1
while i != 0 or <conditions>:
    <code de la boucle>
    i = 0

:]

helly · Le 12/12/2010, à 18:09

Une manière propre on a dit !

compte supprimé · Le 12/12/2010, à 18:15

Mais, c'est une manière propre

grim7reaper · Le 12/12/2010, à 18:17

J'aime pas les boucles do while.
Je trouve ça contre nature de forcer le passage dans le corps de la boucle au moins une fois (en plus c'est moins lisible, faut descendre en bas pour voir la condition).
Mais bon, c'est un avis totalement subjectif.

The Uploader · Le 12/12/2010, à 18:23

forcer le passage dans le corps de la boucle au moins une fois

Pourtant parfois j'en ai eu besoin quelques (rares) fois..
Mais ça peut vite tourner au bordel.

Pylades · Le 12/12/2010, à 18:23

#!/usr/bin/env python3

import os, sys

try:
    while (True):
        sys.stdout.write('clfb: ' + os.getcwd().split('/')[-1] + '> ')
        try:
            vi = input()
        except EOFError:
            break
        os.chdir(vi)
    print()

except KeyboardInterrupt:
    print()
    sys.exit(130)

grim7reaper · Le 12/12/2010, à 18:27

The Uploader a écrit :

forcer le passage dans le corps de la boucle au moins une fois
Pourtant parfois j'en ai eu besoin quelques (rares) fois..
Mais ça peut vite tourner au bordel.

Moi jamais, je me débrouille toujours en initialisant bien mes variables et en définissant mes conditions d'itérations.

@Pylade : tu pars sur du Python finalement ?

xapantu · Le 12/12/2010, à 18:27

Je me pose une question (en C) :

if(pointeur)

est égal à :

if(pointeur != NULL)

?

Pylades · Le 12/12/2010, à 18:32

grim7reaper a écrit :

The Uploader a écrit :
grim7reaper a écrit :
forcer le passage dans le corps de la boucle au moins une fois
Pourtant parfois j'en ai eu besoin quelques (rares) fois..
Mais ça peut vite tourner au bordel.
Moi jamais, je me débrouille toujours en initialisant bien mes variables et en définissant mes conditions d'itérations.

Des fois je trouve ça plus élégant, par exemple dans l'embryon de code que j'ai posté un peu plus tôt.

grim7reaper a écrit :

@Pylade : tu pars sur du Python finalement ?

Je ne sais pas. J'hésite encore. Je vais attendre de voir ce que donne readline pour me décider.

xapantu a écrit :

Je me pose une question (en C) :
if(pointeur)
est égal à :
if(pointeur != NULL)
?

Dans la norme, rien ne garantit que NULL vaut 0 ; mais dans les faits, c'est toujours le cas.
Donc oui, c'est équivalent.

xapantu · Le 12/12/2010, à 18:33

ok, merci

grim7reaper · Le 12/12/2010, à 18:38

Pylade a écrit :

grim7reaper a écrit :
Moi jamais, je me débrouille toujours en initialisant bien mes variables et en définissant mes conditions d'itérations.
Des fois je trouve ça plus élégant, par exemple dans l'embryon de code que j'ai posté un peu plus tôt.

Bah forcément, ta condition est moisie donc tu te rattrapes comme tu peux .
Sérieusement, c'est quoi cette logique de quitter le programme sur l'absence de '\n' ?

Dans la norme, rien ne garantit que NULL vaut 0 ; mais dans les faits, c'est toujours le cas.
Donc oui, c'est équivalent.

Je crois que c'est toujours définis pour valoir faux dans un test (mais j'avoue que j'ai la flemme de vérifier).

Dernière modification par grim7reaper (Le 12/12/2010, à 18:39)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2251 Le 12/12/2010, à 16:25

Re : /* Topic des codeurs couche-tard [2] */

#2252 Le 12/12/2010, à 16:31

Re : /* Topic des codeurs couche-tard [2] */

#2253 Le 12/12/2010, à 16:32

Re : /* Topic des codeurs couche-tard [2] */

#2254 Le 12/12/2010, à 16:33

Re : /* Topic des codeurs couche-tard [2] */

#2255 Le 12/12/2010, à 16:34

Re : /* Topic des codeurs couche-tard [2] */

#2256 Le 12/12/2010, à 16:34

Re : /* Topic des codeurs couche-tard [2] */

#2257 Le 12/12/2010, à 16:39

Re : /* Topic des codeurs couche-tard [2] */

#2258 Le 12/12/2010, à 16:40

Re : /* Topic des codeurs couche-tard [2] */

#2259 Le 12/12/2010, à 17:00

Re : /* Topic des codeurs couche-tard [2] */

#2260 Le 12/12/2010, à 17:12

Re : /* Topic des codeurs couche-tard [2] */

#2261 Le 12/12/2010, à 17:37

Re : /* Topic des codeurs couche-tard [2] */

#2262 Le 12/12/2010, à 17:43

Re : /* Topic des codeurs couche-tard [2] */

#2263 Le 12/12/2010, à 17:47

Re : /* Topic des codeurs couche-tard [2] */

#2264 Le 12/12/2010, à 17:58

Re : /* Topic des codeurs couche-tard [2] */

#2265 Le 12/12/2010, à 18:04

Re : /* Topic des codeurs couche-tard [2] */

#2266 Le 12/12/2010, à 18:09

Re : /* Topic des codeurs couche-tard [2] */

#2267 Le 12/12/2010, à 18:15

Re : /* Topic des codeurs couche-tard [2] */

#2268 Le 12/12/2010, à 18:17

Re : /* Topic des codeurs couche-tard [2] */

#2269 Le 12/12/2010, à 18:23

Re : /* Topic des codeurs couche-tard [2] */

#2270 Le 12/12/2010, à 18:23

Re : /* Topic des codeurs couche-tard [2] */

#2271 Le 12/12/2010, à 18:27

Re : /* Topic des codeurs couche-tard [2] */

#2272 Le 12/12/2010, à 18:27

Re : /* Topic des codeurs couche-tard [2] */

#2273 Le 12/12/2010, à 18:32

Re : /* Topic des codeurs couche-tard [2] */

#2274 Le 12/12/2010, à 18:33

Re : /* Topic des codeurs couche-tard [2] */

#2275 Le 12/12/2010, à 18:38

Re : /* Topic des codeurs couche-tard [2] */

Pied de page des forums