montrer des lignes de commandes : combien cela coute a peu pres, et comment opérer ?
40 réponses
Rakotomandimby Mihamina
Bonjour,
Dans le cadre d'une activité d'introduction à Linux, je souhaiterai
avoir un intervenant bien qualifié sous UNIX (plus presisément sous un
shell) pour faire une petite conférence d'environ 1 heure , 1,5 heure
pour montrer l'interet des CLI (command line interface) par rapport aux
cliquodromes.
L'auditoire sera une promotion d'etudiants en Informatique (premier
cycle universitaire).
L'essentiel de la préparation sera de trouver un maximum d'exemples
concrets (et interessants) ou l'on peut comparer l'efficacité de la CLI
par rapport au cliquodrome. Le clicodrome exemple sera bien sur le plus
celebre d'entre eux : MSWin. Et bien sur avoir reponse a toutes les
question des detracteurs des CLI qui seront eventuellement présents.
Ce genre d'intervention est-il courant (je ne pense pas), a combien
aurons-nous (Association) a payer ce type d'intervention ? a quels genre
de prestataires s'adresser ( S.A.P. ? :-P ) ?
Je ne peux pas assurer moi-meme ce genre d'intervention car je suis
moi-meme de bien faible niveau en adminnistration (je ne me sens pas a
la hauteur, quoi)
--
RKTMB - http://www.rktmb.org/Members/mihamina
Tél: + 33 2 38 76 43 65 (France)
Membre d'un L.U.G. à Orléans (Université)
Le Tue, 24 Aug 2004 19:10:05 +0200, Rakotomandimby Mihamina a écrit :
Bonjour,
Bonsoir,
(snip le descriptif)
Je ne peux pas assurer moi-meme ce genre d'intervention car je suis moi-meme de bien faible niveau en adminnistration (je ne me sens pas a la hauteur, quoi)
(Donnant une introduction à Linux, voici ce que j'applique)
Si le but est de montrer l'intéret de la CLI, le plus simple est de montrer des traitements par lots, genre renommer en "juin" tous les fichiers commençant par "mai", ou appliquer un chmod (ou un chown) bien senti à tous les fichiers sur un critère précis (date, etc.).
Il suffit alors de montrer que, pendant que les élèves cliquent à tout va, une ligne de commande "kivabien" résout le problème en quelques secondes.
De même, on peut montrer très facilement l'intérêt de placer les signes | , & , > et >> pour faire des opérations complexes, ou encore des outils comme write ou talk (sous Unix bien sur...).
Enfin, la plupart des serveurs fonctionnant *sans* interface graphique, l'apprentissage de la CLI est indispensable, de même que la gestion d'une machine à distance via SSH (avec les débutants, je me connecte sur une machine en root et puis je fais "eject cdrom". Effet garanti ;-)
Pour montrer tout cela, je pense, au vu de tes interventions sur différents forums, que tu as largement le niveau pour le faire toi-même. Le tout est de bien préparer son cours et de respirer un bon coup au début ;-)
-- Jerome, prof d'info à ses heures... "Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux. Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo." M. in fr.comp.os.linux.debats
Le Tue, 24 Aug 2004 19:10:05 +0200, Rakotomandimby Mihamina a écrit :
Bonjour,
Bonsoir,
(snip le descriptif)
Je ne peux pas assurer moi-meme ce genre d'intervention car je suis
moi-meme de bien faible niveau en adminnistration (je ne me sens pas a
la hauteur, quoi)
(Donnant une introduction à Linux, voici ce que j'applique)
Si le but est de montrer l'intéret de la CLI, le plus simple est de
montrer des traitements par lots, genre renommer en "juin" tous les
fichiers commençant par "mai", ou appliquer un chmod (ou un chown) bien
senti à tous les fichiers sur un critère précis (date, etc.).
Il suffit alors de montrer que, pendant que les élèves cliquent à tout
va, une ligne de commande "kivabien" résout le problème en quelques
secondes.
De même, on peut montrer très facilement l'intérêt de placer les
signes | , & , > et >> pour faire des opérations complexes, ou encore des
outils comme write ou talk (sous Unix bien sur...).
Enfin, la plupart des serveurs fonctionnant *sans* interface graphique,
l'apprentissage de la CLI est indispensable, de même que la gestion d'une
machine à distance via SSH (avec les débutants, je me connecte sur une
machine en root et puis je fais "eject cdrom". Effet garanti ;-)
Pour montrer tout cela, je pense, au vu de tes interventions sur
différents forums, que tu as largement le niveau pour le faire toi-même.
Le tout est de bien préparer son cours et de respirer un bon coup au
début ;-)
--
Jerome, prof d'info à ses heures...
"Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux.
Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo."
M. in fr.comp.os.linux.debats
Le Tue, 24 Aug 2004 19:10:05 +0200, Rakotomandimby Mihamina a écrit :
Bonjour,
Bonsoir,
(snip le descriptif)
Je ne peux pas assurer moi-meme ce genre d'intervention car je suis moi-meme de bien faible niveau en adminnistration (je ne me sens pas a la hauteur, quoi)
(Donnant une introduction à Linux, voici ce que j'applique)
Si le but est de montrer l'intéret de la CLI, le plus simple est de montrer des traitements par lots, genre renommer en "juin" tous les fichiers commençant par "mai", ou appliquer un chmod (ou un chown) bien senti à tous les fichiers sur un critère précis (date, etc.).
Il suffit alors de montrer que, pendant que les élèves cliquent à tout va, une ligne de commande "kivabien" résout le problème en quelques secondes.
De même, on peut montrer très facilement l'intérêt de placer les signes | , & , > et >> pour faire des opérations complexes, ou encore des outils comme write ou talk (sous Unix bien sur...).
Enfin, la plupart des serveurs fonctionnant *sans* interface graphique, l'apprentissage de la CLI est indispensable, de même que la gestion d'une machine à distance via SSH (avec les débutants, je me connecte sur une machine en root et puis je fais "eject cdrom". Effet garanti ;-)
Pour montrer tout cela, je pense, au vu de tes interventions sur différents forums, que tu as largement le niveau pour le faire toi-même. Le tout est de bien préparer son cours et de respirer un bon coup au début ;-)
-- Jerome, prof d'info à ses heures... "Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux. Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo." M. in fr.comp.os.linux.debats
cedric
En plus de ce qui a été dis par Jérome, il me semble intéressant d'expliquer la "philosophie" des flux et des filtres derrière la ligne de commande. En effet, la ligne de commande n'est puissante que si, d'une part, le format de donnée standard est le texte (ASCII par exemple) et d'autre part on dispose d'un jeu de commandes simples dont on peut brancher les entrées aux sorties (les "filtres").
Bref, le shell n'est puissant que grace à cet ensemble (ASCII + commandes + pipes) et le problème du clicodrome que tu cite est surtout de ne pas offrir d'interface utilisateur cohérente. Ca a très peu à voir avec le fait d'utiliser la souris plutot que le clavier, de ce point de vue (et d'ailleurs, il me semble que pour ca Apple s'en sort mieux).
Maintenant, est-ce toujours perspicace de nos jour de considérer que le format de donnée universel est l'ASCII, et que le moyen d'accès à un ordinateur est le clavier (ou tout autre input orienté flux de caractères), ca peut légitimement se discuter à l'heure ou de plus en plus d'ordinateurs possèdent un écran tactile mais pas de clavier (agendas...).
En plus de ce qui a été dis par Jérome, il me semble intéressant
d'expliquer la "philosophie" des flux et des filtres derrière la ligne
de commande. En effet, la ligne de commande n'est puissante que si,
d'une part, le format de donnée standard est le texte (ASCII par
exemple) et d'autre part on dispose d'un jeu de commandes simples dont
on peut brancher les entrées aux sorties (les "filtres").
Bref, le shell n'est puissant que grace à cet ensemble (ASCII +
commandes + pipes) et le problème du clicodrome que tu cite est surtout
de ne pas offrir d'interface utilisateur cohérente. Ca a très peu à voir
avec le fait d'utiliser la souris plutot que le clavier, de ce point de
vue (et d'ailleurs, il me semble que pour ca Apple s'en sort mieux).
Maintenant, est-ce toujours perspicace de nos jour de considérer que le
format de donnée universel est l'ASCII, et que le moyen d'accès à un
ordinateur est le clavier (ou tout autre input orienté flux de
caractères), ca peut légitimement se discuter à l'heure ou de plus en
plus d'ordinateurs possèdent un écran tactile mais pas de clavier
(agendas...).
En plus de ce qui a été dis par Jérome, il me semble intéressant d'expliquer la "philosophie" des flux et des filtres derrière la ligne de commande. En effet, la ligne de commande n'est puissante que si, d'une part, le format de donnée standard est le texte (ASCII par exemple) et d'autre part on dispose d'un jeu de commandes simples dont on peut brancher les entrées aux sorties (les "filtres").
Bref, le shell n'est puissant que grace à cet ensemble (ASCII + commandes + pipes) et le problème du clicodrome que tu cite est surtout de ne pas offrir d'interface utilisateur cohérente. Ca a très peu à voir avec le fait d'utiliser la souris plutot que le clavier, de ce point de vue (et d'ailleurs, il me semble que pour ca Apple s'en sort mieux).
Maintenant, est-ce toujours perspicace de nos jour de considérer que le format de donnée universel est l'ASCII, et que le moyen d'accès à un ordinateur est le clavier (ou tout autre input orienté flux de caractères), ca peut légitimement se discuter à l'heure ou de plus en plus d'ordinateurs possèdent un écran tactile mais pas de clavier (agendas...).
no
On Tue, 24 Aug 2004 20:10:08 +0200, cedric wrote:
Maintenant, est-ce toujours perspicace de nos jour de considérer que le format de donnée universel est l'ASCII
Bien au contraire, je pense que l'ASCII, ou du moins le texte en unicode par exemple, devient justement de plus en plus le support des données. Il n'y a qu'a voir le HTML/CSS, le XML, les interfaces XMLRPC/SOAP qui remplacent les protocoles/API « binaires ». A l'époque il était plus simple/plus économe d'avoir des champs/enregistrements de longueur fixe que l'on pouvait parsé a coup de read et de fseek alors qu'actuellement on n'hésite pas a stocker tout cela dans du XML.
On Tue, 24 Aug 2004 20:10:08 +0200, cedric wrote:
Maintenant, est-ce toujours perspicace de nos jour de considérer que le
format de donnée universel est l'ASCII
Bien au contraire, je pense que l'ASCII, ou du moins le texte en unicode
par exemple, devient justement de plus en plus le support des données.
Il n'y a qu'a voir le HTML/CSS, le XML, les interfaces XMLRPC/SOAP qui
remplacent les protocoles/API « binaires ». A l'époque il était plus
simple/plus économe d'avoir des champs/enregistrements de longueur fixe
que l'on pouvait parsé a coup de read et de fseek alors qu'actuellement
on n'hésite pas a stocker tout cela dans du XML.
Maintenant, est-ce toujours perspicace de nos jour de considérer que le format de donnée universel est l'ASCII
Bien au contraire, je pense que l'ASCII, ou du moins le texte en unicode par exemple, devient justement de plus en plus le support des données. Il n'y a qu'a voir le HTML/CSS, le XML, les interfaces XMLRPC/SOAP qui remplacent les protocoles/API « binaires ». A l'époque il était plus simple/plus économe d'avoir des champs/enregistrements de longueur fixe que l'on pouvait parsé a coup de read et de fseek alors qu'actuellement on n'hésite pas a stocker tout cela dans du XML.
Pascal Bourguignon
cedric writes:
Maintenant, est-ce toujours perspicace de nos jour de considérer que le format de donnée universel est l'ASCII, et que le moyen d'accès à un ordinateur est le clavier (ou tout autre input orienté flux de caractères), ca peut légitimement se discuter à l'heure ou de plus en plus d'ordinateurs possèdent un écran tactile mais pas de clavier (agendas...).
Justement discutons en!
Si les périfériques multimédia respectaient plus souvent la philosophie unix, ça marcherait parfaitement.
commande-vocale < /dev/audio | sed -n 's/<bash>//p' | bash
Malheureusement, ça reste trop souvent un voeux pieux avec comme lamentable excuse que les serveur unix d'il y a dix ans n'étaient pas capables de gérer de tels flux multimédia en temps réel.
Allez, pour voir, il y en a combien qui utilisent encore quotidiennement un ordinateur de bureau ("workstation") vieux de dix ans?
Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
cedric <rixed@happyleptic.NOSPAM.org> writes:
Maintenant, est-ce toujours perspicace de nos jour de considérer que
le format de donnée universel est l'ASCII, et que le moyen d'accès à
un ordinateur est le clavier (ou tout autre input orienté flux de
caractères), ca peut légitimement se discuter à l'heure ou de plus en
plus d'ordinateurs possèdent un écran tactile mais pas de clavier
(agendas...).
Justement discutons en!
Si les périfériques multimédia respectaient plus souvent la
philosophie unix, ça marcherait parfaitement.
commande-vocale < /dev/audio | sed -n 's/<bash>//p' | bash
Malheureusement, ça reste trop souvent un voeux pieux avec comme
lamentable excuse que les serveur unix d'il y a dix ans n'étaient pas
capables de gérer de tels flux multimédia en temps réel.
Allez, pour voir, il y en a combien qui utilisent encore
quotidiennement un ordinateur de bureau ("workstation") vieux de dix ans?
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Maintenant, est-ce toujours perspicace de nos jour de considérer que le format de donnée universel est l'ASCII, et que le moyen d'accès à un ordinateur est le clavier (ou tout autre input orienté flux de caractères), ca peut légitimement se discuter à l'heure ou de plus en plus d'ordinateurs possèdent un écran tactile mais pas de clavier (agendas...).
Justement discutons en!
Si les périfériques multimédia respectaient plus souvent la philosophie unix, ça marcherait parfaitement.
commande-vocale < /dev/audio | sed -n 's/<bash>//p' | bash
Malheureusement, ça reste trop souvent un voeux pieux avec comme lamentable excuse que les serveur unix d'il y a dix ans n'étaient pas capables de gérer de tels flux multimédia en temps réel.
Allez, pour voir, il y en a combien qui utilisent encore quotidiennement un ordinateur de bureau ("workstation") vieux de dix ans?
Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
Miod Vallat
Allez, pour voir, il y en a combien qui utilisent encore quotidiennement un ordinateur de bureau ("workstation") vieux de dix ans?
Ben, y'a moi, si ton critère est «dix ans et plus».
Allez, pour voir, il y en a combien qui utilisent encore
quotidiennement un ordinateur de bureau ("workstation") vieux de dix ans?
Ben, y'a moi, si ton critère est «dix ans et plus».
Allez, pour voir, il y en a combien qui utilisent encore quotidiennement un ordinateur de bureau ("workstation") vieux de dix ans?
Ben, y'a moi, si ton critère est «dix ans et plus».
cedric
Les exemples sités sont allécheants, mais tout de même il ne faut pas se cacher un problème : un flux video mpeg ou un document XML ont une structure de donnée nettement plus complexe qu'un flux de lignes de caractères. Je veux dire par là que le sens des données n'est plus "local" : pour interpreter un octet, il faut se référer à des infos qui sont par exemple contenues dans le header du fichier, voir carément dans d'autres fichiers (DTD...). Ceci nuit fortement à l'efficacité de telles commandes (et à leur simplicité d'implémentation) - tu vas peut etre me dire que tout ceci n'entre pas en considération pour l'utilisateur, mais moi j'ai tendance à penser que si.
- tu es obligé de propager toi même l'information de format du flux - ce serait bien si mpeg2compress "savait" que le format d'entrée est jpeg - le positionnement du zoom n'est pas modifiable à la volée (par une autre entrée, idéalement), de meme que la taille du zoom
Bref, il faudrait plus d'un pipe de communication entre les commandes pour que ce soit aussi beau et souple que le sont les commandes pour manipuler du texte. Il faudrait pouvoir brancher l'input de zoom sur la sortie d'un GUI pour positionner le zoom et regler la taille de l'image par exemple.
Ca existe un unix avec plus de flux que stdin/out/err ? Plan9 peut etre ?
Les exemples sités sont allécheants, mais tout de même il ne faut pas se
cacher un problème : un flux video mpeg ou un document XML ont une
structure de donnée nettement plus complexe qu'un flux de lignes de
caractères. Je veux dire par là que le sens des données n'est plus
"local" : pour interpreter un octet, il faut se référer à des infos qui
sont par exemple contenues dans le header du fichier, voir carément dans
d'autres fichiers (DTD...). Ceci nuit fortement à l'efficacité de telles
commandes (et à leur simplicité d'implémentation) - tu vas peut etre me
dire que tout ceci n'entre pas en considération pour l'utilisateur, mais
moi j'ai tendance à penser que si.
- tu es obligé de propager toi même l'information de format du flux - ce
serait bien si mpeg2compress "savait" que le format d'entrée est jpeg
- le positionnement du zoom n'est pas modifiable à la volée (par une
autre entrée, idéalement), de meme que la taille du zoom
Bref, il faudrait plus d'un pipe de communication entre les commandes
pour que ce soit aussi beau et souple que le sont les commandes pour
manipuler du texte. Il faudrait pouvoir brancher l'input de zoom sur la
sortie d'un GUI pour positionner le zoom et regler la taille de l'image
par exemple.
Ca existe un unix avec plus de flux que stdin/out/err ?
Plan9 peut etre ?
Les exemples sités sont allécheants, mais tout de même il ne faut pas se cacher un problème : un flux video mpeg ou un document XML ont une structure de donnée nettement plus complexe qu'un flux de lignes de caractères. Je veux dire par là que le sens des données n'est plus "local" : pour interpreter un octet, il faut se référer à des infos qui sont par exemple contenues dans le header du fichier, voir carément dans d'autres fichiers (DTD...). Ceci nuit fortement à l'efficacité de telles commandes (et à leur simplicité d'implémentation) - tu vas peut etre me dire que tout ceci n'entre pas en considération pour l'utilisateur, mais moi j'ai tendance à penser que si.
- tu es obligé de propager toi même l'information de format du flux - ce serait bien si mpeg2compress "savait" que le format d'entrée est jpeg - le positionnement du zoom n'est pas modifiable à la volée (par une autre entrée, idéalement), de meme que la taille du zoom
Bref, il faudrait plus d'un pipe de communication entre les commandes pour que ce soit aussi beau et souple que le sont les commandes pour manipuler du texte. Il faudrait pouvoir brancher l'input de zoom sur la sortie d'un GUI pour positionner le zoom et regler la taille de l'image par exemple.
Ca existe un unix avec plus de flux que stdin/out/err ? Plan9 peut etre ?
cedric
no wrote:
Bien au contraire, je pense que l'ASCII, ou du moins le texte en unicode par exemple, devient justement de plus en plus le support des données. Il n'y a qu'a voir le HTML/CSS, le XML, les interfaces XMLRPC/SOAP qui remplacent les protocoles/API « binaires ».
Oui mais ces données ne se lisent plus de façon linéaire. un document XML a une structure d'arbre là où les fichiers ASCII considérés initialement étaient de simples séquences de lignes.
A l'époque il était plus simple/plus économe d'avoir des champs/enregistrements de longueur fixe que l'on pouvait parsé a coup de read et de fseek alors qu'actuellement on n'hésite pas a stocker tout cela dans du XML.
Et on a peut être tort :-)
no wrote:
Bien au contraire, je pense que l'ASCII, ou du moins le texte en unicode
par exemple, devient justement de plus en plus le support des données.
Il n'y a qu'a voir le HTML/CSS, le XML, les interfaces XMLRPC/SOAP qui
remplacent les protocoles/API « binaires ».
Oui mais ces données ne se lisent plus de façon linéaire. un document
XML a une structure d'arbre là où les fichiers ASCII considérés
initialement étaient de simples séquences de lignes.
A l'époque il était plus
simple/plus économe d'avoir des champs/enregistrements de longueur fixe
que l'on pouvait parsé a coup de read et de fseek alors qu'actuellement
on n'hésite pas a stocker tout cela dans du XML.
Bien au contraire, je pense que l'ASCII, ou du moins le texte en unicode par exemple, devient justement de plus en plus le support des données. Il n'y a qu'a voir le HTML/CSS, le XML, les interfaces XMLRPC/SOAP qui remplacent les protocoles/API « binaires ».
Oui mais ces données ne se lisent plus de façon linéaire. un document XML a une structure d'arbre là où les fichiers ASCII considérés initialement étaient de simples séquences de lignes.
A l'époque il était plus simple/plus économe d'avoir des champs/enregistrements de longueur fixe que l'on pouvait parsé a coup de read et de fseek alors qu'actuellement on n'hésite pas a stocker tout cela dans du XML.
Et on a peut être tort :-)
Stephane Chazelas
2004-08-24, 22:18(+02), Pascal Bourguignon: [...]
Si les périfériques multimédia respectaient plus souvent la philosophie unix, ça marcherait parfaitement. [...]
On peut faire pas mal de trucs tres puissants avec ALSA, en y incluant un peu de cette "philosophie unix".
Je me rappelle m'etre pas mal amusé avec un Winmodem et une carte son pilotés par ALSA du temps que j'avais un PC.
(ALSA == advanced Linux sound architecture).
-- Stephane
2004-08-24, 22:18(+02), Pascal Bourguignon:
[...]
Si les périfériques multimédia respectaient plus souvent la
philosophie unix, ça marcherait parfaitement.
[...]
On peut faire pas mal de trucs tres puissants avec ALSA, en y
incluant un peu de cette "philosophie unix".
Je me rappelle m'etre pas mal amusé avec un Winmodem et une
carte son pilotés par ALSA du temps que j'avais un PC.
Si les périfériques multimédia respectaient plus souvent la philosophie unix, ça marcherait parfaitement. [...]
On peut faire pas mal de trucs tres puissants avec ALSA, en y incluant un peu de cette "philosophie unix".
Je me rappelle m'etre pas mal amusé avec un Winmodem et une carte son pilotés par ALSA du temps que j'avais un PC.
(ALSA == advanced Linux sound architecture).
-- Stephane
Stephane Chazelas
2004-08-24, 19:37(+02), Jerome Lambert: [...]
Si le but est de montrer l'intéret de la CLI, le plus simple est de montrer des traitements par lots, genre renommer en "juin" tous les fichiers commençant par "mai"
Mauvais exemple. Pour faire ca de facon fiable, c'est assez dificile en shell. C'est une question posee tres frequemment sur comp.unix.shell qui declenche a chaque fois de nombreuses reponses inapropriees. Il faut avoir une application specifique genre mmv (ou utiliser zsh), j'imagine que de telles applications existent sous leur forme graphique.
, ou appliquer un chmod (ou un chown) bien senti à tous les fichiers sur un critère précis (date, etc.).
Un clickodrome pourrait tres bien faire ca, meme mieux que find. Je veux meme croire que ca existe deja.
[...]
outils comme write ou talk (sous Unix bien sur...).
Plutot intrusif comme outils. Justement, avec l'interface graphique, l'equivalent de ce genre d'outil (ytalk ou je ne sais plus comme s'appelait l'equivalent de "write" pour Win 3.11) utilise une fenetre differente de celle de travail.
Enfin, la plupart des serveurs fonctionnant *sans* interface graphique, l'apprentissage de la CLI est indispensable, de même que la gestion d'une machine à distance via SSH (avec les débutants, je me connecte sur une machine en root et puis je fais "eject cdrom". Effet garanti ;-)
Dans le cas ou on veuille administrer une machine a distance. Ca ne s'adresse pas forcement aux gens visés par l'OP.
Faut voir que les shells Unix (au moins les recents) sont assez mal concus, et demandent pas mal d'investissement avant de pouvoir etre productif avec. Pour une utilisation "end user" d'un ordinateur, je ne suis pas sur que l'investissement soit rentable.
-- Stephane
2004-08-24, 19:37(+02), Jerome Lambert:
[...]
Si le but est de montrer l'intéret de la CLI, le plus simple est de
montrer des traitements par lots, genre renommer en "juin" tous les
fichiers commençant par "mai"
Mauvais exemple. Pour faire ca de facon fiable, c'est assez
dificile en shell. C'est une question posee tres frequemment sur
comp.unix.shell qui declenche a chaque fois de nombreuses
reponses inapropriees. Il faut avoir une application specifique
genre mmv (ou utiliser zsh), j'imagine que de telles
applications existent sous leur forme graphique.
, ou appliquer un chmod (ou un chown) bien
senti à tous les fichiers sur un critère précis (date, etc.).
Un clickodrome pourrait tres bien faire ca, meme mieux que find.
Je veux meme croire que ca existe deja.
[...]
outils comme write ou talk (sous Unix bien sur...).
Plutot intrusif comme outils. Justement, avec l'interface
graphique, l'equivalent de ce genre d'outil (ytalk ou je ne sais
plus comme s'appelait l'equivalent de "write" pour Win 3.11)
utilise une fenetre differente de celle de travail.
Enfin, la plupart des serveurs fonctionnant *sans* interface graphique,
l'apprentissage de la CLI est indispensable, de même que la gestion d'une
machine à distance via SSH (avec les débutants, je me connecte sur une
machine en root et puis je fais "eject cdrom". Effet garanti ;-)
Dans le cas ou on veuille administrer une machine a distance. Ca
ne s'adresse pas forcement aux gens visés par l'OP.
Faut voir que les shells Unix (au moins les recents) sont assez
mal concus, et demandent pas mal d'investissement avant de
pouvoir etre productif avec. Pour une utilisation "end user"
d'un ordinateur, je ne suis pas sur que l'investissement soit
rentable.
Si le but est de montrer l'intéret de la CLI, le plus simple est de montrer des traitements par lots, genre renommer en "juin" tous les fichiers commençant par "mai"
Mauvais exemple. Pour faire ca de facon fiable, c'est assez dificile en shell. C'est une question posee tres frequemment sur comp.unix.shell qui declenche a chaque fois de nombreuses reponses inapropriees. Il faut avoir une application specifique genre mmv (ou utiliser zsh), j'imagine que de telles applications existent sous leur forme graphique.
, ou appliquer un chmod (ou un chown) bien senti à tous les fichiers sur un critère précis (date, etc.).
Un clickodrome pourrait tres bien faire ca, meme mieux que find. Je veux meme croire que ca existe deja.
[...]
outils comme write ou talk (sous Unix bien sur...).
Plutot intrusif comme outils. Justement, avec l'interface graphique, l'equivalent de ce genre d'outil (ytalk ou je ne sais plus comme s'appelait l'equivalent de "write" pour Win 3.11) utilise une fenetre differente de celle de travail.
Enfin, la plupart des serveurs fonctionnant *sans* interface graphique, l'apprentissage de la CLI est indispensable, de même que la gestion d'une machine à distance via SSH (avec les débutants, je me connecte sur une machine en root et puis je fais "eject cdrom". Effet garanti ;-)
Dans le cas ou on veuille administrer une machine a distance. Ca ne s'adresse pas forcement aux gens visés par l'OP.
Faut voir que les shells Unix (au moins les recents) sont assez mal concus, et demandent pas mal d'investissement avant de pouvoir etre productif avec. Pour une utilisation "end user" d'un ordinateur, je ne suis pas sur que l'investissement soit rentable.
-- Stephane
manu
Erwan David wrote:
Ouais un système de macro qui dirait faire un évènement "click" sur le boton truc mettre "toto" dans le champ machin, etc ?
Non, c'est plus "meta" que ca.
En fait une appli developpée pour AppleScript est coupée en deux: tu as le moteur et l'interface utilisateur. Les deux communiquent à coup d'evenements appellées AppleEvents.
Les AppleEvents décrivent le fonctionnement de l'application à haut niveau. Par exemple un traitement de texte va definir des objets document, paragraphe, mot, et des actions sur ces objets.
AppleScript permet de parler directement au back-end de l'application et de lui dire par exemple de copier le 3eme paragraphe du document machin, ou bien de modifier un attribut des fichiers séléctionnés, etc...
L'editeur de script a une fonction "ouvrir un dictionnaire", qui propose d'ouvrir une application. On peut alors y examiner son dictionnaire, c'est à dire la liste des objets et actions proposés par l'application.
Bien sur Apple fournit un cadre de description de tout un tas d'objets et d'actions pour essayer de standardiser la chose. Ca ne marche pas trop mal.
Il n'existe pas à ma connaissance d'equivalent de ces fonctionnalités sous Unix. Petite etude de cas:
En 1997, j'ai fait communiquer la base de données FileMakerPro et le logiciel de dessin vectoriel Canvas. La base contenait les resultats éléctoraux, et Canvas contenait une carte de France. FileMakerPro faisait automatiquement colorier la carte en fonction des resultats.
Depuis des outils pour faire la même chose sont apparus sous Unix: avec une carte au format SVG, on peut utiliser une feuille de style XSL qui transforme le document SVG en un autre document SVG mis en couleur.
Il reste que la facilité de mise en oeuvre n'a pas grand chose à voir. Par contre la solution d'Apple a un inconvénient: l'execution des AppleEvents est rythmé par le scheduling des applications, et ca peut se reveler un peu lent si on en a beaucoup à passer.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Erwan David <erwan@rail.eu.org> wrote:
Ouais un système de macro qui dirait faire un évènement "click" sur
le boton truc mettre "toto" dans le champ machin, etc ?
Non, c'est plus "meta" que ca.
En fait une appli developpée pour AppleScript est coupée en deux: tu as
le moteur et l'interface utilisateur. Les deux communiquent à coup
d'evenements appellées AppleEvents.
Les AppleEvents décrivent le fonctionnement de l'application à haut
niveau. Par exemple un traitement de texte va definir des objets
document, paragraphe, mot, et des actions sur ces objets.
AppleScript permet de parler directement au back-end de l'application et
de lui dire par exemple de copier le 3eme paragraphe du document machin,
ou bien de modifier un attribut des fichiers séléctionnés, etc...
L'editeur de script a une fonction "ouvrir un dictionnaire", qui propose
d'ouvrir une application. On peut alors y examiner son dictionnaire,
c'est à dire la liste des objets et actions proposés par l'application.
Bien sur Apple fournit un cadre de description de tout un tas d'objets
et d'actions pour essayer de standardiser la chose. Ca ne marche pas
trop mal.
Il n'existe pas à ma connaissance d'equivalent de ces fonctionnalités
sous Unix. Petite etude de cas:
En 1997, j'ai fait communiquer la base de données FileMakerPro et le
logiciel de dessin vectoriel Canvas. La base contenait les resultats
éléctoraux, et Canvas contenait une carte de France. FileMakerPro
faisait automatiquement colorier la carte en fonction des resultats.
Depuis des outils pour faire la même chose sont apparus sous Unix: avec
une carte au format SVG, on peut utiliser une feuille de style XSL qui
transforme le document SVG en un autre document SVG mis en couleur.
Il reste que la facilité de mise en oeuvre n'a pas grand chose à voir.
Par contre la solution d'Apple a un inconvénient: l'execution des
AppleEvents est rythmé par le scheduling des applications, et ca peut se
reveler un peu lent si on en a beaucoup à passer.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Ouais un système de macro qui dirait faire un évènement "click" sur le boton truc mettre "toto" dans le champ machin, etc ?
Non, c'est plus "meta" que ca.
En fait une appli developpée pour AppleScript est coupée en deux: tu as le moteur et l'interface utilisateur. Les deux communiquent à coup d'evenements appellées AppleEvents.
Les AppleEvents décrivent le fonctionnement de l'application à haut niveau. Par exemple un traitement de texte va definir des objets document, paragraphe, mot, et des actions sur ces objets.
AppleScript permet de parler directement au back-end de l'application et de lui dire par exemple de copier le 3eme paragraphe du document machin, ou bien de modifier un attribut des fichiers séléctionnés, etc...
L'editeur de script a une fonction "ouvrir un dictionnaire", qui propose d'ouvrir une application. On peut alors y examiner son dictionnaire, c'est à dire la liste des objets et actions proposés par l'application.
Bien sur Apple fournit un cadre de description de tout un tas d'objets et d'actions pour essayer de standardiser la chose. Ca ne marche pas trop mal.
Il n'existe pas à ma connaissance d'equivalent de ces fonctionnalités sous Unix. Petite etude de cas:
En 1997, j'ai fait communiquer la base de données FileMakerPro et le logiciel de dessin vectoriel Canvas. La base contenait les resultats éléctoraux, et Canvas contenait une carte de France. FileMakerPro faisait automatiquement colorier la carte en fonction des resultats.
Depuis des outils pour faire la même chose sont apparus sous Unix: avec une carte au format SVG, on peut utiliser une feuille de style XSL qui transforme le document SVG en un autre document SVG mis en couleur.
Il reste que la facilité de mise en oeuvre n'a pas grand chose à voir. Par contre la solution d'Apple a un inconvénient: l'execution des AppleEvents est rythmé par le scheduling des applications, et ca peut se reveler un peu lent si on en a beaucoup à passer.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
