Création d un raccourci pour /home

Bonjour,

J ai installé manjaro lxde sur le Pc de ma tante, grande débutante en GNU/Linux et afin de lui faciliter la tâche je souhaiterai pourvoir créer un raccourci pour son /home directement sur le bureau.

Effectuant moi même la modification, aucun soucis s il s'agit de modifier des fichier de configuration via le terminal.

Merci d avance.

qu'est-ce qui gère le bureau pour le moment sur cette version ? Nitrogen ou Pcmanfm ?

si c'est Nitrogen, il va falloir s'en débarrasser et le remplacer par Pcmanfm; et si c'est déjà Pcmanfm qui gère le bureau, il me semble qu'il suffit juste de glisser le dossier et de cliquer sur "lier ici" (ou un truc du genre); en plus "barbu", il y a aussi la possibilité de créer un fichier *.desktop dans le répertoire ~/Bureau.

C'est pcmanFM qui gère la gestion de fichier. Le raccourci installé à la nom de pcmanfmgestionnaire de fichier, pas très user friendly, non ? :rigole:

J'ai eu beau essayer de renommer le raccourci rien a faire.

Après créer un raccourci qui ouvre une fenêtre en graphique j'avoue que je ne sais pas faire.

ouvre ce raccourci avec ton éditeur de texte, tu pourras modifier le titre à ta guise

ln -s 'cible' 'destination du raccourci'

?
J'avoue que j'ai du mal avec les .desktop

Otyugh a écrit :
ln -s 'cible' 'destination du raccourci'
?
J'avoue que j'ai du mal avec les .desktop

un petit topo sur les .desktop :
http://doc.ubuntu-fr.org/raccourci-lanceur

Je voulais dire, je n'en saisit pas l’intérêt pratique par rapport à un lien symbolique ou à un petit script d'une ligne ^^
J'ai l'impression que ça ajoute en complexité pour quelque chose qui se fait aussi avec des outils plus primitifs (qui servent après en plus !).

Je comprends, disons que de plus en plus, les scripts que tu déclare au demarrage se transforment en .desktop automatiquement.
J'ai le cas avec conky sous gnome-shell, dont ma commande

sh -c "sleep 2 && (conky &)"

déclarée dans gnome session (la gestion des programmes de demarrage) se transforme automatiquement depuis la dernière mise à jour en une belle grosse entrée dans mon dock comme programme en cours d'activité (ce qui est moche et inutile)
Bref, je me prends la tête avec NotShowIn, Hidden, NoDisplay pour avoir le programme qui tourne mais pas d'icone dans gnome.
je vais pas créer un service systemd pour conky, quand même ! encore que.... :rigole:

mais tout ceci est un autre sujet.. :sourire:

Otyugh a écrit :Je voulais dire, je n'en saisit pas l’intérêt pratique par rapport à un lien symbolique ou à un petit script d'une ligne ^^
J'ai l'impression que ça ajoute en complexité pour quelque chose qui se fait aussi avec des outils plus primitifs (qui servent après en plus !).

l'intérêt technique est différent...
un lien symbolique créé avec "ln -s" est en dur au niveau du système de fichier; c'est une redirection d'une certaine façon...
un fichier *.desktop est un lanceur; il ouvre une url (locale vers un fichier dans ce cas) avec le logiciel adapté à ce que ça doit ouvrir (explorateur de fichiers si c'est un dossier).
une différence de comportement flagrante entre les deux est que le lien est ouvert dans la même fenêtre de l'explorateur, alors que le *.desktop est ouvert dans une nouvelle fenêtre.
une autre différence est que le *.desktop ne sert plus à rien en ligne de commande (un vulgaire fichier texte) alors que le lien donne accès à sa cible; j'ai créé sur mon bureau (donc dans le répertoire ~/Bureau) un *.desktop et un lien vers un dossier de mon home nommé ~/Dessin:

[david@asus-aio ~]$ cd Bureau/
[david@asus-aio Bureau]$ ls | grep Dessin
Dessin@
Dessin.desktop*

si je veux aller dans ~/Dessin via Dessin.desktop:

[david@asus-aio Bureau]$ cd Dessin.desktop 
bash: cd: Dessin.desktop: N'est pas un dossier

marche pô
mais avec le lien:

[david@asus-aio Bureau]$ cd Dessin/
[david@asus-aio Dessin]$ pwd
/home/david/Bureau/Dessin
[david@asus-aio Dessin]$ ls
esquisse1.jpg  esquisse2.jpg  manjaro.png
[david@asus-aio Dessin]$ cd ..
[david@asus-aio Bureau]

je peux entrer dedans; le lien laisse penser que /Dessin est dans /Bureau; le contenu correspond bien à celui de ~/Dessin; et quand je remonte au répertoire parent, je suis à nouveau dans /Bureau...

sinon, pour faire un fichier home.desktop facilement, voici un modèle:

[Desktop Entry]
Version=1.0
Type=Link
Name=Home
Comment=Dossier personnel
Icon=user-home
URL=file:///home/toto

en remplaçant "toto" par le nom de l'utilisateur, et pour le bureau, il faut que ce soit éxécutable.

Loubrix a écrit :l'intérêt technique est différent...

Quel différence entre ton exemple et un script bash qui dirait "file-browser /home" ?

disons qu'en faisant ça avec un script, tu crées un troisième moyen pour ouvrir l'explorateur de fichiers alors que je t'en ai déjà montré 2 natifs: inutile de réinventer la roue

en plus n'oublie pas que le Bash est un langage interprété, donc tout ce que tu lui fais faire est forcément moins rapide qu'un programme compilé, même si sur les machines modernes ça ne se voit plus beaucoup, et que sur une fonction aussi simple ce n'est pas flagrant non-plus...

quoiqu'il en soit, le meilleur moyen, c'est celui qui te convient: ça c'est la force du libre :bien

Merci pour vos réponses : 3 solutions donc, j'aurai appris plein de truc.

je passerai en résolu une fois appliqué sur le bureau de ma tante :salut:

Loubrix a écrit :Bash est un langage interprété, donc tout ce que tu lui fais faire est forcément moins rapide qu'un programme compilé

On utilise souvent bash pour faire appel à d'autres programmes qui eux, sont compilés (cd, mv, ou rm ; par exemple c'est du C, il me semble). Et à moins que je rate quelque chose, ceux-là sont toujours aussi rapide.
Du coup si les instructions interprétées sont lentes, je pense que pour une instruction bash, l'ordre doit être inférieur à 1ms de traitement, même sous les modèles les plus antiques qui soient. Non ?

(je n'insiste pas vraiment pour avoir raison, mais si tu peux lever mes doutes tant mieux, sinon c'est des détails, très clairement).

effectivement, les programmes comme cd, mv ou rm sont compilés, et c'est bien du C.

un ordinateur ne comprend qu'une seule chose: le langage binaire.
les langages de programmation existe pour compenser le fait que les humains sont incapables d'assimiler le binaire.

certains langages sont compilés une bonne fois pour toutes et installés sur le système sous forme de fichiers éxécutables en binaire; suivant la taille du (ou des) binaire résultant, la compilation peut-être longue.

pour les langages interprétés, il sont installés sous forme de fichiers textes dans un langage compréhensible; dire qu'ils sont interprétés signifie qu'ils sont compilés à la volée à chaque éxécution (puisque rappelons le, l'ordinateur ne comprend que le binaire).
sur un programme de deux ou trois instructions, ça n'a guère d'incidence, mais quand il y a des centaines d'instructions, ça prend un peu plus d'importance; il suffit de regarder la vitesse de fonctionnement de Yaourt, pourtant un très bon programme, mais qui vu sa taille actuelle, mériterait d'être ré-écrit en C (ou au moins dans un interprété plus rapide, comme Python).
parce qu'il y a ça aussi: dans les langages interprétés, certains sont plus rapides que d'autres; et là dedans, Bash est considéré comme très lent.
c'est pour ça qu'il vaut mieux y avoir recours uniquement quand on n'a pas le choix...