Hi,
I can’t find out how to retrieve (from code) the command-line arguments
of a process just like sin with format a does? Could anyone please give
me some hints?
Thanks
chris
chris <sscanf@usa.net> wrote:
Hi,
I can’t find out how to retrieve (from code) the command-line arguments
of a process just like sin with format a does? Could anyone please give
me some hints?
It is messy, inconsistent, and not guaranteed to work perfectly. (And,
uses undocumented interfaces.)
What are you trying to achieve/why do you need this?
-David
QNX Training Services
dagibbs@qnx.com
I can’t find out how to retrieve (from code) the command-line arguments
of a process just like sin with format a does? Could anyone please give
me some hints?It is messy, inconsistent, and not guaranteed to work perfectly. (And,
uses undocumented interfaces.)Good lord, that’s too much of good properties >
What are you trying to achieve/why do you need this?Nothing urgent, just polish up an application on an embedded device with
a developer view of running processes. Also I was curious how this sort
of thing is implemented.
Thanks for your answer, David.
chris
What is it you want to access about your running processes?
I once wrote a ‘sin’ type of program. It was able to display just about
everything that sin does except 'fi’les, 'fd’file descriptors and 'me’mory.
This was written way back when QSSL was still debugging the Fsys.aha7scsi
driver. Out system would occasionally go into a state where the driver
locked up. The rest of the system wouldn’t do disk IO and so wouldn’t load
new programs. My sin load and just stayed resident, looping once every
second. A single keystroke would change the format of the screen. But it
was nice because it was already loaded. So when the disk driver locked up
we could see what was blocked on what.
P.S. No. I don’t have the source code. It stayed at a former employer,
dang-it. But let me know what you want to see and I can give you a code
fragment to see it.
–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
“chris” <sscanf@usa.net> wrote in message news:3B147C8B.489CDF89@usa.net…
I can’t find out how to retrieve (from code) the command-line
arguments
of a process just like sin with format a does? Could anyone please
give
me some hints?It is messy, inconsistent, and not guaranteed to work perfectly. (And,
uses undocumented interfaces.)Good lord, that’s too much of good properties >
What are you trying to achieve/why do you need this?
Nothing urgent, just polish up an application on an embedded device with
a developer view of running processes. Also I was curious how this sort
of thing is implemented.Thanks for your answer, David.
chris
chris <sscanf@usa.net> wrote:
I can’t find out how to retrieve (from code) the command-line arguments
of a process just like sin with format a does? Could anyone please give
me some hints?It is messy, inconsistent, and not guaranteed to work perfectly. (And,
uses undocumented interfaces.)Good lord, that’s too much of good properties >
What are you trying to achieve/why do you need this?
Nothing urgent, just polish up an application on an embedded device with
a developer view of running processes. Also I was curious how this sort
of thing is implemented.
If you can live with popen(“sin ar”) and parse the output, that would
probably be your best choice.
If not, well, it gets into knowing where in “Magic” memory for you
process those arguments are stored, and then using __qnx_debug_xfer()
to get that memory.
As to why it may not work perfectly – some programs modify the memory
the arguments live in as they parse the arguments, so the best you can
get is what currently resides in that memory, rather than what command
line arguments they were actually started with.
-David
QNX Training Services
dagibbs@qnx.com
OK. Yes. I see the SUbject line of this message now. Sin 'ar’guments is
one of those that I never implemented. And yes, it is tricky at best.
Use popen( “sin ar” );
–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
“Bill Caroselli” <Bill@Sattel.com> wrote in message
news:9f32a9$o5s$1@inn.qnx.com…
What is it you want to access about your running processes?
I once wrote a ‘sin’ type of program. It was able to display just about
everything that sin does except 'fi’les, 'fd’file descriptors and
'me’mory.
This was written way back when QSSL was still debugging the Fsys.aha7scsi
driver. Out system would occasionally go into a state where the driver
locked up. The rest of the system wouldn’t do disk IO and so wouldn’t
load
new programs. My sin load and just stayed resident, looping once every
second. A single keystroke would change the format of the screen. But it
was nice because it was already loaded. So when the disk driver locked up
we could see what was blocked on what.P.S. No. I don’t have the source code. It stayed at a former employer,
dang-it. But let me know what you want to see and I can give you a code
fragment to see it.–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
“chris” <> sscanf@usa.net> > wrote in message
news:> 3B147C8B.489CDF89@usa.net> …I can’t find out how to retrieve (from code) the command-line
arguments
of a process just like sin with format a does? Could anyone please
give
me some hints?It is messy, inconsistent, and not guaranteed to work perfectly.
(And,
uses undocumented interfaces.)Good lord, that’s too much of good properties >
What are you trying to achieve/why do you need this?
Nothing urgent, just polish up an application on an embedded device with
a developer view of running processes. Also I was curious how this sort
of thing is implemented.Thanks for your answer, David.
chris
Would it possible to this by implementing one’s own
sh, which captures this info, and then call the real sh?
chris wrote:
I can’t find out how to retrieve (from code) the command-line arguments
of a process just like sin with format a does? Could anyone please give
me some hints?It is messy, inconsistent, and not guaranteed to work perfectly. (And,
uses undocumented interfaces.)Good lord, that’s too much of good properties >
What are you trying to achieve/why do you need this?
Nothing urgent, just polish up an application on an embedded device with
a developer view of running processes. Also I was curious how this sort
of thing is implemented.Thanks for your answer, David.
chris
Alex <acellarius@systems104.co.za> wrote:
Would it possible to this by implementing one’s own
sh, which captures this info, and then call the real sh?
Wouldn’t be particularly general – wouldn’t catch stuff started
in the boot image, wouldn’t catch stuff started with spawn(), etc.
-David
QNX Training Services
dagibbs@qnx.com