Il y a quelques jours (quelques semaines) le vieux windowsien que je
suis s'est décidé à franchir le pas : j'ai installé sur mon PC une Linux
Mandrake 9.1 ... (je découvre ce monde Linux, et je vais continuer à
découvrir !) ... jusque là, rien que de très normal ... sauf que ...
Je me pose une question : est-il vraiment indispensable d'avoir recours
à une console pour taper de vieilles commandes à la mimine ? alors que
l'on peut faire la même chose en cliquant sur de jolies icones ?
Cela me fait penser à ces vieux informaticiens que j'ai cotoyé quand
j'ai découvert l'informatique, qui employaient des termes
incompréhensible, histoire de montrer que, eux avaient le savoir ...
comme s'ils avaient peur qu'en transmettant leurs connaissances, on leur
pique leur place ...
Ne me faites pas dire ce que je viens de dire !!! ;-)
Jusqu'à ce jour, chaque fois que j'ai posé une question, j'ai eu une
réponse qui m'a permis de résoudre le problème que je rencontrais ...
mais c'était pratiquement tout le temps en m'indiquant des commandes
ressemblant à du DOS préhistorique (genre "si tu veux installer des
logiciels, tu vas dans une console et tu tapes urpmi" plutot que de me
dire "va dans le panneau de controle mandrake et cliques sur rpmdrake
installation de logiciels")
C'est quoi ? la finesse qui m'aurait échappé ? et qui devrait m'inciter
à utiliser le mode console plus souvent ?
Allez !!
Sans rancune !!
Je vous souhaite une bonne année 2004 à tous !!
Le concept derrière le `ls *.zip`, c'est pour éviter que ça marche si un fichier a un nom avec des espaces ?
:-) Ca me rapelle quelque chose...
"Je te donne trois essais, tu y arriveras peut-être."
René Domergue
A l'eternel problème des interfaces textuelles et graphiques !!!
Sans parler de la gestion d'un système, qui pour moi ne peut être faite correctement et complèment qu'en "ligne de commande" et en "scrip", passons à un logiciel de gestion commerciale.
Est-il réellement plus rapide de saisir des lignes de commandes de ventes avec un logiciel nous obligeant à cliquer à droite et à gauche à tout bout de champs. Est-il réellement plus convivial d'être toujours obligé de fixer l'écran pour s'avoir où se trouve ce satané curseur avant de valider une ligne.
Pour moi, il n'existe pas d'interface graphique utilisable en "production" intensive (Maintenance des systèmes, Saisie des écritures comptables, Saisie des ligne de commandes). Les interfaces graphiques peuvent marcher pour les produits d'analyse de données (Tableau de bord, Statistiques, Simulations d'activitées, ...) où le travail est moins répétitif.
A l'eternel problème des interfaces textuelles et graphiques !!!
Sans parler de la gestion d'un système, qui pour moi ne peut être faite
correctement et complèment qu'en "ligne de commande" et en "scrip", passons
à un logiciel de gestion commerciale.
Est-il réellement plus rapide de saisir des lignes de commandes de ventes
avec un logiciel nous obligeant à cliquer à droite et à gauche à tout bout
de champs. Est-il réellement plus convivial d'être toujours obligé de fixer
l'écran pour s'avoir où se trouve ce satané curseur avant de valider une
ligne.
Pour moi, il n'existe pas d'interface graphique utilisable en "production"
intensive (Maintenance des systèmes, Saisie des écritures comptables,
Saisie des ligne de commandes). Les interfaces graphiques peuvent marcher
pour les produits d'analyse de données (Tableau de bord, Statistiques,
Simulations d'activitées, ...) où le travail est moins répétitif.
A l'eternel problème des interfaces textuelles et graphiques !!!
Sans parler de la gestion d'un système, qui pour moi ne peut être faite correctement et complèment qu'en "ligne de commande" et en "scrip", passons à un logiciel de gestion commerciale.
Est-il réellement plus rapide de saisir des lignes de commandes de ventes avec un logiciel nous obligeant à cliquer à droite et à gauche à tout bout de champs. Est-il réellement plus convivial d'être toujours obligé de fixer l'écran pour s'avoir où se trouve ce satané curseur avant de valider une ligne.
Pour moi, il n'existe pas d'interface graphique utilisable en "production" intensive (Maintenance des systèmes, Saisie des écritures comptables, Saisie des ligne de commandes). Les interfaces graphiques peuvent marcher pour les produits d'analyse de données (Tableau de bord, Statistiques, Simulations d'activitées, ...) où le travail est moins répétitif.
Rémi Pannequin
Michel BILLAUD a écrit :
Ah, l'informatique se met à automatiser le traitement de l'information, on aura tout vu.
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je vérifie.
-- Rémi
Michel BILLAUD a écrit :
Ah, l'informatique se met à automatiser le traitement de l'information,
on aura tout vu.
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la
concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je
vérifie.
Ah, l'informatique se met à automatiser le traitement de l'information, on aura tout vu.
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je vérifie.
-- Rémi
george
Rémi Pannequin , dans le message , a écrit :
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je vérifie.
-tique est un suffixe tout à fait courant, en particulier pour parler de domaines de connaissance : acoustique, dialectique, mathématique, etc. Le TLF donne : « 1962 (Terme inventé par Ph. Dreyfus d'apr. GILB. 1971); 1966, 16 nov. (Le Monde, ibid.). Dér. de informat(ion)*; suff. -ique* »
Rémi Pannequin , dans le message
<pan.2004.01.12.20.23.38.250851@laposte.net>, a écrit :
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la
concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je
vérifie.
-tique est un suffixe tout à fait courant, en particulier pour parler de
domaines de connaissance : acoustique, dialectique, mathématique, etc.
Le TLF donne : « 1962 (Terme inventé par Ph. Dreyfus d'apr. GILB.
1971); 1966, 16 nov. (Le Monde, ibid.). Dér. de informat(ion)*; suff.
-ique* »
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je vérifie.
-tique est un suffixe tout à fait courant, en particulier pour parler de domaines de connaissance : acoustique, dialectique, mathématique, etc. Le TLF donne : « 1962 (Terme inventé par Ph. Dreyfus d'apr. GILB. 1971); 1966, 16 nov. (Le Monde, ibid.). Dér. de informat(ion)*; suff. -ique* »
Rémi Pannequin
Nicolas George a écrit :
Rémi Pannequin , dans le message , a écrit :
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je vérifie.
-tique est un suffixe tout à fait courant, en particulier pour parler de domaines de connaissance : acoustique, dialectique, mathématique, etc. Le TLF donne : « 1962 (Terme inventé par Ph. Dreyfus d'apr. GILB. 1971); 1966, 16 nov. (Le Monde, ibid.). Dér. de informat(ion)*; suff. -ique* »
C'est bien ce que je pensait... Merci pour la référence !
-- Rémi
Nicolas George a écrit :
Rémi Pannequin , dans le message
<pan.2004.01.12.20.23.38.250851@laposte.net>, a écrit :
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la
concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je
vérifie.
-tique est un suffixe tout à fait courant, en particulier pour parler de
domaines de connaissance : acoustique, dialectique, mathématique, etc.
Le TLF donne : « 1962 (Terme inventé par Ph. Dreyfus d'apr. GILB.
1971); 1966, 16 nov. (Le Monde, ibid.). Dér. de informat(ion)*; suff.
-ique* »
C'est bien ce que je pensait... Merci pour la référence !
Aspropos, est-il vrai que l'étymologie de "informatique" revient à la concaténation de "information" et "automatique" ?
Personnellement, je n'en crois rien, mais on m'a dit que, alors, je vérifie.
-tique est un suffixe tout à fait courant, en particulier pour parler de domaines de connaissance : acoustique, dialectique, mathématique, etc. Le TLF donne : « 1962 (Terme inventé par Ph. Dreyfus d'apr. GILB. 1971); 1966, 16 nov. (Le Monde, ibid.). Dér. de informat(ion)*; suff. -ique* »
C'est bien ce que je pensait... Merci pour la référence !
-- Rémi
Patrice Karatchentzeff
Floyd writes:
exemple, 40 fichiers zip. A décompresser à la main, avec winzip ou équivalent Linux, tu te tape les fichiers les uns après les autres, un peu pénible. Alors qu'en ligne de commande, un "for i in `ls *.zip`; do unzip $i; done;" te les décompresses automatiquement...
exemple, 40 fichiers zip. A décompresser à la main, avec winzip ou
équivalent Linux, tu te tape les fichiers les uns après les autres,
un peu pénible. Alors qu'en ligne de commande, un "for i in `ls
*.zip`; do unzip $i; done;" te les décompresses automatiquement...
exemple, 40 fichiers zip. A décompresser à la main, avec winzip ou équivalent Linux, tu te tape les fichiers les uns après les autres, un peu pénible. Alors qu'en ligne de commande, un "for i in `ls *.zip`; do unzip $i; done;" te les décompresses automatiquement...
Patrice Karatchentzeff , dans le message , a écrit :
Un unzip *.zip ne fonctionne pas ?
Non, de même que tar -xf *.tar ne marcherait pas : le premier argument est pris comme nom d'archive, les suivants comme des membres de l'archive à extraire.
Patrice Karatchentzeff , dans le message
<87y8scyekj.fsf@belledonne.chartreuse.fr>, a écrit :
Un unzip *.zip ne fonctionne pas ?
Non, de même que tar -xf *.tar ne marcherait pas : le premier argument
est pris comme nom d'archive, les suivants comme des membres de
l'archive à extraire.
Patrice Karatchentzeff , dans le message , a écrit :
Un unzip *.zip ne fonctionne pas ?
Non, de même que tar -xf *.tar ne marcherait pas : le premier argument est pris comme nom d'archive, les suivants comme des membres de l'archive à extraire.
Pascal C.
Le Sun, 11 Jan 2004 22:07:08 +0100, Msieur Fernand a écrit :
[...] Je me pose une question : est-il vraiment indispensable d'avoir recours à une console pour taper de vieilles commandes à la mimine ? alors que l'on peut faire la même chose en cliquant sur de jolies icones ?
La ligne de commande n'est pas une vieillerie, bien au contraire, je trouve qu'elle n'a jamais été aussi pratique.
Je ne crois pas que ce soit les "jolis icônes" contre la "vieille ligne de commande". Les possibilités ne sont pas les mêmes.
J'ai commencé avec de la ligne de commande, puis j'ai découvert les interfaces graphiques (GEM, Windows 1.0, etc.), mais je n'ai jamais abandonné pour autant. J'apprécie de pouvoir faire des opérations simples en cliquant (par exemple sélectionner visuellement une partie des fichiers d'un répertoire pour les recopier ailleurs ou les effacer), mais l'interface graphique est très difficile à automatiser, et ne permet pas un nombre important de choix, sous peine de fenêtres trop chargées en options.
Alors il faut recourir à un autre type d'interface, en l'occurrence la ligne de commmande.
J'utilise les deux, et ça m'ennuierai beaucoup d'avoir l'un et pas l'autre. D'ailleurs, sous Windows, la nullité de l'interface ligne de commande m'exaspère depuis de nombreuses années !
Autre avantage de la ligne de commande: quand l'interface graphique est plantée, on peut reprendre la main. Alors qu'avec Windows NT/2000, c'est foutu! Dans le même ordre d'idée, on peut faire tourner un PC sans l'IHM si elle n'est pas nécessaire (par exemple pour un serveur web). On économise alors de la mémoire, du CPU, des process...
[...] Ne me faites pas dire ce que je viens de dire !!! ;-) Jusqu'à ce jour, chaque fois que j'ai posé une question, j'ai eu une réponse qui m'a permis de résoudre le problème que je rencontrais ... mais c'était pratiquement tout le temps en m'indiquant des commandes ressemblant à du DOS préhistorique (genre "si tu veux installer des logiciels, tu vas dans une console et tu tapes urpmi" plutot que de me dire "va dans le panneau de controle mandrake et cliques sur rpmdrake installation de logiciels")
Ah, autre avantage de la ligne de commande: on peut faire copier/coller d'une série de commandes, difficile à la souris!
Il est en outre plus facile de décrire les opérations en LdC que pour une IHM. D'autant que les IHM peuvent changer (Gnome/KDE, etc.). Un "cp" sera toujours le même alors que les manipulations de fichiers seront différents suivant le logiciel utilisé (Konqueror, Nautilus, etc.).
"urpmi" présente aussi l'avantage d'être plus fiable que l'outil graphique de Mandrake, et, là encore, de fournir une interface commune à toutes les plates-formes à base RPM. Imagine que la personne te dise comment faire sous Suse ou RedHat: "clique dans Sax"... Tu serais bien avancé!
Sache enfin que la philosophie Unix c'est plutôt de commencer à développer une application en ligne de commande très fiable (ex.: cdrecord pour graver les CD), puis ensuite seulement à mettre par dessus une IHM (xcdroast, G3B, etc.). Ceci donne des applications fiables, que l'on peut aisément automatiser par des scripts.
Sous Windows, c'est plutôt le contraire: on développe l'IHM et ensuite seulement l'application. On voit le résultat (et pas seulement chez MS, il n'y a qu'à voir comment les SSII développent sous Windows!).
Ce n'est pas une fatalité: dans une vie antérieure, je faisais du génie logiciel dans une boîte où le principe était un développement en couches: d'abord les services de base (couche servant aussi pour la portabilité), par-dessus des services de plus haut niveau, etc., puis la couche graphique de base (utilisant X/Motif ou Win32) puis une couche graphique de plus haut niveau, puis la couche applicative. Ainsi, les applications étaient très fiables, avec un taux de bugs réduits, et étaient fortement portables: des applications graphiques de 400.000 lignes, avec des IHM sophistiquées, se portaient d'Unix à Windows par simple recompilation... Il était en outre possible de "débrancher" l'interface graphique pour tourner en "batch", et ainsi automatiser les traitements, pour les faire tourner par exemple durant la nuit ou le week-end sans intervention humaine.
Piloter Word à partir de scripts VB c'est possible, mais pas simple et parfois aléatoire!
Conclusion: il faut les deux (batch + IHM) !!!
-- Pascal
Le Sun, 11 Jan 2004 22:07:08 +0100, Msieur Fernand a écrit :
[...]
Je me pose une question : est-il vraiment indispensable d'avoir recours à
une console pour taper de vieilles commandes à la mimine ? alors que l'on
peut faire la même chose en cliquant sur de jolies icones ?
La ligne de commande n'est pas une vieillerie, bien
au contraire, je trouve qu'elle n'a jamais été aussi
pratique.
Je ne crois pas que ce soit les "jolis icônes" contre la
"vieille ligne de commande". Les possibilités ne sont pas
les mêmes.
J'ai commencé avec de la ligne de commande, puis j'ai
découvert les interfaces graphiques (GEM, Windows 1.0, etc.),
mais je n'ai jamais abandonné pour autant. J'apprécie de
pouvoir faire des opérations simples en cliquant (par exemple
sélectionner visuellement une partie des fichiers d'un répertoire
pour les recopier ailleurs ou les effacer), mais l'interface
graphique est très difficile à automatiser, et ne permet
pas un nombre important de choix, sous peine de fenêtres
trop chargées en options.
Alors il faut recourir à un autre type d'interface, en
l'occurrence la ligne de commmande.
J'utilise les deux, et ça m'ennuierai beaucoup d'avoir
l'un et pas l'autre. D'ailleurs, sous Windows, la nullité
de l'interface ligne de commande m'exaspère depuis de
nombreuses années !
Autre avantage de la ligne de commande: quand l'interface
graphique est plantée, on peut reprendre la main. Alors
qu'avec Windows NT/2000, c'est foutu! Dans le même ordre
d'idée, on peut faire tourner un PC sans l'IHM si elle
n'est pas nécessaire (par exemple pour un serveur web).
On économise alors de la mémoire, du CPU, des process...
[...]
Ne me faites pas dire ce que je viens de dire !!! ;-) Jusqu'à ce jour,
chaque fois que j'ai posé une question, j'ai eu une réponse qui m'a
permis de résoudre le problème que je rencontrais ... mais c'était
pratiquement tout le temps en m'indiquant des commandes ressemblant à du
DOS préhistorique (genre "si tu veux installer des logiciels, tu vas dans
une console et tu tapes urpmi" plutot que de me dire "va dans le panneau
de controle mandrake et cliques sur rpmdrake installation de logiciels")
Ah, autre avantage de la ligne de commande:
on peut faire copier/coller d'une série de
commandes, difficile à la souris!
Il est en outre plus facile de décrire les opérations
en LdC que pour une IHM. D'autant que les IHM peuvent
changer (Gnome/KDE, etc.). Un "cp" sera toujours le même
alors que les manipulations de fichiers seront différents
suivant le logiciel utilisé (Konqueror, Nautilus, etc.).
"urpmi" présente aussi l'avantage d'être plus fiable
que l'outil graphique de Mandrake, et, là encore,
de fournir une interface commune à toutes les plates-formes
à base RPM. Imagine que la personne te dise comment faire
sous Suse ou RedHat: "clique dans Sax"... Tu serais bien
avancé!
Sache enfin que la philosophie Unix c'est plutôt de
commencer à développer une application en ligne de
commande très fiable (ex.: cdrecord pour graver les CD),
puis ensuite seulement à mettre par dessus une IHM
(xcdroast, G3B, etc.). Ceci donne des applications
fiables, que l'on peut aisément automatiser par des
scripts.
Sous Windows, c'est plutôt le contraire: on développe
l'IHM et ensuite seulement l'application. On voit le
résultat (et pas seulement chez MS, il n'y a qu'à voir
comment les SSII développent sous Windows!).
Ce n'est pas une fatalité: dans une vie antérieure,
je faisais du génie logiciel dans une boîte où le
principe était un développement en couches: d'abord
les services de base (couche servant aussi pour la
portabilité), par-dessus des services de plus haut
niveau, etc., puis la couche graphique de base
(utilisant X/Motif ou Win32) puis une couche
graphique de plus haut niveau, puis la couche
applicative. Ainsi, les applications étaient très
fiables, avec un taux de bugs réduits, et étaient
fortement portables: des applications graphiques
de 400.000 lignes, avec des IHM sophistiquées,
se portaient d'Unix à Windows par simple
recompilation... Il était en outre possible
de "débrancher" l'interface graphique pour tourner
en "batch", et ainsi automatiser les traitements,
pour les faire tourner par exemple durant la nuit
ou le week-end sans intervention humaine.
Piloter Word à partir de scripts VB c'est possible,
mais pas simple et parfois aléatoire!
Le Sun, 11 Jan 2004 22:07:08 +0100, Msieur Fernand a écrit :
[...] Je me pose une question : est-il vraiment indispensable d'avoir recours à une console pour taper de vieilles commandes à la mimine ? alors que l'on peut faire la même chose en cliquant sur de jolies icones ?
La ligne de commande n'est pas une vieillerie, bien au contraire, je trouve qu'elle n'a jamais été aussi pratique.
Je ne crois pas que ce soit les "jolis icônes" contre la "vieille ligne de commande". Les possibilités ne sont pas les mêmes.
J'ai commencé avec de la ligne de commande, puis j'ai découvert les interfaces graphiques (GEM, Windows 1.0, etc.), mais je n'ai jamais abandonné pour autant. J'apprécie de pouvoir faire des opérations simples en cliquant (par exemple sélectionner visuellement une partie des fichiers d'un répertoire pour les recopier ailleurs ou les effacer), mais l'interface graphique est très difficile à automatiser, et ne permet pas un nombre important de choix, sous peine de fenêtres trop chargées en options.
Alors il faut recourir à un autre type d'interface, en l'occurrence la ligne de commmande.
J'utilise les deux, et ça m'ennuierai beaucoup d'avoir l'un et pas l'autre. D'ailleurs, sous Windows, la nullité de l'interface ligne de commande m'exaspère depuis de nombreuses années !
Autre avantage de la ligne de commande: quand l'interface graphique est plantée, on peut reprendre la main. Alors qu'avec Windows NT/2000, c'est foutu! Dans le même ordre d'idée, on peut faire tourner un PC sans l'IHM si elle n'est pas nécessaire (par exemple pour un serveur web). On économise alors de la mémoire, du CPU, des process...
[...] Ne me faites pas dire ce que je viens de dire !!! ;-) Jusqu'à ce jour, chaque fois que j'ai posé une question, j'ai eu une réponse qui m'a permis de résoudre le problème que je rencontrais ... mais c'était pratiquement tout le temps en m'indiquant des commandes ressemblant à du DOS préhistorique (genre "si tu veux installer des logiciels, tu vas dans une console et tu tapes urpmi" plutot que de me dire "va dans le panneau de controle mandrake et cliques sur rpmdrake installation de logiciels")
Ah, autre avantage de la ligne de commande: on peut faire copier/coller d'une série de commandes, difficile à la souris!
Il est en outre plus facile de décrire les opérations en LdC que pour une IHM. D'autant que les IHM peuvent changer (Gnome/KDE, etc.). Un "cp" sera toujours le même alors que les manipulations de fichiers seront différents suivant le logiciel utilisé (Konqueror, Nautilus, etc.).
"urpmi" présente aussi l'avantage d'être plus fiable que l'outil graphique de Mandrake, et, là encore, de fournir une interface commune à toutes les plates-formes à base RPM. Imagine que la personne te dise comment faire sous Suse ou RedHat: "clique dans Sax"... Tu serais bien avancé!
Sache enfin que la philosophie Unix c'est plutôt de commencer à développer une application en ligne de commande très fiable (ex.: cdrecord pour graver les CD), puis ensuite seulement à mettre par dessus une IHM (xcdroast, G3B, etc.). Ceci donne des applications fiables, que l'on peut aisément automatiser par des scripts.
Sous Windows, c'est plutôt le contraire: on développe l'IHM et ensuite seulement l'application. On voit le résultat (et pas seulement chez MS, il n'y a qu'à voir comment les SSII développent sous Windows!).
Ce n'est pas une fatalité: dans une vie antérieure, je faisais du génie logiciel dans une boîte où le principe était un développement en couches: d'abord les services de base (couche servant aussi pour la portabilité), par-dessus des services de plus haut niveau, etc., puis la couche graphique de base (utilisant X/Motif ou Win32) puis une couche graphique de plus haut niveau, puis la couche applicative. Ainsi, les applications étaient très fiables, avec un taux de bugs réduits, et étaient fortement portables: des applications graphiques de 400.000 lignes, avec des IHM sophistiquées, se portaient d'Unix à Windows par simple recompilation... Il était en outre possible de "débrancher" l'interface graphique pour tourner en "batch", et ainsi automatiser les traitements, pour les faire tourner par exemple durant la nuit ou le week-end sans intervention humaine.
Piloter Word à partir de scripts VB c'est possible, mais pas simple et parfois aléatoire!
Conclusion: il faut les deux (batch + IHM) !!!
-- Pascal
Benjamin FRANCOIS
Patrice Karatchentzeff s'est exprimé en ces termes:
Floyd writes:
exemple, 40 fichiers zip. A décompresser à la main, avec winzip ou équivalent Linux, tu te tape les fichiers les uns après les autres, un peu pénible. Alors qu'en ligne de commande, un "for i in `ls *.zip`; do unzip $i; done;" te les décompresses automatiquement...
Un unzip *.zip ne fonctionne pas ?
Non. Par contre un find . -name "*.zip" -exec unzip {} ; oui.
-- When you have an efficient government, you have a dictatorship. -- Harry Truman
Patrice Karatchentzeff s'est exprimé en ces termes:
Floyd <mik-news@SPAMISLAMEacidspace.net> writes:
exemple, 40 fichiers zip. A décompresser à la main, avec winzip ou
équivalent Linux, tu te tape les fichiers les uns après les autres,
un peu pénible. Alors qu'en ligne de commande, un "for i in `ls
*.zip`; do unzip $i; done;" te les décompresses automatiquement...
Un unzip *.zip ne fonctionne pas ?
Non. Par contre un
find . -name "*.zip" -exec unzip {} ;
oui.
--
When you have an efficient government, you have a dictatorship.
-- Harry Truman
Patrice Karatchentzeff s'est exprimé en ces termes:
Floyd writes:
exemple, 40 fichiers zip. A décompresser à la main, avec winzip ou équivalent Linux, tu te tape les fichiers les uns après les autres, un peu pénible. Alors qu'en ligne de commande, un "for i in `ls *.zip`; do unzip $i; done;" te les décompresses automatiquement...
Un unzip *.zip ne fonctionne pas ?
Non. Par contre un find . -name "*.zip" -exec unzip {} ; oui.
-- When you have an efficient government, you have a dictatorship. -- Harry Truman
Gilles Berger Sabbatel
On Mon, 12 Jan 2004 11:22:33 +0100, Michel BILLAUD wrote:
alors que l'on peut faire la même chose en cliquant sur de jolies icones ?
et bien non, on ne peut pas. D'où l'intérêt de.
Là tu exagères (comme souvent, d'ailleurs)... On peut souvent. Pas toujours, et quand on peut, ce n'est pas toujours efficace...
Cela me fait penser à ces vieux informaticiens que j'ai cotoyé quand j'ai découvert l'informatique, qui employaient des termes incompréhensible, histoire de montrer que, eux avaient le savoir ...
Vous pensez que si les marins ne parlent pas de cordes et de ficelles, c'est juste pour emmerder les terriens ?
Bien trouvé... Mais il y a tellement de gens qui pensent que si les voileux parlent de bouts, de drisses, d'écoutes, d'aussières, etc, c'est par pur snobisme... En fait, je crois n'avoir compris l'intérêt de ce vocabulaire que le jour où je m'y suis mis... J'imagine le tableau sans cela : au près, par vent de force 7... Ordre du chef de bord : détend la corde de grand-voile... NOOOOOON!!!! PAS CELLE-LA!!!!.... CRRRAAAAC... Trop tard...
comme s'ils avaient peur qu'en transmettant leurs connaissances, on leur pique leur place ...
et vous vous imaginez qu'en parlant de ficelles au lieu de drisses, ça vous apprend quelque chose sur la navigation ?
Sans compter qu'il faut 5 ans après le bac pour former un ingénieur informaticien, alors...
C'est quoi ? la finesse qui m'aurait échappé ? et qui devrait m'inciter à utiliser le mode console plus souvent ?
C'est plus efficace, et beaucoup moins compliqué.
Souvent, en effet. Moi, par exemple, il y a un truc qui me gonfle avec mes enfants (9 à 14 ans) quand ils me demandent comment faire telle chose, mon premier réflexe est souvent d'appeler le logiciel depuis la ligne de commande (d'ailleurs, il arrive que le logiciel en question ne soit pas dans les menus). Après, pour essayer de me mettre à leur portée, je leur montre comment appeler le logiciel avec l'interface graphique - ou même je fais ce qu'il faut pour faire apparaître le logiciel dans les menus... Et après, je les retrouve toujours en train d'utiliser la ligne de commande! Vous allez voir qu'un de ces jours, je vais les retrouver en train de lire le manuel et de s'essayer à la programmation en shell... Pourvu que ce ne soit pas en csh! Je ferais peut-être bien de leur parler de Perl.
On Mon, 12 Jan 2004 11:22:33 +0100, Michel BILLAUD wrote:
alors que
l'on peut faire la même chose en cliquant sur de jolies icones ?
et bien non, on ne peut pas. D'où l'intérêt de.
Là tu exagères (comme souvent, d'ailleurs)... On peut souvent. Pas
toujours, et quand on peut, ce n'est pas toujours efficace...
Cela me fait penser à ces vieux informaticiens que j'ai cotoyé quand
j'ai découvert l'informatique, qui employaient des termes
incompréhensible, histoire de montrer que, eux avaient le savoir ...
Vous pensez que si les marins ne parlent pas de cordes et de ficelles,
c'est juste pour emmerder les terriens ?
Bien trouvé... Mais il y a tellement de gens qui pensent que si les
voileux parlent de bouts, de drisses, d'écoutes, d'aussières, etc, c'est
par pur snobisme... En fait, je crois n'avoir compris l'intérêt de ce
vocabulaire que le jour où je m'y suis mis... J'imagine le tableau sans
cela : au près, par vent de force 7... Ordre du chef de bord : détend
la corde de grand-voile... NOOOOOON!!!! PAS CELLE-LA!!!!....
CRRRAAAAC... Trop tard...
comme s'ils avaient peur qu'en transmettant leurs connaissances, on
leur pique leur place ...
et vous vous imaginez qu'en parlant de ficelles au lieu de drisses, ça
vous apprend quelque chose sur la navigation ?
Sans compter qu'il faut 5 ans après le bac pour former un ingénieur
informaticien, alors...
C'est quoi ? la finesse qui m'aurait échappé ? et qui devrait
m'inciter à utiliser le mode console plus souvent ?
C'est plus efficace, et beaucoup moins compliqué.
Souvent, en effet. Moi, par exemple, il y a un truc qui me gonfle avec
mes enfants (9 à 14 ans) quand ils me demandent comment faire telle
chose, mon premier réflexe est souvent d'appeler le logiciel depuis la
ligne de commande (d'ailleurs, il arrive que le logiciel en question ne
soit pas dans les menus). Après, pour essayer de me mettre à leur
portée, je leur montre comment appeler le logiciel avec l'interface
graphique - ou même je fais ce qu'il faut pour faire apparaître le
logiciel dans les menus... Et après, je les retrouve toujours en train
d'utiliser la ligne de commande! Vous allez voir qu'un de ces jours, je
vais les retrouver en train de lire le manuel et de s'essayer à la
programmation en shell... Pourvu que ce ne soit pas en csh! Je ferais
peut-être bien de leur parler de Perl.
On Mon, 12 Jan 2004 11:22:33 +0100, Michel BILLAUD wrote:
alors que l'on peut faire la même chose en cliquant sur de jolies icones ?
et bien non, on ne peut pas. D'où l'intérêt de.
Là tu exagères (comme souvent, d'ailleurs)... On peut souvent. Pas toujours, et quand on peut, ce n'est pas toujours efficace...
Cela me fait penser à ces vieux informaticiens que j'ai cotoyé quand j'ai découvert l'informatique, qui employaient des termes incompréhensible, histoire de montrer que, eux avaient le savoir ...
Vous pensez que si les marins ne parlent pas de cordes et de ficelles, c'est juste pour emmerder les terriens ?
Bien trouvé... Mais il y a tellement de gens qui pensent que si les voileux parlent de bouts, de drisses, d'écoutes, d'aussières, etc, c'est par pur snobisme... En fait, je crois n'avoir compris l'intérêt de ce vocabulaire que le jour où je m'y suis mis... J'imagine le tableau sans cela : au près, par vent de force 7... Ordre du chef de bord : détend la corde de grand-voile... NOOOOOON!!!! PAS CELLE-LA!!!!.... CRRRAAAAC... Trop tard...
comme s'ils avaient peur qu'en transmettant leurs connaissances, on leur pique leur place ...
et vous vous imaginez qu'en parlant de ficelles au lieu de drisses, ça vous apprend quelque chose sur la navigation ?
Sans compter qu'il faut 5 ans après le bac pour former un ingénieur informaticien, alors...
C'est quoi ? la finesse qui m'aurait échappé ? et qui devrait m'inciter à utiliser le mode console plus souvent ?
C'est plus efficace, et beaucoup moins compliqué.
Souvent, en effet. Moi, par exemple, il y a un truc qui me gonfle avec mes enfants (9 à 14 ans) quand ils me demandent comment faire telle chose, mon premier réflexe est souvent d'appeler le logiciel depuis la ligne de commande (d'ailleurs, il arrive que le logiciel en question ne soit pas dans les menus). Après, pour essayer de me mettre à leur portée, je leur montre comment appeler le logiciel avec l'interface graphique - ou même je fais ce qu'il faut pour faire apparaître le logiciel dans les menus... Et après, je les retrouve toujours en train d'utiliser la ligne de commande! Vous allez voir qu'un de ces jours, je vais les retrouver en train de lire le manuel et de s'essayer à la programmation en shell... Pourvu que ce ne soit pas en csh! Je ferais peut-être bien de leur parler de Perl.
