Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #7131 > unrolled thread

Who knows `ps` well?

Back to article view | Back to comp.os.linux.misc

Contents

  Who knows `ps` well? Avoid9Pdf@gmail.com - 2013-01-29 08:53 +0000
    Re: Who knows `ps` well? J G Miller <miller@yoyo.ORG> - 2013-01-29 14:00 +0000
      Re: Who knows `ps` well? J G Miller <miller@yoyo.ORG> - 2013-02-02 17:10 +0000
      Re: Who knows `ps` well? Avoid9Pdf@gmail.com - 2013-02-03 13:11 +0000
        Re: Who knows `ps` well? J G Miller <miller@yoyo.ORG> - 2013-02-03 15:06 +0000
          Re: Who knows `ps` well? Avoid9Pdf@gmail.com - 2013-02-05 09:36 +0000
            Re: Who knows `ps` well? J G Miller <miller@yoyo.ORG> - 2013-02-05 15:17 +0000
              Re: Who knows `ps` well? Avoid9Pdf@gmail.com - 2013-02-06 18:50 +0000
              Re: Who knows `ps` well? Avoid9Pdf@gmail.com - 2013-02-07 05:14 +0000
                How to use wmctrl to switch to a window on another workspace with an EMWH compliant window manager J G Miller <miller@yoyo.ORG> - 2013-02-07 15:58 +0000
    Re: Who knows `ps` well? Chris Davies <chris-usenet@roaima.co.uk> - 2013-01-29 17:19 +0000
    Re: Who knows `ps` well? Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2013-02-05 08:09 -0800

#7131 — Who knows `ps` well?

Actually `ps` and related utilities that can help show:
 which workSpace/s [in X] have got a running `links`.

Can someone improve/add-to this?

Which W,C has got links:
->  lsof | grep links | grep CHR == show 3 links open == `pgrep links` is better

=> Does /proc/<PID> know the (worksSpace,Console) of a process?

->  lsof | grep links | grep  CHR | grep  0u ==
links      5531       root    0u      CHR     136,25                 28 /dev/pts/25
links      5570       root    0u      CHR      136,4                  7 /dev/pts/4 (deleted)
links      7153       root    0u      CHR     136,28                 31 /dev/pts/28

->  lsof | grep links | grep  CHR
== shows the 4 copies of `links`
COMMAND     PID       USER   FD      TYPE     DEVICE    SIZE       NODE NAME
links      5531       root    0u      CHR     136,25                 28 /dev/pts/25
links      5570       root    0u      CHR      136,4                  7 /dev/pts/4 (deleted)
links      7153       root    0u      CHR     136,28                 31 /dev/pts/28
links     10296       root    1u      CHR     136,36                 39 /dev/pts/36

PS. I don't know the details of what I'm doing.
But hopefully the fields: DEVICE, NAME can point to the WorkSpace.

In KDE3: `pstree -p` showed it, because the Consoles of each Workspace
were shown as grouped.

Please help.

== TIA.

[toc] | [next] | [standalone]

#7133

On Tuesday, January 29th, 2013, at 08:53:44h +0000, Chris Glurr burbled:

> Actually `ps` and related utilities that can help show:
>  which workSpace/s [in X] have got a running `links`.

ps cannot tell you on which desktop workspace an application is running.

ps has no concept of X11, desktops, or workspaces.

One of the few things which can indicate how to get to a workspace
with a particular running application is the desktop/window manager
"show windows" menu, and only if the application is of course an X11
application, not something running within an X terminal emulator.

> I don't know the details of what I'm doing.

That has been obvious to most discerning readers of your postings
for a long time.

> But hopefully the fields: DEVICE, NAME can point to the WorkSpace.

No they cannot do that directly.

[toc] | [prev] | [next] | [standalone]

#7167

On Tue, 29 Jan 2013 14:00:04 +0000, J G Miller wrote:

> One of the few things which can indicate how to get to a workspace
> with a particular running application is the desktop/window manager
> "show windows" menu, and only if the application is of course an X11
> application, not something running within an X terminal emulator.

If you are prepared to start your links in an X terminal emulator which
uses a distinctive application name (eg links or links-1, links-2 etc
for multiple occurrences) you could then find the window using the method
outlined at

    <http://urukrama.wordpress.COM/category/dmenu/>

using wmctrl assuming a compliant window manager.

[toc] | [prev] | [next] | [standalone]

#7185

In article <ke8kl2$nau$3@dont-email.me>, J G Miller <miller@yoyo.ORG> wrote: 

> On Tuesday, January 29th, 2013, at 08:53:44h +0000, Chris Glurr burbled:
> 
> > Actually `ps` and related utilities that can help show:
> >  which workSpace/s [in X] have got a running `links`.
> 
> ps cannot tell you on which desktop workspace an application is running.

Not DIRECTLY. It requires some thought/effort.
> 
> ps has no concept of X11, desktops, or workspaces.
> 
Mandrake 9: KDE3: `pstree -p` shows
the VTs grouped per Desktop.
`pgrep links` shows all links; but isn't needed since you can SEE
the links [and any other pid] on the 'branch' of pstree.

I wrote a script to list the <path> of all `mc`, as explained further below.
   lsof | grep <pid of mc>
lead to the list of <mc paths>.

Then later versions of KDE couldn't use it.
 
> One of the few things which can indicate how to get to a workspace
> with a particular running application is the desktop/window manager
> "show windows" menu, and only if the application is of course an X11
> application, not something running within an X terminal emulator.
> 
> > I don't know the details of what I'm doing.
> 
> That has been obvious to most discerning readers of your postings
> for a long time.
> 
If you're a stalker, you may want to go to the kiddies SOCIAL network.
This forum is for adults to exchange TECHNICAL info independant of 
names and personalities.

> > But hopefully the fields: DEVICE, NAME can point to the WorkSpace.
> 
> No they cannot do that directly.
We're not expecting a DIRECT answer, like you'd get from the 'man'
==========
Chris Davies writes:-

> You could try something like "xwininfo -name links" and see if you
> can derive any information from the geometry fields (Absolute position
> vs Corners). The other one to try is "xwininfo -root -tree". But since
> I don't know what you're trying to achieve it's pretty difficult to give
> a specific answer.

That's seems interesting for other puposes.

Here's what's trying to be achieved.
To know which book and page knows about a topic-type.

Or:
your work-room has 4 columns and 6 rows of work-benches.
When you start, with no work-benches equiped, a
Japanese task arrives. You call out the door for a Japanes-translator,
  who comes in and takes up any random free work-bench.
When a Spanish task arrives, you want to know if/where any
Spanish-translator are located, to pass the task to.
Etc. for each type of task. 

In computing work-flow-terms, you don't want to launch a new
mc on <pathN>, when there's already one available.

Obviously the system knows what proccesses are running.
And `ps` is the heart of that knowledge.
And `lsof` is the center of knowledge of what <paths> any
process may be 'looking-at'.

[toc] | [prev] | [next] | [standalone]

#7188

On Sunday, February 3rd, 2013, at 13:11:09 +0000, Avoid9Pdf warbled:

> In article <ke8kl2$nau$3@dont-email.me>, J G Miller <miller@yoyo.ORG> wrote: 
> 
>> On Tuesday, January 29th, 2013, at 08:53:44h +0000, Chris Glurr burbled:
>> 
>> > Actually `ps` and related utilities that can help show:
>> >  which workSpace/s [in X] have got a running `links`.
>> 
>> ps cannot tell you on which desktop workspace an application is running.
> 
> Not DIRECTLY. It requires some thought/effort.
>> 
>> ps has no concept of X11, desktops, or workspaces.
>> 
> Mandrake 9: KDE3: `pstree -p` shows
> the VTs grouped per Desktop.

pstree is not ps

Since pstree does not know what a desktop is, I suggest
that the grouping was fortuitous due to the order of
starting each X terminal emulator on those desktops.

[toc] | [prev] | [next] | [standalone]

#7200

In article <kelucv$ov4$1@dont-email.me>, J G Miller <miller@yoyo.ORG> wrote: 

> On Sunday, February 3rd, 2013, at 13:11:09 +0000, Avoid9Pdf warbled:
> 
> > In article <ke8kl2$nau$3@dont-email.me>, J G Miller <miller@yoyo.ORG> wrote: 
> > 
> >> On Tuesday, January 29th, 2013, at 08:53:44h +0000, Chris Glurr burbled:
> >> 
> >> > Actually `ps` and related utilities that can help show:
> >> >  which workSpace/s [in X] have got a running `links`.
> >> 
> >> ps cannot tell you on which desktop workspace an application is running.
> > 
> > Not DIRECTLY. It requires some thought/effort.
> >> 
> >> ps has no concept of X11, desktops, or workspaces.
> >> 
> > Mandrake 9: KDE3: `pstree -p` shows
> > the VTs grouped per Desktop.
> 
> pstree is not ps
> 
`ls` is not `ls -l`; `fdisk` is not `cfdisk`; try to see the ESSENCE

> Since pstree does not know what a desktop is, I suggest
> that the grouping was fortuitous due to the order of
> starting each X terminal emulator on those desktops.
> 
`pstree`knows the pid of `xinit`, which leads to knowledge of the total
total status of the desktop.

Yes, IIRC <kde> spawned N processes [which weren't even ordered
per workspace ordering, so I had to use heuristics like: the branch
with 4 terminals and process 'dog' is workspace3];
one per workspace, where each grouped its terminals together.

This is not a HOW2 query, which is answered directly from the `man`.
Which W,T has got processP active on pathD may be approached by:
=> where is the knowledge of all processes == `ps`
=> where is the knowledge of all paths in use == `lsof`

So the intersection of the 'trees' of `ps` & `lsof` would LEAD TO
[not just simplistically pop-out] the answer.

I claim that you could [without switching W,Ts and examining manually]
trace eg. which W,T has `nano` open on <path>/file, with the cursor
on char "g" of word dog.

[toc] | [prev] | [next] | [standalone]

#7202

On Tuesday, February 5th, 2013, at 09:36:59h +0000, Chris Glurr observed:

> `pstree`knows the pid of `xinit`, which leads to knowledge of the total
> total status of the desktop.

True, but it has no notion of which of those applications are on
a particular workspace.

> Yes, IIRC <kde> spawned N processes [which weren't even ordered
> per workspace ordering, so I had to use heuristics like: the branch
> with 4 terminals and process 'dog' is workspace3];

But pstree and ps do not know that dog is on workspace 3 -- *you*
are mentally applying that external information to the groupings
of the output of pstree.

Did you have a look at the URL I posted in another message
with details on how you may be able to get to the actual
workspace using wmctrl etc?

[toc] | [prev] | [next] | [standalone]

#7229

In article <ker7qi$r6o$4@dont-email.me>, J G Miller <miller@yoyo.ORG> wrote: 

> On Tuesday, February 5th, 2013, at 09:36:59h +0000, Chris Glurr observed:
> 
> > `pstree`knows the pid of `xinit`, which leads to knowledge of the total
> > total status of the desktop.
> 
> True, but it has no notion of which of those applications are on
> a particular workspace.
> 
IIRC KDE:pstree showed the N-workspace as descendents [spawned by]
xinit. So that if `dog` and `cow` are on different workspace, `pstree`
will show that. It did.

> > Yes, IIRC <kde> spawned N processes [which weren't even ordered
> > per workspace ordering, so I had to use heuristics like: the branch
> > with 4 terminals and process 'dog' is workspace3];
> 
> But pstree and ps do not know that dog is on workspace 3 -- *you*
> are mentally applying that external information to the groupings
> of the output of pstree.
> 
Yes, the info that pstree & lsof gave me allowed me to deduce
that 'dog' is  on workspace3.
Some times it's more difficult that just buying the pre-digested
solution from Walmart.

> Did you have a look at the URL I posted in another message
> with details on how you may be able to get to the actual
> workspace using wmctrl etc?

I'll google that.

[toc] | [prev] | [next] | [standalone]

#7245

In article <ker7qi$r6o$4@dont-email.me>, J G Miller <miller@yoyo.ORG> wrote: 

> On Tuesday, February 5th, 2013, at 09:36:59h +0000, Chris Glurr observed:
> 
> > `pstree`knows the pid of `xinit`, which leads to knowledge of the total
> > total status of the desktop.
> 
> True, but it has no notion of which of those applications are on
> a particular workspace.
> 
If Jon has some vital info, and the telephone-dir 'has no notion
that Jon has some vital info', it doesn't mean you shouldn't use
the telephone-dir, to phone Jon to get the vital info.

Perhaps a real-life situation will help explain.
A CD-bootable OS won't mount [to save a test-log] ANY of my
IDEs or USBstik/s. But it mounts a new/un-used USBstik.
I believe that M$ disk-specs contain many redundancies
[laws to nail the competition, which can be pulled out when
needed] so that other OSs can access M$ files [almost always]
with a subset of the full spec [ie. cutting-corners].

So all my IDEs & USBstiks have become non-M$ compliant.

With the newly captured test-log I boot Linux, and immediately
check that the USBstik is readable. Then do `startx`to use the
data. Later I need the USBstik occupied port for the modem,
but I can't `umount` the USBstik, despite manually searching
20 consoles in 12 workspaces. Very frustrating!!

Q. which damned W,T is holding <USBstik-path> ?!
A. the W,T held by the pid, corresponding to
 `lsof | grep <USBstik-path>`
 
In this case NONE of the W,T was still holding <USBstik-path>,
but `pstree` was able to show that it was held by a terminal
outside/before entering X.
Thus `ps` has the HIGHEST supervisory knowledge, except for
the on/off switch. Obviously, since it's the window to the krnl.

> Did you have a look at the URL I posted in another message
> with details on how you may be able to get to the actual
> workspace using wmctrl etc?

] If the -p option is specified the next column will contain the
] PID for the window as a decimal integer.
] Getting a list of windows with PID and geometry information.
]          wmctrl -p -G -l

But HOW does it "list the windows"?
I don't wan't names. I want to know which W,T to switch to.

Apparently then, `lsof | grep <pid> | grep <key>`
would give the path & utility?

I need this mainly for keeping track of multiple `mc`.

[toc] | [prev] | [next] | [standalone]

#7256 — How to use wmctrl to switch to a window on another workspace with an EMWH compliant window manager

On Thursday, February 7th, 2013, at 05:14:37h +0000, Chris Glurr asked:

> ] If the -p option is specified the next column will contain the
> ] PID for the window as a decimal integer.
> ] Getting a list of windows with PID and geometry information.
> ]          wmctrl -p -G -l
> 
> But HOW does it "list the windows"?

If you are not prepared to install it and try it, why not
read the article at

    <http://www.linuxjournal.COM/magazine/hack-and-automate-your-desktop-wmctrl>

and more examples at

    <http://spiralofhope.COM/wmctrl-examples.html>

> I don't wan't names. I want to know which W,T to switch to.

So use wmctrl to do that for you?

First get the window name with wmctrl -l, then use

       wmctrl -a <WIN> 

to activate the window by *switching to its desktop* and raising it.

> I need this mainly for keeping track of multiple `mc`.

So what you must do (in order to use wmctrl) is to run
mc in an X terminal emulator eg using xterm, or
better rxvt, or perhaps urxvt (for nicer xft font handling)
with a different title for each instance using the
-title or -T parameter or possibly with a different application
name using -n.

Then in your script you would use wmctrl -l to get a list
of windows, filter that with the string (passed as the parameter
to the script) to find the specific instance, extract the 
window name or numeric id, then use wmctrl -a to activate
that window and move to its desktop.

[toc] | [prev] | [next] | [standalone]

#7135

Avoid9Pdf@gmail.com wrote:
> Actually `ps` and related utilities that can help show:
> which workSpace/s [in X] have got a running `links`.

You could try something like "xwininfo -name links" and see if you
can derive any information from the geometry fields (Absolute position
vs Corners). The other one to try is "xwininfo -root -tree". But since
I don't know what you're trying to achieve it's pretty difficult to give
a specific answer.

Chris

[toc] | [prev] | [next] | [standalone]

#7204

On 2013-01-29, Avoid9Pdf@gmail.com <Avoid9Pdf@gmail.com> wrote:
>
> PS. I don't know the details of what I'm doing.

This summarizes just about every post you've made!

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web