In article <1ky6b50.1fty7dh1rhae6tN%, (SbM) wrote:
> Patrick Stadelmann wrote: > > > In article <1ky6apz.13j79txk4bixrN%, > > (SbM) wrote: > > > > > Ou pourquoi faire simple quand on peut faire compliqué :) > > > > Pourquoi ? Parce que quand on peut l'éviter, on quitte les applications, > > on ne les tue pas. > > Tu trouves plus simple de taper un script que de faire alt-clic > droit>Relancer ? Franchement ?
C'est pas plus simple, c'est plus propre. Comme passer par le menu Eteindre plutôt que de tirer la prise pour éteindre un iMac !
Hum... question : que sais tu du signal envoyé au finder en premier quand on demande à le relancer ?
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <1ky6b50.1fty7dh1rhae6tN%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
> Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
>
> > In article <1ky6apz.13j79txk4bixrN%sebastienmarty@yahoo.fr>,
> > sebastienmarty@yahoo.fr (SbM) wrote:
> >
> > > Ou pourquoi faire simple quand on peut faire compliqué :)
> >
> > Pourquoi ? Parce que quand on peut l'éviter, on quitte les applications,
> > on ne les tue pas.
>
> Tu trouves plus simple de taper un script que de faire alt-clic
> droit>Relancer ? Franchement ?
C'est pas plus simple, c'est plus propre. Comme passer par le menu
Eteindre plutôt que de tirer la prise pour éteindre un iMac !
Hum... question : que sais tu du signal envoyé au finder en premier
quand on demande à le relancer ?
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
In article <1ky6b50.1fty7dh1rhae6tN%, (SbM) wrote:
> Patrick Stadelmann wrote: > > > In article <1ky6apz.13j79txk4bixrN%, > > (SbM) wrote: > > > > > Ou pourquoi faire simple quand on peut faire compliqué :) > > > > Pourquoi ? Parce que quand on peut l'éviter, on quitte les applications, > > on ne les tue pas. > > Tu trouves plus simple de taper un script que de faire alt-clic > droit>Relancer ? Franchement ?
C'est pas plus simple, c'est plus propre. Comme passer par le menu Eteindre plutôt que de tirer la prise pour éteindre un iMac !
Hum... question : que sais tu du signal envoyé au finder en premier quand on demande à le relancer ?
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
Fleuger wrote:
SbM wrote:
> C'est un force-quit ?
Ça en a l'air.
J'exécute le script -> pas d'inscription dans la console.
Je fais Relancer en cliquant sur l'icône du Finder dans le dock avec la touche alt appuyée. J'obtiens : -> Feb 12 17:29:03 gefleurot com.apple.launchd.peruser.501[278] (com.apple.Finder[8981]): Exited: Terminated: 15
Je fais un Forcer à Quitter sur TextEdit, j'obtiens : Feb 12 17:33:51 gefleurot com.apple.launchd.peruser.501[278] ([0x0-0x668668].com.apple.TextEdit[9213]): Exited: Terminated: 15
Ceci ne prouve rien, bien au contraire :
- les inscriptions dans la console sont faites par le proc qui arrête le finder ou textedit, pas par les applications qui sont quittées.
- les applications sont quittées par le signal SIGTERM qui est un signal propre... (il peut-être capturé, et devrait l'être ) Ce serait par SIGKILL ce serait effectivement une terminaison salle.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Fleuger <g4fleurot@free.fr> wrote:
SbM <sebastienmarty@yahoo.fr> wrote:
> C'est un force-quit ?
Ça en a l'air.
J'exécute le script -> pas d'inscription dans la console.
Je fais Relancer en cliquant sur l'icône du Finder dans le dock avec la
touche alt appuyée. J'obtiens :
-> Feb 12 17:29:03 gefleurot com.apple.launchd.peruser.501[278]
(com.apple.Finder[8981]): Exited: Terminated: 15
Je fais un Forcer à Quitter sur TextEdit, j'obtiens :
Feb 12 17:33:51 gefleurot com.apple.launchd.peruser.501[278]
([0x0-0x668668].com.apple.TextEdit[9213]): Exited: Terminated: 15
Ceci ne prouve rien, bien au contraire :
- les inscriptions dans la console sont faites par le proc qui arrête le
finder ou textedit, pas par les applications qui sont quittées.
- les applications sont quittées par le signal SIGTERM qui est un signal
propre... (il peut-être capturé, et devrait l'être ) Ce serait par
SIGKILL ce serait effectivement une terminaison salle.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
J'exécute le script -> pas d'inscription dans la console.
Je fais Relancer en cliquant sur l'icône du Finder dans le dock avec la touche alt appuyée. J'obtiens : -> Feb 12 17:29:03 gefleurot com.apple.launchd.peruser.501[278] (com.apple.Finder[8981]): Exited: Terminated: 15
Je fais un Forcer à Quitter sur TextEdit, j'obtiens : Feb 12 17:33:51 gefleurot com.apple.launchd.peruser.501[278] ([0x0-0x668668].com.apple.TextEdit[9213]): Exited: Terminated: 15
Ceci ne prouve rien, bien au contraire :
- les inscriptions dans la console sont faites par le proc qui arrête le finder ou textedit, pas par les applications qui sont quittées.
- les applications sont quittées par le signal SIGTERM qui est un signal propre... (il peut-être capturé, et devrait l'être ) Ce serait par SIGKILL ce serait effectivement une terminaison salle.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
Patrick Stadelmann wrote:
In article , Erwan David wrote:
> Donc ni l'un ni l'autre ne sont un forcer à quitter, qui serait un > signal 9, pas 15.
Vu depuis une application GUI normale, c'est un bien un "kill" car elle ne reçoit pas d'AppleEvent 'quit' comme quand elle est fermée proprement (menu Quitter ou son raccourci, 'quit' envoyer par le système, lors du log out par exemple etc). Elle ne voit donc rien venir et ne peut pas quitter proprement.
Bien sûr que si... il n'y a pas que les AppleEvent, il y a aussi la couche unix.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <87sj51tq2k.fsf@bibi.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
> Donc ni l'un ni l'autre ne sont un forcer à quitter, qui serait un
> signal 9, pas 15.
Vu depuis une application GUI normale, c'est un bien un "kill" car elle
ne reçoit pas d'AppleEvent 'quit' comme quand elle est fermée proprement
(menu Quitter ou son raccourci, 'quit' envoyer par le système, lors du
log out par exemple etc). Elle ne voit donc rien venir et ne peut pas
quitter proprement.
Bien sûr que si... il n'y a pas que les AppleEvent, il y a aussi la
couche unix.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
> Donc ni l'un ni l'autre ne sont un forcer à quitter, qui serait un > signal 9, pas 15.
Vu depuis une application GUI normale, c'est un bien un "kill" car elle ne reçoit pas d'AppleEvent 'quit' comme quand elle est fermée proprement (menu Quitter ou son raccourci, 'quit' envoyer par le système, lors du log out par exemple etc). Elle ne voit donc rien venir et ne peut pas quitter proprement.
Bien sûr que si... il n'y a pas que les AppleEvent, il y a aussi la couche unix.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
mvaukois
Philippe RAI wrote:
Il n'y a pas un petit utilitaire qui fait cela ?
Outre la solution donnée par Manfred, il y a plusieurs utilitaires qui font ça comme Deeper ou TinkerTool et sans doute Onyx. Celui que j'ai choisi est XtraFinder qui permet, entre autres choses, de définir un raccourci clavier pour rendre visibles ou invisibles les fichiers normalement invisibles. -- Michel Vauquois Que Dieu vous garde... Moi j'ai pas le temps (RD)
Philippe RAI <philo.ra@NoSm-freesurf.fr> wrote:
Il n'y a pas un petit utilitaire qui fait cela ?
Outre la solution donnée par Manfred, il y a plusieurs utilitaires qui
font ça comme Deeper ou TinkerTool et sans doute Onyx.
Celui que j'ai choisi est XtraFinder qui permet, entre autres choses, de
définir un raccourci clavier pour rendre visibles ou invisibles les
fichiers normalement invisibles.
--
Michel Vauquois
Que Dieu vous garde... Moi j'ai pas le temps (RD)
Outre la solution donnée par Manfred, il y a plusieurs utilitaires qui font ça comme Deeper ou TinkerTool et sans doute Onyx. Celui que j'ai choisi est XtraFinder qui permet, entre autres choses, de définir un raccourci clavier pour rendre visibles ou invisibles les fichiers normalement invisibles. -- Michel Vauquois Que Dieu vous garde... Moi j'ai pas le temps (RD)
Patrick Stadelmann
In article <1ky74hz.toa5ua1x4mks9N%, (FiLH) wrote:
Patrick Stadelmann wrote:
> In article , > Erwan David wrote: > > > Donc ni l'un ni l'autre ne sont un forcer à quitter, qui serait un > > signal 9, pas 15. > > Vu depuis une application GUI normale, c'est un bien un "kill" car elle > ne reçoit pas d'AppleEvent 'quit' comme quand elle est fermée proprement > (menu Quitter ou son raccourci, 'quit' envoyer par le système, lors du > log out par exemple etc). Elle ne voit donc rien venir et ne peut pas > quitter proprement.
Bien sûr que si... il n'y a pas que les AppleEvent, il y a aussi la couche unix.
La grande majorité des applications GUI ne voient pas les signaux, simplement parce qu'elles se repose sur les mécanismes natifs d'OS X.
Patrick -- Patrick Stadelmann
In article <1ky74hz.toa5ua1x4mks9N%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> In article <87sj51tq2k.fsf@bibi.depot.rail.eu.org>,
> Erwan David <erwan@rail.eu.org> wrote:
>
> > Donc ni l'un ni l'autre ne sont un forcer à quitter, qui serait un
> > signal 9, pas 15.
>
> Vu depuis une application GUI normale, c'est un bien un "kill" car elle
> ne reçoit pas d'AppleEvent 'quit' comme quand elle est fermée proprement
> (menu Quitter ou son raccourci, 'quit' envoyer par le système, lors du
> log out par exemple etc). Elle ne voit donc rien venir et ne peut pas
> quitter proprement.
Bien sûr que si... il n'y a pas que les AppleEvent, il y a aussi la
couche unix.
La grande majorité des applications GUI ne voient pas les signaux,
simplement parce qu'elles se repose sur les mécanismes natifs d'OS X.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1ky74hz.toa5ua1x4mks9N%, (FiLH) wrote:
Patrick Stadelmann wrote:
> In article , > Erwan David wrote: > > > Donc ni l'un ni l'autre ne sont un forcer à quitter, qui serait un > > signal 9, pas 15. > > Vu depuis une application GUI normale, c'est un bien un "kill" car elle > ne reçoit pas d'AppleEvent 'quit' comme quand elle est fermée proprement > (menu Quitter ou son raccourci, 'quit' envoyer par le système, lors du > log out par exemple etc). Elle ne voit donc rien venir et ne peut pas > quitter proprement.
Bien sûr que si... il n'y a pas que les AppleEvent, il y a aussi la couche unix.
La grande majorité des applications GUI ne voient pas les signaux, simplement parce qu'elles se repose sur les mécanismes natifs d'OS X.
Patrick -- Patrick Stadelmann
philo.ra
MV wrote:
Philippe RAI wrote:
> Il n'y a pas un petit utilitaire qui fait cela ?
Outre la solution donnée par Manfred, il y a plusieurs utilitaires qui font ça comme Deeper ou TinkerTool et sans doute Onyx. Celui que j'ai choisi est XtraFinder qui permet, entre autres choses, de définir un raccourci clavier pour rendre visibles ou invisibles les fichiers normalement invisibles.
OK merci, j'avais déjà Onyx je n'avais pas vu qu'il avait cette fonction.
MV <mvaukois@orage.fr.invalid> wrote:
Philippe RAI <philo.ra@NoSm-freesurf.fr> wrote:
> Il n'y a pas un petit utilitaire qui fait cela ?
Outre la solution donnée par Manfred, il y a plusieurs utilitaires qui
font ça comme Deeper ou TinkerTool et sans doute Onyx.
Celui que j'ai choisi est XtraFinder qui permet, entre autres choses, de
définir un raccourci clavier pour rendre visibles ou invisibles les
fichiers normalement invisibles.
OK merci, j'avais déjà Onyx je n'avais pas vu qu'il avait cette
fonction.
> Il n'y a pas un petit utilitaire qui fait cela ?
Outre la solution donnée par Manfred, il y a plusieurs utilitaires qui font ça comme Deeper ou TinkerTool et sans doute Onyx. Celui que j'ai choisi est XtraFinder qui permet, entre autres choses, de définir un raccourci clavier pour rendre visibles ou invisibles les fichiers normalement invisibles.
OK merci, j'avais déjà Onyx je n'avais pas vu qu'il avait cette fonction.
g4fleurot
FiLH wrote:
Ceci ne prouve rien,
bien au contraire :
? ? ?
- les inscriptions dans la console sont faites par le proc qui arrête le finder ou textedit, pas par les applications qui sont quittées.
Je comprend que le système envoie une instruction 15 qu'il écrit aussi dans la console. L'application la reçoit et réagit en conséquence si elle est programmée pour le faire.
- les applications sont quittées par le signal SIGTERM qui est un signal propre... (il peut-être capturé, et devrait l'être ) Ce serait par SIGKILL ce serait effectivement une terminaison salle.
Effectivement 15 est un SIGTERM, mais quelle est la différence pour le fonctionnement futur d'une application entre un 15 et un 9 ?
Dans le cas du 15, je constate que je peux relancer l'application et qu'elle fonctionne.
Mais dans le cas d'un 9, (pour ma culture personnelle, je ne suis pas informaticien, mais un retraité un peu curieux) l'application fonctionne-t-elle toujours ou bien est-ce qu'elle risque d'être corrompue et doit être réinstallée ?
C'est ce que je crois comprendre lorsqu'on dit d'une terminaison qu'elle est sale. Quelque chose qui "casserait" le code de l'application ?
-- Gérard FLEUROT plus un
FiLH <filh@filh.orgie> wrote:
Ceci ne prouve rien,
bien au contraire :
? ? ?
- les inscriptions dans la console sont faites par le proc qui arrête le
finder ou textedit, pas par les applications qui sont quittées.
Je comprend que le système envoie une instruction 15 qu'il écrit aussi
dans la console.
L'application la reçoit et réagit en conséquence si elle est programmée
pour le faire.
- les applications sont quittées par le signal SIGTERM qui est un signal
propre... (il peut-être capturé, et devrait l'être ) Ce serait par
SIGKILL ce serait effectivement une terminaison salle.
Effectivement 15 est un SIGTERM, mais quelle est la différence pour le
fonctionnement futur d'une application entre un 15 et un 9 ?
Dans le cas du 15, je constate que je peux relancer l'application et
qu'elle fonctionne.
Mais dans le cas d'un 9, (pour ma culture personnelle, je ne suis pas
informaticien, mais un retraité un peu curieux) l'application
fonctionne-t-elle toujours ou bien est-ce qu'elle risque d'être
corrompue et doit être réinstallée ?
C'est ce que je crois comprendre lorsqu'on dit d'une terminaison qu'elle
est sale. Quelque chose qui "casserait" le code de l'application ?
Je comprend que le système envoie une instruction 15 qu'il écrit aussi dans la console. L'application la reçoit et réagit en conséquence si elle est programmée pour le faire.
- les applications sont quittées par le signal SIGTERM qui est un signal propre... (il peut-être capturé, et devrait l'être ) Ce serait par SIGKILL ce serait effectivement une terminaison salle.
Effectivement 15 est un SIGTERM, mais quelle est la différence pour le fonctionnement futur d'une application entre un 15 et un 9 ?
Dans le cas du 15, je constate que je peux relancer l'application et qu'elle fonctionne.
Mais dans le cas d'un 9, (pour ma culture personnelle, je ne suis pas informaticien, mais un retraité un peu curieux) l'application fonctionne-t-elle toujours ou bien est-ce qu'elle risque d'être corrompue et doit être réinstallée ?
C'est ce que je crois comprendre lorsqu'on dit d'une terminaison qu'elle est sale. Quelque chose qui "casserait" le code de l'application ?
-- Gérard FLEUROT plus un
g4fleurot
Patrick Stadelmann wrote:
C'est pourquoi depuis quelques versions, si une application plante quand on la relance, Mac OS X propose de remettre à zéro ses préférences.
En fait, depuis longtemps, ce que la sagesse recommande de faire quand une application ne répond plus comme elle devrait le faire.
Le code lui-même est en lecture seule, et un plantage de l'application n'aura pas d'effet sur lui.
OK, merci Patrick pour ces précisions.
Et merci pour l'éclairage que tu as apporté sur la différence à propos du Finder entre Quitter et Relancer.
-- Gérard FLEUROT plus un
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
C'est pourquoi depuis quelques versions, si une application
plante quand on la relance, Mac OS X propose de remettre à zéro ses
préférences.
En fait, depuis longtemps, ce que la sagesse recommande de faire quand
une application ne répond plus comme elle devrait le faire.
Le code lui-même est en lecture seule, et un plantage de l'application
n'aura pas d'effet sur lui.
OK, merci Patrick pour ces précisions.
Et merci pour l'éclairage que tu as apporté sur la différence à propos
du Finder entre Quitter et Relancer.
C'est pourquoi depuis quelques versions, si une application plante quand on la relance, Mac OS X propose de remettre à zéro ses préférences.
En fait, depuis longtemps, ce que la sagesse recommande de faire quand une application ne répond plus comme elle devrait le faire.
Le code lui-même est en lecture seule, et un plantage de l'application n'aura pas d'effet sur lui.
OK, merci Patrick pour ces précisions.
Et merci pour l'éclairage que tu as apporté sur la différence à propos du Finder entre Quitter et Relancer.
-- Gérard FLEUROT plus un
erwan
Patrick Stadelmann écrivait :
In article <1ky81g9.1jgp36z1eyjgdiN%, (Fleuger) wrote:
Effectivement 15 est un SIGTERM, mais quelle est la différence pour le fonctionnement futur d'une application entre un 15 et un 9 ?
Dans le cas d'une application "Unix" ça fait la différence entre une fermeture propre ou sale. Dans le cas d'une application graphique dans Mac OS X, ça ne fait en général pas de différence, les deux signaux ont l'effet d'un SIGKILL, car pour gérer une fermeture propre, l'application attend une notification par un autre canal.
Application mal programmée alors, rien ne lui interdit de traiter le sigterm proprement.
-- Les simplifications c'est trop compliqué
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait :
In article <1ky81g9.1jgp36z1eyjgdiN%g4fleurot@free.fr>,
g4fleurot@free.fr (Fleuger) wrote:
Effectivement 15 est un SIGTERM, mais quelle est la différence pour le
fonctionnement futur d'une application entre un 15 et un 9 ?
Dans le cas d'une application "Unix" ça fait la différence entre une
fermeture propre ou sale. Dans le cas d'une application graphique dans
Mac OS X, ça ne fait en général pas de différence, les deux signaux ont
l'effet d'un SIGKILL, car pour gérer une fermeture propre, l'application
attend une notification par un autre canal.
Application mal programmée alors, rien ne lui interdit de traiter le
sigterm proprement.
In article <1ky81g9.1jgp36z1eyjgdiN%, (Fleuger) wrote:
Effectivement 15 est un SIGTERM, mais quelle est la différence pour le fonctionnement futur d'une application entre un 15 et un 9 ?
Dans le cas d'une application "Unix" ça fait la différence entre une fermeture propre ou sale. Dans le cas d'une application graphique dans Mac OS X, ça ne fait en général pas de différence, les deux signaux ont l'effet d'un SIGKILL, car pour gérer une fermeture propre, l'application attend une notification par un autre canal.
Application mal programmée alors, rien ne lui interdit de traiter le sigterm proprement.
-- Les simplifications c'est trop compliqué
Patrick Stadelmann
In article , wrote:
Patrick Stadelmann écrivait :
> In article <1ky81g9.1jgp36z1eyjgdiN%, > (Fleuger) wrote: > >> Effectivement 15 est un SIGTERM, mais quelle est la différence pour le >> fonctionnement futur d'une application entre un 15 et un 9 ? > > Dans le cas d'une application "Unix" ça fait la différence entre une > fermeture propre ou sale. Dans le cas d'une application graphique dans > Mac OS X, ça ne fait en général pas de différence, les deux signaux ont > l'effet d'un SIGKILL, car pour gérer une fermeture propre, l'application > attend une notification par un autre canal.
Application mal programmée alors, rien ne lui interdit de traiter le sigterm proprement.
Non, gérer les signaux n'est pas nécessaire pour les applications GUI. Encore une fois, Mac OS X utilise d'autres mécanismes.
Patrick -- Patrick Stadelmann
In article <87r4kk7c02.fsf@regulateur.rail.eu.org>, erwan@rail.eu.org
wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait :
> In article <1ky81g9.1jgp36z1eyjgdiN%g4fleurot@free.fr>,
> g4fleurot@free.fr (Fleuger) wrote:
>
>> Effectivement 15 est un SIGTERM, mais quelle est la différence pour le
>> fonctionnement futur d'une application entre un 15 et un 9 ?
>
> Dans le cas d'une application "Unix" ça fait la différence entre une
> fermeture propre ou sale. Dans le cas d'une application graphique dans
> Mac OS X, ça ne fait en général pas de différence, les deux signaux ont
> l'effet d'un SIGKILL, car pour gérer une fermeture propre, l'application
> attend une notification par un autre canal.
Application mal programmée alors, rien ne lui interdit de traiter le
sigterm proprement.
Non, gérer les signaux n'est pas nécessaire pour les applications GUI.
Encore une fois, Mac OS X utilise d'autres mécanismes.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
> In article <1ky81g9.1jgp36z1eyjgdiN%, > (Fleuger) wrote: > >> Effectivement 15 est un SIGTERM, mais quelle est la différence pour le >> fonctionnement futur d'une application entre un 15 et un 9 ? > > Dans le cas d'une application "Unix" ça fait la différence entre une > fermeture propre ou sale. Dans le cas d'une application graphique dans > Mac OS X, ça ne fait en général pas de différence, les deux signaux ont > l'effet d'un SIGKILL, car pour gérer une fermeture propre, l'application > attend une notification par un autre canal.
Application mal programmée alors, rien ne lui interdit de traiter le sigterm proprement.
Non, gérer les signaux n'est pas nécessaire pour les applications GUI. Encore une fois, Mac OS X utilise d'autres mécanismes.
