1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Will this work?

Discussion in 'Plugins' started by vefatica, Jul 29, 2010.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    Suppose I have a lingering app running started by TCC in the same console; a packet-sniffer is a good example. And suppose I want notification (a beep of vbeep, say) if that app writes to the console. I imagine a plugin command, say, ALERT, which the user would call just before starting the forementioned app, say ALERT & SNIFFIT. ALERT would start a thread which polled the console for its cursor position, alerting the user upon a change. Will this work?

    I'm also wondering it there's a way that thread might know when the app has terminated (so it might terminate itself). I suppose a keyhandler function could tell when TCC issues its next prompt (the app terminated) but I'm hoping for something easier.
     
  2. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,190
    Likes Received:
    11
    Why not do something akin to the way TEE works?

    SNIFFIT | ALERT

    ALERT could echo stdin to stdout and monitor the stdin traffic directly.

    -Scott

    vefatica <> wrote on 07/29/2010 08:09:40 PM:


     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    That certainly solves the problem of knowing when the app finishes.

    On Fri, 30 Jul 2010 09:42:21 -0400, you wrote:

    |Why not do something akin to the way TEE works?
    |
    |SNIFFIT | ALERT
    |
    |ALERT could echo stdin to stdout and monitor the stdin traffic directly.
    |
    |-Scott
    |
    |vefatica <> wrote on 07/29/2010 08:09:40 PM:
    |
    |
    |
    |---Quote---
    |> Suppose I have a lingering app running started by TCC in the same
    |> console; a packet-sniffer is a good example. And suppose I want
    |> notification (a beep of vbeep, say) if that app writes to the
    |> console. I imagine a plugin command, say, ALERT, which the user
    |> would call just before starting the forementioned app, say ALERT &
    |> SNIFFIT. ALERT would start a thread which polled the console for
    |> its cursor position, alerting the user upon a change. Will this work?
    |>
    |> I'm also wondering it there's a way that thread might know when the
    |> app has terminated (so it might terminate itself). I suppose a
    |> keyhandler function could tell when TCC issues its next prompt (the
    |> app terminated) but I'm hoping for something easier.
    |>
    |>
    |>
    |>
    |---End Quote---
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | Suppose I have a lingering app running started by TCC in the same
    | console; a packet-sniffer is a good example. And suppose I want
    | notification (a beep of vbeep, say) if that app writes to the
    | console. I imagine a plugin command, say, ALERT, which the user
    | would call just before starting the forementioned app, say ALERT &
    | SNIFFIT. ALERT would start a thread which polled the console for
    | its cursor position, alerting the user upon a change. Will this
    | work?

    Your concept is fully in harmony with a basic UI principle I realized
    decades ago: use audible notification when user attention is desired, e.g.,
    when an action completes after taking longer than a normal human attention
    span. In interactive TCC operations I implemented this using PRE_EXEC and
    POST_EXEC: the former saves _WINTICKS, the latter executes BEEP if the time
    elapsed is more then 30s.
    I think you could use the ON CONDITION command for your situation,
    exactly as you described:
    ON CONDITION %_column NE %savedcol .OR. %_row NE %savedrow ...

    | I'm also wondering it there's a way that thread might know when the
    | app has terminated (so it might terminate itself). I suppose a
    | keyhandler function could tell when TCC issues its next prompt (the
    | app terminated) but I'm hoping for something easier.

    Once again I think you could use "ON CONDITION NOT ISWINDOW ...", or a test
    based on PID, or a test using your WHICHWIN, ...
    --
    HTH, Steve
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    On Fri, 30 Jul 2010 10:24:09 -0400, you wrote:

    || Suppose I have a lingering app running started by TCC in the same
    || console; a packet-sniffer is a good example. And suppose I want
    || notification (a beep of vbeep, say) if that app writes to the
    || console. I imagine a plugin command, say, ALERT, which the user
    || would call just before starting the forementioned app, say ALERT &
    || SNIFFIT. ALERT would start a thread which polled the console for
    || its cursor position, alerting the user upon a change. Will this
    || work?
    |
    | Your concept is fully in harmony with a basic UI principle I realized
    |decades ago: use audible notification when user attention is desired, e.g.,
    |when an action completes after taking longer than a normal human attention
    |span. In interactive TCC operations I implemented this using PRE_EXEC and
    |POST_EXEC: the former saves _WINTICKS, the latter executes BEEP if the time
    |elapsed is more then 30s.
    | I think you could use the ON CONDITION command for your situation,
    |exactly as you described:
    | ON CONDITION %_column NE %savedcol .OR. %_row NE %savedrow ...

    I'm talking about running a console app (windump (tcpdump) in
    particular) in the same console as TCC. It won't have its own window
    and if it's started (as usual) from the command line I won't have easy
    access to its PID. TCC's main thread will be waiting for it to
    finish. I don't want to wait for it to finish. Rather, I want to
    provide notification whenever it produces output. In my own thread, I
    could check for a change in cursor position more efficiently than with
    TCC's internal variables.

    I like Scott's idea of simply piping the app through my plugin which
    would just reproduce its output (and would certainly know, with no
    additional effort, when there is output). But there's a speed
    consideration. At high volume, windump's output can't keep up with
    the arrival of information. I rarely lose packets because of the lack
    of buffering but I wouldn't want to exacerbate the situation by my
    also processing the output before it's displayed.


    || I'm also wondering it there's a way that thread might know when the
    || app has terminated (so it might terminate itself). I suppose a
    || keyhandler function could tell when TCC issues its next prompt (the
    || app terminated) but I'm hoping for something easier.
    |
    |Once again I think you could use "ON CONDITION NOT ISWINDOW ...", or a test
    |based on PID, or a test using your WHICHWIN, ...
     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    On Fri, 30 Jul 2010 10:24:09 -0400, you wrote:

    |I implemented this using PRE_EXEC and
    |POST_EXEC:

    That brings up a question for Rex. Will the real (user-defined) alias
    be executed if the plugin version of one of the three special aliases
    disables itself by returning 0xFEDCBA98? It would be nice to be able
    to turn it on/off like that so it could be used, for example, to tell
    when TCC issues its prompt (but only when interested).
     
  7. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,190
    Likes Received:
    11
    If you need to launch a separate thread to play the beep or PlaySound() or
    whatever mechanism you use it shouldn't add any recognizable time.

    -Scott

    vefatica <> wrote on 07/30/2010 11:35:27 AM:


     
  8. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | I'm talking about running a console app (windump (tcpdump) in
    | particular) in the same console as TCC. It won't have its own window
    | and if it's started (as usual) from the command line I won't have
    | easy access to its PID. TCC's main thread will be waiting for it to
    | finish. I don't want to wait for it to finish. Rather, I want to
    | provide notification whenever it produces output. In my own thread,
    | I could check for a change in cursor position more efficiently than
    | with TCC's internal variables.

    Suppose you use "ON" to start your own monitoring thread?

    | I like Scott's idea of simply piping the app through my plugin which
    | would just reproduce its output (and would certainly know, with no
    | additional effort, when there is output). But there's a speed
    | consideration. At high volume, windump's output can't keep up with
    | the arrival of information. I rarely lose packets because of the
    | lack of buffering but I wouldn't want to exacerbate the situation by
    | my also processing the output before it's displayed.

    In my experience piping is faster than on-screen display. You could also
    provide additional buffering to avoid losing data.

    ||| I'm also wondering it there's a way that thread might know when the
    ||| app has terminated (so it might terminate itself). I suppose a
    ||| keyhandler function could tell when TCC issues its next prompt (the
    ||| app terminated) but I'm hoping for something easier.
    ||
    || Once again I think you could use "ON CONDITION NOT ISWINDOW ...",
    || or a test based on PID, or a test using your WHICHWIN, ...

    If you allow updaing of window titles, "iswindow" will also detect
    termination.
    --
    Steve
     
  9. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,190
    Likes Received:
    11
    This might work for you as well:

    foldermonitor . /i"foo.txt" created modified forever beep exclamation
    sniffit | tee foo.txt

    -Scott






    vefatica <>
    07/30/2010 11:35 AM
    Please respond to



    To
    Samintz@ra.rockwell.com
    cc

    Subject
    RE: [Plugins-t-2219] Will this work?






    On Fri, 30 Jul 2010 10:24:09 -0400, you wrote:

    || Suppose I have a lingering app running started by TCC in the same
    || console; a packet-sniffer is a good example. And suppose I want
    || notification (a beep of vbeep, say) if that app writes to the
    || console. I imagine a plugin command, say, ALERT, which the user
    || would call just before starting the forementioned app, say ALERT &
    || SNIFFIT. ALERT would start a thread which polled the console for
    || its cursor position, alerting the user upon a change. Will this
    || work?
    |
    | Your concept is fully in harmony with a basic UI principle I realized

    |decades ago: use audible notification when user attention is desired,
    e.g.,
    |when an action completes after taking longer than a normal human
    attention
    |span. In interactive TCC operations I implemented this using PRE_EXEC and

    |POST_EXEC: the former saves _WINTICKS, the latter executes BEEP if the
    time
    |elapsed is more then 30s.
    | I think you could use the ON CONDITION command for your situation,
    |exactly as you described:
    | ON CONDITION %_column NE %savedcol .OR. %_row NE %savedrow ...

    I'm talking about running a console app (windump (tcpdump) in
    particular) in the same console as TCC. It won't have its own window
    and if it's started (as usual) from the command line I won't have easy
    access to its PID. TCC's main thread will be waiting for it to
    finish. I don't want to wait for it to finish. Rather, I want to
    provide notification whenever it produces output. In my own thread, I
    could check for a change in cursor position more efficiently than with
    TCC's internal variables.

    I like Scott's idea of simply piping the app through my plugin which
    would just reproduce its output (and would certainly know, with no
    additional effort, when there is output). But there's a speed
    consideration. At high volume, windump's output can't keep up with
    the arrival of information. I rarely lose packets because of the lack
    of buffering but I wouldn't want to exacerbate the situation by my
    also processing the output before it's displayed.


    || I'm also wondering it there's a way that thread might know when the
    || app has terminated (so it might terminate itself). I suppose a
    || keyhandler function could tell when TCC issues its next prompt (the
    || app terminated) but I'm hoping for something easier.
    |
    |Once again I think you could use "ON CONDITION NOT ISWINDOW ...", or a
    test
    |based on PID, or a test using your WHICHWIN, ...
     

Share This Page