Can't use --nofork for KUniqueApplications from another kde process

[Robert Knight]

>  Attached to that bug report (and included below) is a script
> which seems to work-around the problem, albeit it doesn't exactly
> meet your requiremsnts.

If Konsole is started from a terminal with the --nofork argument it
should work - since
Konsole will register itself with D-Bus in such a way that it won't
cause any conflicts.

Having said that, the best way to implement this would be to patch
Konsole itself so that
it has an option to behave as you would like, an option mind you.  The
behavior makes sense
when, as most people do, you start Konsole from some GUI shortcut.

Regards,
Robert.

2009/1/12 Brian Foster <brian.foster at innova-card.com>:
>
>  | I'm trying to implement the "run in external terminal" feature for
> kdevelop,
>  | basically the aim is to be able to launch a new konsole with the user's
>  | program running inside it.
>  |
>  | However, I want to run konsole with --nofork, so that kdevelop remains
>  | associated with the konsole, can track the life of the running program,
> and
>  | can kill it if desired.
>  |
>  | It works fine without passing --nofork to konsole, and works if there's
> no
>  | other konsole process running, but if there's another konsole running,
> it
>  | fails with the message "KUniqueApplication: Can't setup D-Bus service.
>  | Probably already running."  [ ... ]
>
> Hamish,
>
>   I just upgraded to Kubuntu 8.10 (and hence to KDE 4.1), and ran
>  into what seems to be the same issue with the "external editor"
>  feature in Kmail.  Please see "Bug 169092: text entered in external
>  editor [ ...]", https://bugs.kde.org/show_bug.cgi?id=169092
>
>   Attached to that bug report (and included below) is a script
>  which seems to work-around the problem, albeit it doesn't exactly
>  meet your requiremsnts.  In particular, killing the script won't
>  actually kill either Konsole or the program being run by Konsole.
>  (It ought to be possible to modify it to do so, albeit I myself
>  currently have no interest in designing/implementing/testing
>  such a change.)
>
> cheers!
>        -blf-
>
> =====(cut here and below)===== kons =====(--nofork work-around)=====
> #!/bin/bash
> #
> # kons  — Work-around KDE 4 / Konsole asynchronous silliness
> #
> # Version 2009.01-blf (YYYY.MM-INITIALS).
> # Created by Brian Foster <brian.foster at innova-card.com>
> # Released under the GPL.
> #
> # KDE 4 / Konsole is asynchronous.  That is, 'konsole -e COMMAND' exits
> # immediately instead of when the terminal session completes (as was
> # the case in KDE 3, and still is the case with other terminaks, such
> # as xterm(1)).  Consequently, it's hard to determine when <COMMAND>
> # completes, which is something that is often required (e.g., when
> # <COMMAND> is an "external editor" for Kmail or similar).
> #
> # In theory, the '--nofork' option prevents this, but that's unreliable,
> # often resulting in the opaque complaint (the '4763' is the PID of some
> # process (not sure what process?)):
> #
> #       <unknown program name>(4763)/: KUniqueApplication: Can't setup D-Bus
> service. Probably already running.
> #
> # Hence this script, which attempts to run Konsole synchronously.
> # The usage is (intended to be) identical to Konsole.  The script does
> # not exit until the <COMMAND> exits.  Furthermore, the exit status is
> # nominally that of <COMMAND>.  Hence, instead of:
> #
> #       konsole -e COMMAND
> #
> # simply using (<SCRIPT> is the name of this script, e.g., 'kons'):
> #
> #       SCRIPT -e COMMAND
> #
> # works-around the KDE 4 asynchronous Konsole problem.
> #
>
> while [ $# -ne 0 ]; do
>        case $1 in
>        -e)     shift
>                break
>                ;;
>        *)      opts=( "${opts[@]}" "$1" )
>                shift
>                ;;
>        esac
> done
>
> tdir=$(umask 077; mktemp -d)  ||  exit
> fifo=$tdir/$$
> mkfifo -m600 -- "$fifo"  ||  {
>        sts=$?
>        rm -rf -- "$tdir"
>        exit $sts
> }
>
> exec 7<>"$fifo"  ||  exit
> rm -rf -- "$tdir"
>
> [ $# -eq 0 ] && set -- exec "${SHELL:-bash}"
>
> konsole "${opts[@]}" -e bash -c '
> # For debugging, uncomment the following statement ('set -x').
> # Also, when debugging, using --hold ('kons --hold -e ...') is recommended.
> ###     set -x
>        pid=$1
>        shift
>        ( exec 7>&-; unset pid; eval "$@" )
>        sts=$?
>        echo $sts >&7  ||  kill $pid
>        exit $sts
> ' -- $$ "$@"
>
> read -u7 sts  ||  sts=$?
> exit $sts
> =====(cut here and above)===== kons =====(--nofork work-around)=====
>
> --
> View this message in context: http://www.nabble.com/Can%27t-use---nofork-for-KUniqueApplications-from-another-kde-process-tp21047022p21411819.html
> Sent from the kde-core-devel mailing list archive at Nabble.com.
>
>