On Mon, 25 Jun 2018 12:38:48 -0400 Chris Jones <cga2...@gmail.com> wrote:
> GNU/screen provides a list of windows in tabular form that you can access via > CTRL+a " or the GNU/screen CTRL+: windowlist command. > > By default this list of windows displays rather little information: window > number, window title and flags. > > This is basically what users like myself already have at the bottom of the > screen in their "hardstatus line". > > I thought it would be nice to display the name of the currently > executing program where relevant and (or) the bash $PWD for those > windows that are currently idle just displaying the shell prompt. > > The idea is to use this display to have some kind of overview of what is > currently going on in a given GNU/screen session. > > To clarify: > > I have (say).. a vim session running in window #3, gdb running in window #4, > and perhaps less /tmp/xxxx.log on windows #5, a man page on windows #6, and > somewhat unrelated... some kind of audio player running in window #10. > > As to windows #7 to #9 as well as #11 and #12 they are currently displaying > the > bash prompt and are basically available to do whatever I fancy at this point. > > Regarding windows #0, #1, and #2 they run e.g. a python interactive shell, the > mutt mailer agent, and the text-mode Elinks web browser... > > Lines such as this in my .screenrc: > > screen -t P $SHELL -c "python" > screen -t P $SHELL -c "mutt -y" > > start these "static" windows when I launch the GNU/screen session. > > I know where they are and their content never changes during the life of > the screen session. > > The default setting for the windowlist string that formats the entries is like > so: > > windowlist string "%3n %t%=%f" > > causing the windowlist screen to display for each entry, the window number > (%n) > the window title (%t) and the right-aligned window flags (%=%f) > > I looked into adding the last executed command - adding the %x STRING ESCAPE > eg. > > windowlist string "%3n %t %x%=%f" > > but alas '%x' remains set to the value of the initial command - ie. the > command that is issued at session startup, (or the default shell when > the window is created on the fly via eg. CTRL+a c). > > And that is usually just '/bin/bash'... with optionally whatever command > was specified via the screen command - e.g.something like screen -t > M $SHELL -c "mutt -y" will cause the windowlist (aka CTRL_A ") to > display '/bin/bash -c mutt -y'. > > After that the value of the %x STRING ESCAPE is not updated to keep > track of what is actually happening in each window in terms of what is > currently running on top of the bash shell. > > I also looked into using a backtick that returns what I am looking for via > something like: > > windowlist string "%3n %t %8`%=%f" > > where '%8`' would have been defined to screen like so: > > backtick 8 0 0 /home/cjones/bin/bt-wlist > > ... but I haven't been able to find anything (such as an environment variable) > that would let the code in the backtick script figure out anything about what > is happening in each GNU/screen window. > > As far as I can tell, nothing useful in terms of windows content (param or > environment variable) is passed by GNU/screen to the backtick script when it > is given control. > > Hitting a wall at this point and wondering whether anyone more knowledgeable > has gone down this path before and mignt have any suggestions. > > Thanks, > > CJ Hi, (I don't think it's possible with current screen, you would need to add some kind of tty escape for windows command, so you can get list of window ttys.) Eh... whatever, I pushed %T escape to git, so if you rebuild you can screen -Q windows "%T " and it will give you list of windows ttys ;) And then write script traversing process tree on this tty and I think you still could get some false positives. This is example of runnning "man man" in one of my shells in screen: $ ps ao pid,tty,ppid,comm,args | grep pts/2 4696 pts/2 4681 zsh -/bin/zsh 5076 pts/2 4696 man man man 5103 pts/2 5076 less /usr/bin/less So if you traversed linearly it would show you /usr/bin/less, while running "man man" ;) I think better idea is to make sure that applications which can set window title actually do set it to something meaningful. Amadeusz _______________________________________________ screen-users mailing list screen-users@gnu.org https://lists.gnu.org/mailman/listinfo/screen-users