Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [cdt-dev] LaunchConfigurations: Starting a debug process as root

Oh, something I realize now: 

I was actually thinking about extending org.eclipse.cdt.launch.internal.LocalRunLaunchDelegate because it does almost all I want.
But extending the LocalRunLaunchDelegate is bad style because it comes from an internal package. 

The AbstractCLaunchDelegate on the other hand does not implement launch() so I can do whatever I want to do the the program name and arguments when implementing it for my own launch delegate. Hmmmm

So I pretty much answered my own question. I am still interested in feedback, e.g. on whether there are simpler ways to get my debug process started as root.

Thanks,


Norbert 


-----Ursprüngliche Nachricht-----
Von: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ploett, Norbert
Gesendet: Mittwoch, 25. Januar 2006 12:36
An: CDT General developers list.
Betreff: [cdt-dev] LaunchConfigurations: Starting a debug process as root

Hi there,
 
can somebody help me with this: We are creating our custom launch
configuration. The launch configuration delegate extends
org.eclipse.cdt.launch.AbstractCLaunchDelegate. 

When the user checks a button the new process should be started with
root privileges. My scheme for doing this (which will of course only
work on Linux) was to modify the command line so that the program is
started with sudo:

(Normal launch)
/mypath/myapplication arg1 arg2 argn

(root launch)
sudo /mypath/myapplication arg1 arg2 argn

This requires that 
- the program name is set to "sudo"
- the original program name becomes the first command line parameter
- all other parameters are shifted

The parameter stuff is no problem: I can override
AbstractCLaunchDelegate.getProgramArguments() to prepend the original
program name to the arguments string.

The program name however comes (ultimately) from the static method
AbstractCLaunchDelegate.getProgramName() which I cannot override. 

Now since AbstractCLaunchDelegate is designed to be a class that should
be widely usable for people who want to implement their own launch
delegates, wouldn't it be useful if there were overrideable _instance_
methods for the stuff which is read from the configuration. This would
allow for fiddling with all aspects of the standard configuration
properties if that is needed? As it is the case with
getProgramArguments()?

Any opinions on that? Or another, simpler way to achieve what I want to
do?

Thanks for reading this far :-)


Norbert Ploett
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top