Un chemin relatif marche très bien pour ./test, évidemment.
Certes, il n'en demeure pas moins qu'il est maladroit de donner à un exe perso le nom d'une commande shell ou d'un exe des chemins classiques (/bin /usr/bin, /usr/local/bin...), je doute que tu me contredises sur ce point.
L'appeler essai serait moins risqué, et le problème de l'OP ne se serait pas produit...
A+ JF
Nicolas George a écrit :
Un chemin relatif marche très bien pour ./test, évidemment.
Certes, il n'en demeure pas moins qu'il est maladroit de donner à un exe
perso le nom d'une commande shell ou d'un exe des chemins classiques
(/bin /usr/bin, /usr/local/bin...), je doute que tu me contredises sur
ce point.
L'appeler essai serait moins risqué, et le problème de l'OP ne se serait
pas produit...
Un chemin relatif marche très bien pour ./test, évidemment.
Certes, il n'en demeure pas moins qu'il est maladroit de donner à un exe perso le nom d'une commande shell ou d'un exe des chemins classiques (/bin /usr/bin, /usr/local/bin...), je doute que tu me contredises sur ce point.
L'appeler essai serait moins risqué, et le problème de l'OP ne se serait pas produit...
A+ JF
Nicolas George
Cumbalero wrote in message <4a22d2af$0$21843$:
Certes, il n'en demeure pas moins qu'il est maladroit de donner à un exe perso le nom d'une commande shell ou d'un exe des chemins classiques (/bin /usr/bin, /usr/local/bin...)
Ce serait valable pour un programme qu'on compte garder, mais c'est absolument sans importance pour un truc qui se limite à un test rapide.
L'appeler essai serait moins risqué, et le problème de l'OP ne se serait pas produit...
Pour ça, il aurait fallu avoir conscience du problème, et si ça avait été le cas, il n'y aurait pas eu de problème dès le début.
Cumbalero wrote in message <4a22d2af$0$21843$426a34cc@news.free.fr>:
Certes, il n'en demeure pas moins qu'il est maladroit de donner à un exe
perso le nom d'une commande shell ou d'un exe des chemins classiques
(/bin /usr/bin, /usr/local/bin...)
Ce serait valable pour un programme qu'on compte garder, mais c'est
absolument sans importance pour un truc qui se limite à un test rapide.
L'appeler essai serait moins risqué, et le problème de l'OP ne se serait
pas produit...
Pour ça, il aurait fallu avoir conscience du problème, et si ça avait été le
cas, il n'y aurait pas eu de problème dès le début.
Certes, il n'en demeure pas moins qu'il est maladroit de donner à un exe perso le nom d'une commande shell ou d'un exe des chemins classiques (/bin /usr/bin, /usr/local/bin...)
Ce serait valable pour un programme qu'on compte garder, mais c'est absolument sans importance pour un truc qui se limite à un test rapide.
L'appeler essai serait moins risqué, et le problème de l'OP ne se serait pas produit...
Pour ça, il aurait fallu avoir conscience du problème, et si ça avait été le cas, il n'y aurait pas eu de problème dès le début.
Cumbalero
Nicolas George a écrit :
Ce serait valable pour un programme qu'on compte garder
J'ai juste dit "maladroit". essai ou mon_test et on n'en parle plus.
Pour ça, il aurait fallu avoir conscience du problème
En l'occurrence, s'il l'avait appelé essai, le fait de taper essai dans sa ligne de commande lui aurait renvoyé un bash: essai : program not found assez explicite il me semble.
Je n'ai jamais eu le moindre cours de programmation, mais lors mes cours d'admin , le fait de ne pas nommer un exe avec un nom possiblement utilisé par le système ou ne pas mettre . en tête du PATH (voire ne pas le mettre du tout) font partie des bonnes pratiques.
A+ JF
Nicolas George a écrit :
Ce serait valable pour un programme qu'on compte garder
J'ai juste dit "maladroit". essai ou mon_test et on n'en parle plus.
Pour ça, il aurait fallu avoir conscience du problème
En l'occurrence, s'il l'avait appelé essai, le fait de taper essai dans
sa ligne de commande lui aurait renvoyé un bash: essai : program not
found assez explicite il me semble.
Je n'ai jamais eu le moindre cours de programmation, mais lors mes cours
d'admin , le fait de ne pas nommer un exe avec un nom possiblement
utilisé par le système ou ne pas mettre . en tête du PATH (voire ne pas
le mettre du tout) font partie des bonnes pratiques.
Ce serait valable pour un programme qu'on compte garder
J'ai juste dit "maladroit". essai ou mon_test et on n'en parle plus.
Pour ça, il aurait fallu avoir conscience du problème
En l'occurrence, s'il l'avait appelé essai, le fait de taper essai dans sa ligne de commande lui aurait renvoyé un bash: essai : program not found assez explicite il me semble.
Je n'ai jamais eu le moindre cours de programmation, mais lors mes cours d'admin , le fait de ne pas nommer un exe avec un nom possiblement utilisé par le système ou ne pas mettre . en tête du PATH (voire ne pas le mettre du tout) font partie des bonnes pratiques.
A+ JF
Nicolas George
Cumbalero wrote in message <4a22e183$0$17002$:
le fait de ne pas nommer un exe avec un nom possiblement utilisé par le système ou ne pas mettre
Ce que tu ne comprends toujours pas, c'est que s'il avait su (et s'était rappelé) que test était une commande du système, il n'aurait de toutes façons pas fait l'erreur.
Cumbalero wrote in message <4a22e183$0$17002$426a74cc@news.free.fr>:
le fait de ne pas nommer un exe avec un nom possiblement
utilisé par le système ou ne pas mettre
Ce que tu ne comprends toujours pas, c'est que s'il avait su (et s'était
rappelé) que test était une commande du système, il n'aurait de toutes
façons pas fait l'erreur.
le fait de ne pas nommer un exe avec un nom possiblement utilisé par le système ou ne pas mettre
Ce que tu ne comprends toujours pas, c'est que s'il avait su (et s'était rappelé) que test était une commande du système, il n'aurait de toutes façons pas fait l'erreur.
Cumbalero
Nicolas George a écrit :
Ce que tu ne comprends toujours pas
Mais si je l'ai compris, range ta condescendance pour une autre occasion.
Un simple man bash (ou ksh ou whateversh) l'aurait renseigné.
Et man est la première à connaitre.
man man étant la première à passer.
Maintenant, un mec qui veut programmer sous Unix mais qui ne connait pas test devrait lire quelques ko de docs, non?
A+ JF
Nicolas George a écrit :
Ce que tu ne comprends toujours pas
Mais si je l'ai compris, range ta condescendance pour une autre occasion.
Un simple man bash (ou ksh ou whateversh) l'aurait renseigné.
Et man est la première à connaitre.
man man étant la première à passer.
Maintenant, un mec qui veut programmer sous Unix mais qui ne connait pas
test devrait lire quelques ko de docs, non?
Un simple man bash (ou ksh ou whateversh) l'aurait renseigné.
Et pourquoi serait-il allé chercher dans le man s'il ne savait pas qu'il y avait quelque chose à chercher ?
Mais si je l'ai compris, range ta condescendance pour une autre occasion.
Je rangerai ma condescendance quand tu rangeras ta bêtise.
Olivier Miakinen
Le 31/05/2009 23:45, Nicolas George répondait à Cumbalero :
Un simple man bash (ou ksh ou whateversh) l'aurait renseigné.
Et pourquoi serait-il allé chercher dans le man s'il ne savait pas qu'il y avait quelque chose à chercher ?
Exact. Le simple fait de penser que la réponse puisse se trouver dans la man de bash voudrait dire qu'il connaît déjà la cause du problème, à savoir qu'il pourrait exister une commande « shell builtin » de même nom que son exécutable.
Qui plus est, je viens de vérifier dans le man de bash : cette info se trouve à la 4584e ligne (parmi 4924). Juste par curiosité, Cumbalero, tu as déjà lu du début à la fin les 4924 lignes du man bash ?
Mais si je l'ai compris, range ta condescendance pour une autre occasion.
Je rangerai ma condescendance quand tu rangeras ta bêtise.
Dites, tous les deux, ce n'est pas la peine d'en venir aux insultes quand même, hein !
-- Olivier Miakinen
Le 31/05/2009 23:45, Nicolas George répondait à Cumbalero :
Un simple man bash (ou ksh ou whateversh) l'aurait renseigné.
Et pourquoi serait-il allé chercher dans le man s'il ne savait pas qu'il y
avait quelque chose à chercher ?
Exact. Le simple fait de penser que la réponse puisse se trouver dans la
man de bash voudrait dire qu'il connaît déjà la cause du problème, à
savoir qu'il pourrait exister une commande « shell builtin » de même nom
que son exécutable.
Qui plus est, je viens de vérifier dans le man de bash : cette info se
trouve à la 4584e ligne (parmi 4924). Juste par curiosité, Cumbalero, tu
as déjà lu du début à la fin les 4924 lignes du man bash ?
Mais si je l'ai compris, range ta condescendance pour une autre occasion.
Je rangerai ma condescendance quand tu rangeras ta bêtise.
Dites, tous les deux, ce n'est pas la peine d'en venir aux insultes
quand même, hein !
Le 31/05/2009 23:45, Nicolas George répondait à Cumbalero :
Un simple man bash (ou ksh ou whateversh) l'aurait renseigné.
Et pourquoi serait-il allé chercher dans le man s'il ne savait pas qu'il y avait quelque chose à chercher ?
Exact. Le simple fait de penser que la réponse puisse se trouver dans la man de bash voudrait dire qu'il connaît déjà la cause du problème, à savoir qu'il pourrait exister une commande « shell builtin » de même nom que son exécutable.
Qui plus est, je viens de vérifier dans le man de bash : cette info se trouve à la 4584e ligne (parmi 4924). Juste par curiosité, Cumbalero, tu as déjà lu du début à la fin les 4924 lignes du man bash ?
Mais si je l'ai compris, range ta condescendance pour une autre occasion.
Je rangerai ma condescendance quand tu rangeras ta bêtise.
Dites, tous les deux, ce n'est pas la peine d'en venir aux insultes quand même, hein !
-- Olivier Miakinen
Jacques Lav!gnotte
Olivier Miakinen a écrit :
Dites, tous les deux, ce n'est pas la peine d'en venir aux insultes quand même, hein !
