Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Kwrite sudoedit <un_fichier> → ouvre 2 fenêtres ?

Coeur Noir

Hello,

Constatez-vous le même comportement : lancer un

kwrite sudoedit un_fichier

ouvre 2 fenêtres de kwrite
- l'une sur le un_fichier en question,
- l'autre sur un nouveau document vide.

Suis sous KDE-neon user edition…

Ça ressemble à un bug qui existait y a longtemps avec gedit… où signale-t-on ce genre d'anomalie ?

[edit] là → https://bugs.kde.org/show_bug.cgi?id=381756

Alex10336

Effectivement:

RESOLVED INVALID

Je comprend pas d'où vient le « kwrite sudoedit un_fichier » d'ailleur 😉

Coeur Noir

Hé, hé, la blague, ça va mieux en faisant :

SUDO_EDITOR=kwrite sudoedit un_fichier

Alex, comment je suis tombé là-dessus, euh, j'ai du vouloir lancer un

kdesudo kwrite <fichier>

et obtenu un message que j'ai mal lu, du genre :

Executing Kwrite as root is not possible. To edit files as root use:
SUDO_EDITOR=Kwrite sudoedit <file>

Éxécuter des appli's graphiques en root c'est mal https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/ d'où cette nouvelle façon de faire.

Par ailleurs en ouvrant simplement le fichier via un double clique, kwrite s'ouvre en mode normal et à la tentative d'enregistrer les modifications, il demande le mot de passe root.
Ce qui est encore plus simple.

Fly0s

Ah mais c'est super pratique comme ça en fait ! Moi qu'était tout content qu'openSUSE patche Kate/Kwrite pour qu'il utilise l'ancien comportement, je préférerai vachement avoir à rentrer le mot de passe au moment de l'écriture, c'est vachement plus logique.

abecidofugy

Vim caymieux 😉

Sérieux, éditer en mode graphique, ça implique trop de risques de taper un signe de trop…

Fly0s

Perso, j'utilise toujours la ligne de commande pour modifier les fichiers en root (quitte à devoir lancer un truc en ligne de commande, autant y rester), mais je vois pas bien en quoi y a plus de risque de taper un signe de trop en GUI par rapport à un CLI ? Les risques portent surtout sur la sécurité en lien avec la passoire qu'est le serveur X.

EDIT : J'ai mal formulé, c'était une question. Modifié.

Coeur Noir

Fly0s a écritAh mais c'est super pratique comme ça en fait ! Moi qu'était tout content qu'openSUSE patche Kate/Kwrite pour qu'il utilise l'ancien comportement, je préférerai vachement avoir à rentrer le mot de passe au moment de l'écriture, c'est vachement plus logique.

Reste à voir si c'est le nouveau comportement par défaut, ou si c'est parce que j'ai lancé kwrite au préalable, préfixé de SUDO_EDITOR.

Pas compris non plus la remarque sur « taper un signe de trop » : gui ou cli, les mêmes doigts trop gros sur mon clavier produiront les mêmes gaffes non ?

abecidofugy

Non, avec vim on n'est pas en mode édition par défaut. Il faut taper sur i avant d'insérer un caractère.

Fly0s

Héhé, précisément ce qui me saoule avec vim ! 😉 Mais je vois ce que tu veux dire (ça n'a pas grand-chose à voir avec GUI/CLI du coup).

Coeur Noir

Kåre Särs a écritThat asking for password before saving is a _very_ recent feature of KIO from the KF5 libraries 🙂

C'est donc confirmé, comportement normal, simple et rapide. Pourvu que ça se généralise en dehors de KDE !

Alex10336

abecidofugy a écritVim caymieux 😉

Sérieux, éditer en mode graphique, ça implique trop de risques de taper un signe de trop…

nano cayplusimp ! 😛

Coeur Noir

vim, nano… selon les besoins, genre on passe la plupart de son temps sur terminal. C'est pas forcément plus simple ou plus intuitif ( les ctrl + ci ou ça, taper i pour insérer… bah oui si j'ai ouvert ce fichier c'est peut-être parce que je veux y faire une modification après tout )

Là ce que propose kde-neon c'est super cohérent, sans jamais passer par un terminal : clic sur fichier, il s'ouvre dans kwrite, tu modifies, tu enregistres. Si c'est un fichier root il demande le mot de passe. J'vois pas comment faire plus simple et à mon niveau ça suffit largement pour modifier fstab ou grub ou un sources.list

Je trouve même étonnant qu'une telle simplicité n'ait pas déjà été mise en place plus tôt - en arrière-plan c'est peut-être pas simple du tout mais pour l'utilisateur c'est des étapes en moins, pas besoin d'ouvrir un terminal pour lancer une appli en mode root, on reste en espace utilisateur sans risque.