Bonsoir,
 
En réponse à ce topic dans la catégorie Programmation, je me demande s'il y a un équivalent à la commande "start" de Windows.
 
En résumé, dans notre cas, la commande "start" permet de rechercher l'application qui correspond au type mime ou au protocole utilisé dans le paramètre et de l'ouvrir avec l'application concernée.
 
Par exemple :

 
Cette commande est suffisament utile pour que j'imagine qu'un équivalent existe sous Linux. Quelle est-elle donc (si ça se trouve, c'est "start" aussi, mais j'ai pas de nux pour tester )
 
Dans le topic en question, il s'agit d'ouvrir une page web depuis un programme écrit en C, sans devoir rechercher dans la variable path ou autre la présence d'un navigateur connu. Par extension, ça serait pas mal que ça puisse ouvrir n'importe quel autre type de fichier/protocole
 
Vous pouvez répondre dans ce topic ou le topic d'origine, je préviens son auteur de la présence de celui-ci

A ma connaissance l'équivalent à cette commande n'existe pas pour une simple et bonne raison : selon ton environnement de travail tu n'auras pas les mêmes associations fichier/programme.
 
Après si tu veux connaitre le type de fichier tu as la commande "file" et pour un binaire il suffit de faire un test du genre :

 
après réflexion l'équivalent existe peut être (surement même) avec des DM comme gnome et KDE mais je ne les utilise pas

Hmmm, c'est étrange ce que tu me dis.
 
Même si ça part d'une bonne analyse, on est d'accord que l'environnement de travail d'un programme est connu.
 
Donc, si le programme exe tourne en mode console, le kernel sait à tout moment que le programme ne tourne pas sur un serveur X. Deplus, s'il y a 25 consoles actives, le kernel sait toujours dans quelle console tourne le programme...
 
Ensuite, je ne sais pas comment Linux gère les types mime, mais je suppose que chaque environnement (ou application) va venir s'inscrire dans le "registre" des types mime, en indiquant quel environnement est compatible avec l'application non ?
 
Du moins, ça me semblerait logique...
 
Dans tous les cas, KDE ou GNOME acceptent comme l'explorateur Windows de démarrer un programme quand on interroge un fichier, à partir du moment où ce dernier est associé à son type mime. Reste à espérer que c'est le kernel qui s'en charge, et non l'environnement graphique (sinon là c'est goret à mon goût, et je suis d'accord que ça peut pas marcher)

 
Justement non, l'environnement est particulièrement volatile
 

 
Pas d'accord pour le premier point. L'abstraction par rapport au serveur X est justement faite pour éviter ça. Le kernel ne sait pas si un programme est sous X ou si il est dans un tty, ou même encore en remote à l'autre bout de la planète.
 
Pour ce qui est des 25 consoles, encore une fois, c'est faux. Les utilitaires du type screen (       ) permettent d'avoir un programme dans n'importe quelle console (et même dans plusieurs en simultané)
 

 
Non. Ce genre de chose n'existe pas. Du moins pas en dehors de quelque chose comme gnome ou KDE.
 
 

 
C'est l'environnement graphique. Le kernel est situé à un niveau bien inférieur. Tu places le kernel bien trop haut dans l'interaction avec l'utilisateur

Je viens de vérifier sous Windows XP.
start est indépendant de ma GUI (explorer.exe)
J'ai shooté le process de la GUI, et j'ai pu démarrer "more" en lançant un start sur un fichier texte (après avoir modifié le type mime de txt pour qu'il soit associé à "more" ).
Seul truc, il ne fait pas la différence entre more console et mode fenêtré (si on lance un start depuis une console et que le programme associé tourne en mode fenêtré, il ne cherche pas à retrouver le programme "qui va bien" qui tourne en mode console, il cherche direct à ouvrir en mode fenêtré)

black_lord > ben je trouve que la gestion des type mime devraient être plus proche du kernel moi... c'est important que le kernel sâche quoi faire d'un fichier... (enfin, à mon avis)
 
sinon, pour le coup de ton utilitaire "screen", c'est pas simplement une question de redirection des entrées/sorties standard du programme ? (qui elles, sont indépendantes de l'environnement du programme, et c'est normal)
 
moi quand je parle de l'environnement du programme, je parle par exemple de la session de l'utilisateur.
 
si un utilisateur utilise des variables d'environnement qui sont propres à sa session, tous les programmes qu'il va démarrer seront impactés par ses variables d'environnement. par contre, le même programme lancé en même temps par une autre session ne sera pas impacté par ces modifications (même si c'est le même user, et quand bien même il le lancerait depuis une nouvelle session qu'il a ouvert à l'intérieur de sa première, une fois les variables d'environnement modifiées)... j'imagine que c'est le kernel qui gère ça, pas l'interface utilisateur...

 
Non non. Sans rentrer dans un troll, c'est carrement mieux de l'abstraire niveau sécurité
 

 
non ce n'est pas le kernel mais le shell invoqué par l'utilisateur (ou à défaut d'un shell le passage direct des variables à l'environnement par le processus père)

hmmm, ok
 
bon, ben en attendant, Windows c'est mieux, on n'a pas besoin de savoir depuis où on lance le programme ni quels logiciels sont installés, et encore moins où pour ouvrir un fichier

dites "non" à la drogue
 

 
 
Ben "mieux", en quelque sorte seulement ...
SI je ne m'abuse, le but de la personne sur le topic "programmation" est de faire un prog en C qui permette d'éxécuter le prog par défaut associé à un mime type donné, donc d'éxécuter ce qu'il veut comme il veut ... C'est "mieux", oui, en quelque sorte seulement ...

machine à café aussi ?
 
ce que tu proposes est inutile, d'une lourdeur à maintenir sans nom et dangereux.

 
Ce concept existe sous Windows mais pas sous Linux  

le mode console "DOS" est une vue de l'esprit depuis win2000-XP toussa.
le kernel-win inclu/communique directement avec la GUI pour la gestion des fenetres.
 
hors sous linux ce n'est pas le cas car; sur une meme machine il peut y avoir
des users dans tous les modes (console, X11...), c'est donc logique que le
kernel ne sait pas quoi faire d'un type mime et d'ailleurs il ne doit pas savoir le faire.  
 
qd on programme C(++) sous linux ont utilise la gtk ou la kde-lib.
sinon les include X11 pour faire des prog portables dans tous les environnement,
mais il faut quasiment reinventer les fenetres.
 
sachant par ailleurs que les type mime fixes ne sont valables que pour
des environnements "commerciaux" (tel prog ouvre tel fichier pasque
mon fichier est formatté propriétaire éventuellement signé ).
cela n'est pas valable dans un environneemnt open source.

Tiens, les frères Escobar sont descendus en ville à ce que je vois ...

putain, l'argument à deux balles...

sous windows ou macos, on peut tout à fait modifier l'association, je vois pas en quoi c'est gênant.
 
idem quand tu met un +x sur un fichier. quand tu l'appelles c'est bien ton shell qui l'ouvre, et choisi quel autre shell est le plus approprié pour le faire tourner... alors pkoi pas pour les autres types de fichiers.
 
ça tiens pas debout.

C'est pas le boulot du kernel de gérer ça.
Sinon, ça devient un fourre-tout "immonde".
 
C'est le boulot de l'environnement, situé au dessus, KDE ou Gnome, par exemple.

 
non, c'est pas le shell. C'est juste un bit qui indique que c'est éxécutable. rien de plus, rien de moins.

oui mais sous windows c'est pas pareil

 
dit moi quelle proportion d'utilisateurs ne se font pas iech à changer cette association et
prefere installer/payer le logiciel adequat (illustrator, powerpoint, photoshop,
acrobat et j'en passe) plutôt que de chercher des solutions libres avec des types de fichiers libres
(ogg, xvid, opendoc...)
bon d'accord maintenant, les aides à l'install te modifient les types mime toussa, ce qui n'est
même pas le cas sous linux; normal, les types de fichiers et le systeme ext sont par définition libres eux aussi
et donc on ne peut pas prévoir à l'avance quel logiciel va l'ouvrir ==> d'où le fait
que sous linux il est impossible de l'inclure dans le kernel; deja rien que par principe.
les types mime sous linux sont la pour ajouter une cohérence à l'environnement
de bureau utilisé (gnome, kde toussa...)

gnome-open

Bonjour,
 
Je me permet de prendre part à la discution.
L'ayant lue, je me suis dit qu'il fallait peut etre reformuler la question de départ:
 
- si "start" sous linux n'existe pas, il faut l'inventer.
- "start" sous Windows appelle, il me semble, l'api "ShellExecute" qui se trouve dans une dll quelconque.
 
Il faut déterminer si dans l'api de kde, gnome,... il existe une fonction equivalente à "ShellExecute".
 
Sinon détermier ou et sous quelle forme l'on peut ascéder a la base des mime. Car il faut bien qu'elle se trouve quelque part. Et ensuite faire une appli qui va:
- récuperer sur sa ligne de commande le fichier à ouvrir
- chercher dans les mime l'appli la + consernée pour l'extension
- lancer cette appli avec le fichier à ouvrir dans sa ligne de commande.
Et cette appli, tu pourra l'appeller... "start" ! (n'oublie pas de publier sur le web en GPL le resultat)
 
Enfin, si il y a bien un truc dont je suis sur, c'est qu'il faut être super pro pour trouver un truc sous Linux dont jamais personne n'y a pensé avant. J'ai arreter de programmer des exe sous linux le jour ou je me suis rendu compte qu'il y avait toujours quelqu'un qui y avait pensé et developpé avant moi ! Aujourd'huis je serais + a faire des interfaces ou du php/sql.
 
A+ et bon courrage.
 
HDSDI

gnome-open marche top
 
et sous kde ?

C'est bien pour ça que :

 
Ze soucy sous nux en fait, c'est pas que les appli n'existent pas, c'est que :
soit on en a 25 et on passe 6 mois à trouver laquelle est la mieux.
soit on n'en trouve pas, et durant les 6 mois de dev nécessaires pour la faire, on tombe dessus
 
sous windows au moins, on est vite fixé : ça existe, mais faut payer
 
sinon, merci pour ton intervention très constructive

merci mon tazounet (y va adorer, vous allez voir )
 
comme dit hdsdi : et sous kde ?

 
Ben disons que ca existe sans doute qq part pour permettre aux explorateurs de fichiers de kde/gnome (konqueror/nautilus ?) de savoir quoi faire en cas de double-click. Maintenant si un kde user installe rox-filer (par exemple) ben ce dernier ne connaitra aucun type MIME je pense... Il doit y avoir autant de façon de gérer les MIME qu'il y a d'explorateurs de fichiers    
Et en plus il y a des users (dont moi) qui n'utilisent pas d'explorateurs de fichiers sous linux...
 
Bref c'est pas gagné ce truc

c'est pour ça que je maintiens que l'idée de la BDR de Windows est une très bonne idée, que ce soit centralisé dans une fonction du kernel ne me choquerais pas.
 
j'imagine un truc (comme ça se passe sous windows) qui ferais ça :
-> à l'install d'un programme, ou par ligne de commande : ajout d'une entrée extension/type-mime si non exitante, puis une entrée gui/type-mime/application
 
et ensuite, de façon centralisée, depuis n'importe quel UI (console, x, etc.) appel d'une fonction getappforextension, qui permettrait de retrouver la liste des applications enregistrées comme capable de lire le type mime associé à l'extension, pour la UI courrante.
 
je ne dis pas que c'est au kernel de "gérer" ça, mais simplement de centraliser cette information et permettre sa mise à jour / consultation via des commandes shell ou des appels type "api" (je sais pas comment c'est sous nux, mais j'imagine qu'il y a un équivalent)
 
après, je suppose qu'un simple deamon peut aussi s'en occuper, si l'idée de coller ça directement dans le kernel vous choque...
 
en fait, je parle d'un truc qui reprendrais le principe de ce web service pour windows :
 
http://shell.windows.com/fileassoc [...] sp?EXT=doc
=> avec en plus de l'extension, envoi d'un code correspondant à la UI appelante
 
ça pourrait d'ailleurs être avantageusement couplé aux moteurs de gestion de package type "apt" : ça te trouve la liste des appli connues qui permettent d'ouvrir ce type de fichier. si t'as pas, ça te propose les listes de packages nécessaires pour installer les applis registrée.

la centralisation et la mise à jour, ça existe déjà :
http://freedesktop.org/wiki/Standa [...] nfo_2dspec

ah ben voilà
 
par contre, il gère le multi-environnement, comme j'ai suggéré ?
ce serait peut-être un truc à leur indiquer s'ils n'y ont pas déjà pensé
 
genre, au lieu que le prog soit spécifique à la UI utilisée, qu'il tourne en tant que deamon et permette de retourner le path de l'appli qui tourne dans la UI en cours d'utilisation (passée en paramètre)

genre ça (a priori, pas encore implémenté) :
http://freedesktop.org/wiki/Standards_2fconfig_2dspec
 
voir là aussi :
http://freedesktop.org/wiki/Standa [...] ons_2dspec

 
(comme quoi ce que je proposais, c'était pas si débile )

non car utile, mais la façon de l'implementer dans le kernel etait un très mauvaise idée  

Je up ce vieux topic pour rajouter un truc un peu en rapport avec la problématique évoquée ici...
 
Sur les kernel 2.2.X, on pouvait déclarer un nouveau type d'exécutable en tweakant un peu le kernel...
 

 
Après en ajoutant une commande du type :

dans  

avec :
nom : le nom donné au type d'exécutable
déterminant : M (l'identification se fait sur le début du fichier) ou E (sur l'extension du nom du fichier)
magic : si M, le contenu du début du fichier ; si E, l'extension
interpréteur : le programme à utiliser
 
on pouvait créer ses propres types d'exécutables.
 
Exemple d'un "exécutable html" :  

 
Je ne sais pas trop ce que c'est devenu sous les 2.4.X et 2.6.X par contre  

Je crois que j'ai trouvé ton bonheur... xdg-utils (le projet portland) contient xdg-open qui est indépendant du desktop-manager(gnome,kde...)