Le lundi 12 août 2024, 15:44:51 UTC Russ Allbery a écrit : > Simon McVittie <s...@debian.org> writes: > > > The approach to this that will work consistently is to launch the > > handler asynchronously (in the background), and not attempt to find out > > whether it has exited or not. So for example an interactive shell script > > might do something like this: > > > #!/bin/bash > > # note that disown is a bashism > > > xdg-open "$document" & > > disown $! > > echo "Press Enter when you have finished editing $document..." > > read > > What this is telling me is that ideally someone should tighten the > definition of EDITOR in Policy 11.4, which is the specification satisfied > by sensible-editor, to make it clear that GUI editors with these sorts of > properties are not valid things to set EDITOR to point to unless flags are > present to make them behave in a way that satisfies the expectations of > programs that use EDITOR.
Yes and what why I ask to add sensible-editor wrapper. At least it will do something sensible and it is optional Bastien > > I don't have any strong opinion on the merits of trying to figure out how > to invoke the editor with the proper flags to make it follow the > expectations of EDITOR if EDITOR is not set, but we do need to be careful > to not invoke programs that would cause, e.g., git commit --amend to > immediately exit with no changes to the commit message, and to do that we > probably need to write down what those expectations are. I think the > Policy language was written in a time where we just assumed there was an > obvious way for editors to behave that didn't include things like > backgrounding themselves. > >
signature.asc
Description: This is a digitally signed message part.