HDTenEightyP/NetNews huggingface dataset:
From: pdel@ADS.COM (Peter Delevoryas)
Subject: Help w/ controlling 2 processes
Organization: Advanced Decision Systems, Mtn. View, CA (415)960-7300
Distribution: usa
Date: Thu, 8 Oct 1992 06:38:51 GMT

Hi, I've got a dump program I am trying to automate with expect.

Here's what it is:

It requires two processes, one called backup and the other called
butc. Anyone using AFS will recognize it as the included dump utility.


Here's what I have so far:


#!expect -f


spawn /usr/afs/etc/backup ; # start the backup program
set id1 $spawn_id
expect "backup>"	    # the prompt, after starting the program

spawn /usr/afs/etc/butc ; # start the 'BackUp Tape Coordinator'
set id2 $spawn_id	  # This normally uses a window of its
			  # own because it asks you to hit return
			  # after typing a command
			  # in the 'backup' window.

exec afsmake		  # this creates a file containing a
			  # description of what to dump, which
			  # I want expect to send to 'backup'

set spawn_id $id1

send [ exec cat afs_dump ] ;# this sends the dump info
 interact +		    # if I don't put this in, backup quits

set spawn_id $id2

expect "Hit return when done*" # The 'butc' prints this to screen after
send "\r" ;		       # 'backup' has processed the dump info
interact + 			# I don't know if I need this. Maybe not.



Well, that's it. It doesn't quite work yet. I don't think the "\r" at
the end is getting to butc. It does send the dump info to backup,
though.

Basically I want to avoid starting up 2 windows with backup in one
and butc in the other; I just want to start the script and have it
spawn the two processes and then send strings to each one. I have the
manual and read about multiple processes, but I still need a little
help understanding what's happening.

Thanks, PD





--

 login name:   L1-A                      
 In real life: Peter Delevoryas
 In any other life: a cheap imitation
From: vijay@ncsa.uiuc.edu (Vijay Rangarajan)
Newsgroups: comp.lang.tcl
Subject: Real time graphs.
Summary: tcl/tk to feed data to xgraph, etc.
Keywords: expect, real time, graphs, plots.
Date: 15 Oct 92 19:14:54 GMT
Article-I.D.: ncsa.1992Oct15.191454.7892
Distribution: usa
Organization: Nat'l Ctr for Supercomp App (NCSA) @ University of Illinois
Originator: vijay@picard.ncsa.uiuc.edu

Is it possible to use tcl/tk to graph data, which is written into a log
file at constant intervals ? The log file will be updated every 5 minutes
and I was wondering if it would be possible to use tcl/tk to feed the data 
to a graphing program (like xgraph, gnuplot, etc.) ?

Among the suggestions I got in trying to get real time graphs was to use
tcl/tk to feed data into a graphing package, using 'expect'.

I would appreciate input from tcl/tk users, some sample code would really
be of great help.

Thanks,
Vijay.
Newsgroups: comp.lang.tcl
From: eric@desktalk.com (Eric Lieber)
Subject: tcl_snmp
Reply-To: eric@desktalk.com
Organization: Desktalk Systems Inc.
Date: Fri, 9 Oct 1992 17:22:32 GMT

there was a posting regarding tcl_snmp from phk@data.fls.dk
This address  apparently is incorrect. Does anyone have the correct e-mail address?

Thanx


===========================================================================Eric Lieber			! 
DeskTalk Systems Inc.		!
19401 S. Vermont Ave		!
Torrance, CA., 90502		!
Telephone:	(310) 323-5998	!
Fax:	(310) 323-6197	!
===========================================================================
			Standard Disclaimer
			___________________
From: pierson@kukri.mps.mlo.dec.com (dan pierson)
Newsgroups: comp.lang.tcl
Subject: Re: Planning for Tcl 7.0
Date: 8 Oct 92 12:20:15 GMT
Organization: Digital Equipment Corporation


   From: kjx@comp.vuw.ac.nz (R James Noble)
   Date: Thu, 8 Oct 1992 03:52:02 GMT

   One change I've often thought would make things a little clearer would
   be to add a package system to structure global variable and procedure
   names. 

Yes!  The lack of this is one of the two main reasons I've moved a
major hunk of work from Tcl to a small Lisp based system (BOS isn't
quite far enough along yet or it would have been another candidate).
Current Tcl just gets too hard to manage when the code gets large.

For the record, the other reason was unmeasured concern about the
performance of Tcl lists.  It wouldn't have caused a change by itself
unless backed up by measurements.

                                            dan

--
Dan L. Pierson          Digital Equipment Corporation
pierson@crl.dec.com     Massively Parallel Systems Group
Newsgroups: comp.lang.tcl
From: gwlester@cpu.com (Gerald W. Lester)
Subject: Re: Is there a tcl interface to Motif, even commercial? 
Organization: Computerized Processes Unlimited, Metairie, LA, (504)-889-2784
Date: Thu, 8 Oct 1992 14:18:03 GMT
Reply-To: gwlester@cpu.com

In article <1992Oct6.172654.13015@ninja.zso.dec.com>, alan@ulka.zso.dec.com (F. Alan Jones) writes:
>
>The subject says it all.
>
>Alan

	1) Add the tk extensions to tcl in to your applications

	2) Set the Motif look and feel flag to 1.  (Hitn: it has motif in the
	   name)

P.S. - The VMS sources are *not* at berkeley.
From: Bud Bach <bachww@rtsg.mot.com>
Subject: Re: Planning for Tcl 7.0
X-Xxdate: Thu, 8 Oct 92 17: 50:42 GMT
Organization: Motorola, Inc
X-Useragent: Nuntius v1.1.1d9
Date: Thu, 8 Oct 1992 22:50:17 GMT

In article <1992Oct8.143420.1947@cpu.com> Gerald W. Lester,
gwlester@cpu.com writes:
>	How about the recent discussion (it was on tk but..) on adding a file
>handler.  That is, being able to set up a procedure to automatically get
called
>when input is ready on a file.

Yes!
Newsgroups: comp.lang.tcl
From: bright@sctc.com (David A. Bright)
Subject: Re: Planning for Tcl 7.0
Organization: SCTC
Date: Thu, 8 Oct 1992 18:06:52 GMT

gwlester@cpu.com (Gerald W. Lester) writes:

>I have no problems with any of the changes.   However, I would like to voice
>support for some of them:

>>...
>>6. Change glob to return only the names of existing files.
>>Rationale:  at present "glob */foo" expands * and generates a result
>>without checking to see if each directory has a "foo" file in it.  This
>>makes the current behavior incompatible with csh, for example.  One
>>question is whether constructs like "glob {a,b}.c" should also check for
>>the existence of each of the files.  At present they don't (i.e. a.c and
>>b.c will be returned even if they don't exist), but neither does csh.  My
>>inclination is to make the behavior match csh (names containing *?[] are
>>checked for existence, others aren't).  I'd be interested to hear
>>opinions on this one:  check all names for existence, check only names
>>including *?[] (for csh compatibility), or keep it as it is?

>	Always check!

I disagree.  The csh behavior is very convenient to be able to construct
a series of names.  Check existence for *?[], not for {}.

-- 
David A. Bright			dab@Bright.MN.ORG	(home)
Secure Computing		bright@SCTC.COM		(work)
Newsgroups: comp.lang.tcl
From: clayton@cc.gatech.edu (R. Clayton)
Subject: Pull down tear off mess up?
Reply-To: clayton@cc.gatech.edu (R. Clayton)
Organization: College of Computing, Georgia Institute of Technology
Date: Mon, 12 Oct 1992 17:02:50 GMT

I recently installed tk 2.3 and the version of tcl that came with it.  While
fooling around with the widgets demo, I noticed what I suspect is a problem
with the menu pull-down menu.  With the menu menu attached to its button, the
submenus for the check box and radio button entries (I think, I don't have the
demo in front of me) work correctly; I can move the mouse up and down in the
submenu with no problem.  If I tear off the menu menu, submenus no longer work
correctly:  moving the mouse down in the submenu also moves the menu menu
choice down, changing the submenu.  Moving the mouse up moves the menu menu
choice up, again changing the submenu.
From: smoot@gumby.cs.Berkeley.EDU (Stephen R Smoot)
Newsgroups: comp.lang.tcl
Subject: Re: Planning for Tcl 7.0
Followup-To: comp.lang.tcl
Date: 8 Oct 1992 19:12:29 GMT
Organization: UC Berkeley
Distribution: world
NNTP-Posting-Host: gumby.cs.berkeley.edu

In article <1avu22INN5ao@agate.berkeley.edu>, ouster@sprite.Berkeley.EDU (John Ousterhout) writes:
> 1. Eliminate the "|" option in the "open" command.  Instead, add a
> "popen" command that does the same thing. Rationale: in the current
> implementation you can't open a file whose name begins with "|".
> Also, I think the "popen" command would be more logical.

I like the syntax.  And I like fewer commands.
I'd prefer a option to open to say "no, exactly what I give you"
instead of a new command.

> 3. Clean up backslash processing in several ways:
>     - Change backslash-newline to eat up all the whitespace following the

YES!

> 6. Change glob to return only the names of existing files.

Yes, csh is a useful model for this.

> 8. Implement Tcl_CreateExternVar() procedure along lines proposed by
> Andreas Stolcke to tie a C variable to a Tcl variable with automatic
> updates between them.

Neat!


Other suggestion:

A better way to pass in the name of an array, and reference its elements
from the procedure (the best I can do for this seeems a real hack!).


Unrelated suggestion:

add: wish -nowindow
Newsgroups: comp.lang.tcl
Subject: Re: Planning for Tcl 7.0
From: kjx@comp.vuw.ac.nz (R James Noble)
Date: Thu, 8 Oct 1992 03:52:02 GMT
Organization: Victoria University of Wellington, Wellington, New Zealand

   John Ousterhout writes:

   .... If there are other changes that you think are
   important but aren't contained on this list, let me know and I may add
   them.

One change I've often thought would make things a little clearer would
be to add a package system to structure global variable and procedure
names. Especially as the system matures and more code is written in
tcl rather than C, we will find problems with global name allocation
and collision. For example, we alread have commands named "tkwait",
procedures called "tkerror" and variables "tk_this" or "auto_that".
Adding a package facility (even a simple one like perl's) should aviod
this, and even make it easier for people building systems combining
various tcl extensions into one binary.  

(It would also solve certain problems in writing tcl support systems
like BYO where you may wish to hide your procedures from those of the
user's program)

kjx
--
R James Noble, Graduate Student, Computer Science Department
Victoria University, Box 600, Wellington 1, New Zealand
kjx@comp.vuw.ac.nz
Newsgroups: comp.lang.tcl
From: kelsey@mdd.comm.mot.com (Joe Kelsey)
Subject: Re: Planning for Tcl 7.0 -- glob checking
Organization: Motorola, Mobile Data Division - Seattle, WA
Distribution: na
Date: Fri, 9 Oct 1992 15:18:26 GMT

I agree that the csh {} syntax can be useful *sometimes*, but I really find
that the ksh extended syntax has advantages also.  Rather than standardizing
to *either* sh or csh, why not just make the jump to POSIX.2?  Did they
standardize on sh, csh or ksh?  Since you seem worried about USL attacking
your use of the word UNIX, let's go POSIX all the way and be done with it!

/Joe
Newsgroups: comp.lang.tcl,comp.databases.sybase
From: ouster@sprite.Berkeley.EDU (John Ousterhout)
Newsgroups: comp.lang.tcl
Subject: Re: Pull down tear off mess up?
Date: 12 Oct 1992 20:27:10 GMT
Organization: U.C. Berkeley Sprite Project
Distribution: world
NNTP-Posting-Host: tyranny.berkeley.edu

In article <1992Oct12.170250.10140@cc.gatech.edu>, clayton@cc.gatech.edu (R. Clayton) writes:
|> I recently installed tk 2.3 and the version of tcl that came with it.  While
|> fooling around with the widgets demo, I noticed what I suspect is a problem
|> with the menu pull-down menu.  With the menu menu attached to its button, the
|> submenus for the check box and radio button entries (I think, I don't have the
|> demo in front of me) work correctly; I can move the mouse up and down in the
|> submenu with no problem.  If I tear off the menu menu, submenus no longer work
|> correctly:  moving the mouse down in the submenu also moves the menu menu
|> choice down, changing the submenu.  Moving the mouse up moves the menu menu
|> choice up, again changing the submenu. 

Oops, looks like there's a bug there.  I've fixed it in my unreleased
sources now.  Here's a patch to "library/tk.tcl" that should correct
the problem.  Thanks for reporting the bug.

*** /tmp/,RCSt1805672	Mon Oct 12 13:26:29 1992
--- tk.tcl	Mon Oct 12 13:25:34 1992
***************
*** 212,218 ****
  bind Menu <Any-Enter> {set tk_priv(window) %W; %W activate @%y}
  bind Menu <Any-Leave> {set tk_priv(window) {}; %W activate none}
  bind Menu <Any-Motion> {
!     if {$tk_priv(window) != ""} {
  	%W activate @%y
      }
  }
--- 212,218 ----
  bind Menu <Any-Enter> {set tk_priv(window) %W; %W activate @%y}
  bind Menu <Any-Leave> {set tk_priv(window) {}; %W activate none}
  bind Menu <Any-Motion> {
!     if {$tk_priv(window) == "%W"} {
  	%W activate @%y
      }
  }

Newsgroups: comp.lang.tcl
From: ellson@ontap.att.com (54312 - John C Ellson)
Subject: Re: Planning for Tcl 7.0
Reply-To: ellson@hotsand.att.com
Organization: AT&T
Distribution: world
 
 
 
  - A way to position the end of text at the end of entry widgets.
  - A way to position the end of text at the end of text widgets.
  - A way to position the end of lists at the end of listbox widgets.
                              
  - Ability to automatically stop scrolling when positioned with the
    end at the end (entry, text and listboxes).
    
  - Non-consecutive selections in listboxes. 
  
  - Font support in listboxes.
  
Date: Fri, 16 Oct 1992 05:51:28 GMT
Originator: ellson@ontap

Newsgroups: comp.lang.tcl
From: tewei@bnrca (Te-Wei Sun)
Subject: Rubber box for graphic editor
Keywords: tk, canvas
Organization: Bell-Northern Research, Ottawa, Ontario, CANADA
Date: Wed, 7 Oct 92 23:43:50 GMT

Hi,

I am trying to implement a graphic editor based on tk2.3.
In the editor, I implemented a "rubber box" to facilitate
widget selections. Whenever a user press button 1, a rectangle
gets created and its size changes as the user move the mouse.
Finally the box is deleted when the button is released.

The implementation works well when there are not many widgets on
the canvas. It quickly slows down as the amount of widgets
increases. Eventually the rubber box will have a hard time try to
catch up with the mouse pointer. Unfortunately, it is quite
normal to have hundreds of widgets on the canvas in the same time
for the kind of work my editor is dealing with.

Is there anyway to speed up the rubber box?

Any information will be deeply appreciated.


The following is the "simplified" version of the editor. It creates
hundreds of widgets. When button 1 is pressed, it will create a 
rubber box and will resize the box as the mouse pointer moves.

proc plotRBOX {canvaspath x y} {
global startX startY endX endY RBOX

        set startX [$canvaspath canvasx $x]
        set startY [$canvaspath canvasy $y]
        set endX $startX
        set endY $startY
        set RBOX [$canvaspath create rect $startX $startY \
                        $startX $startY ]
}

proc resizeRBOX {canvaspath x y} {
global startX startY endX endY RBOX

        set endX [$canvaspath canvasx $x]
        set endY [$canvaspath canvasy $y]

        if {$startX > $endX} {
               $canvaspath coords $RBOX $endX $endY $startX $startY
        } else {
               $canvaspath coords $RBOX $startX $startY $endX $endY
        }
}


proc endRBOX {canvaspath} {
global RBOX

        $canvaspath delete $RBOX
        set RBOX 0
}

set c .c

canvas $c -relief raised \
        -scrollregion { 0 0 1000 1000 } \
        -scrollincrement 1

#Scrollbar creation.  Command xview and yview are invoked to adjust the display
scrollbar .vscroll -relief sunken -command ".c yview"
scrollbar .hscroll -orient horiz -relief sunken -command ".c xview"

# Button creation. Commnad destroy kills the window.
button .ok -text "OK" -command "destroy ."

# Window layout
pack append . .ok {bottom fillx} .hscroll {bottom fillx} \
                .vscroll {right filly} $c {top expand fill}



# Connect the scrollbars to the canvas.
$c config -xscroll ".hscroll set" \
         -yscroll ".vscroll set"



#Record the position of the scrollbars. Used for translation of the display.
bind .hscroll <Any-ButtonRelease> {set_x_offset .hscroll }
bind .vscroll <Any-ButtonRelease> {set_y_offset .vscroll }

#binding for the rubber box
bind $c <1> "plotRBOX $c %x %y"
bind $c <B1-Motion> "resizeRBOX $c %x %y"
bind $c <ButtonRelease-1> "endRBOX $c"

#creating widgets on the canvas
for {set i 1} {$i < 51} {incr i} {
        for {set j 1} {$j < 51} {incr j} {
                $c create rect [expr $i*20] [expr $j*20] \
                        [expr $i*10+40] [expr $j*10+20]
        }
}
From: jnh@wag.caltech.edu (Jon N. Hurley)
Newsgroups: comp.lang.tcl
Subject: Re: Planning for Tcl 7.0
Date: 13 Oct 1992 20:48:58 GMT
Organization: California Institute of Technology, Pasadena, CA
Distribution: world
NNTP-Posting-Host: picasso.wag.caltech.edu

How about methods of accessing C structures from TCL?

It seems that there are 2 philosophies:

  1) Create a command object, like the widgets in Tk.
  2) Create a handle that is referenced by string lookup
     in a table, such as the file handles from the open command.

    How about extending the file handle concept for
general structures? Maybe the table would contain general
purpose routines, such as deletion or printing, for the
structures. This way a set of tcl commands could pass
general C data structures between them.

An example of a case where the handle approach is necessary,
is when a command requires two or more unrelated C structures
as arguments. An example is an extension I have made to Kevin
B. Kenny's tclTCP package for XDR'ing binary data. In this
case, the $tcp_connection command object is also given a 
pointer to a C data structure.

If TCL variables were used to store the table index for
C structures, this mechanism could be used to implement
scope rules, whereby when a variable was modified or went
out of scope, the old contents would be deleted using the
deletion routine in the table.

Additionally, I have found that when using trace commands, it
would be very valuable to have access to the old contents of
the variable. This could be passed in as an additional argument to
the trace routine.  This way 'write' traces could reset the old value
if desired, and 'unset' traces could do something based on the value the
variable used to have.
From: linkosalo@cc.helsinki.fi
Newsgroups: comp.lang.tcl
Subject: A bug in '.button invoke'?
Date: 12 Oct 92 13:43:50 GMT
Organization: University of Helsinki



I got the following error message. I haven't coded subprogram or call to "LD".
Any ideas what might go wrong?

+-+-+-+- start -+-+-+-+-
invalid command name "LD"
    while executing
"error "invalid command name \"$name\"""
    (procedure "unknown" line 38)
    invoked from within
"LD"
    invoked from within
".surf.buttons.draw invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    ("then" clause line 2)
    invoked from within
"if {($w == $tk_priv(window))
            && ([lindex [$w config -state] 4] != "disabled")} {
        uplevel #0 [list $w invoke]
    }"
    (procedure "tk_butUp" line 4)
    invoked from within
"tk_butUp .surf.buttons.draw"
    (command bound to event)
-+-+-+-+-+ end +-+-+-+-+-

Tapio Linkosalo

linkosal@salava.metla.fi OR
linkosalo@cc.helsinki.fi
Newsgroups: comp.lang.tcl
From: mathys@utopia.sps.mot.com (Yves Mathys)
Subject: How resizing listbox ?
Organization: Motorola, Semiconductor Systems Design Technology
Date: Thu, 15 Oct 1992 17:06:29 GMT

I have *not* been able to resize listbox, althouth its parent's window
was correctly resizing. 
Any ideas? Do I need a special option on listbox or pack? 

------------------------------------------
	Yves Mathys
	Motorola Inc/Design Technology
	mathys@ssdt-tempe.sps.mot.com
-- 
------------------------------------------
	Yves Mathys
	Motorola Inc/Design Technology
	mathys@ssdt-tempe.sps.mot.com
Newsgroups: comp.lang.tcl
From: shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall)
Subject: Re: syntax(?) error in simple wish script
Date: Tue, 13 Oct 1992 21:31:50 GMT
Reply-To: jay@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester, MN

In article <1992Oct13.185540.24784@sctc.com>, scott@sctc.com (Scott Hammond) writes:
|> {tk 2.3, tcl6.4, SunOs4.1.2}
|> The following script generates an error.  I don't understand what's
|> wrong, and what is 'arm line 5'?.
[...] 
|> 
|> The error is:
|> 
|> 	invalid command name "
|> 			 puts stderr "missing"
|> 			"
|> 	    while executing

Try unbracing the command, that is instead of
{
	puts stderr "missing"
}
just have
	puts stderr "missing"

I think the curly braces are forcing tcl to interpet the entire thing
between them as a command name; no command by that name, hence the error.

No idea what 'arm line 5' is about.
-- 
: jay          jay@vnet.ibm.com    My opinions and ideas, not my employer's.
: shmdgljd@rchland.vnet.ibm.com    (c) Copyright 1992.  All rights reserved.
Newsgroups: comp.lang.tcl,news.answers
From: neal@druhi.ATT.COM (Neal D. McBurnett)
Newsgroups: comp.lang.tcl
Subject: SQL front end in tk?
Date: 12 Oct 92 20:03:06 GMT
Distribution: comp
Organization: AT&T Bell Laboratories

I'm thinking of  putting together a tk interface to an existing SQL database of
conference room reservations, and I wonder if anyone has done anything
similar - e.g. a general SQL browsing interface.

Neal_McBurnett@ATT.COM (Neal McBurnett)	303-538-4852	AT&T Bell Labs, Denver
Newsgroups: comp.lang.tcl
From: Bud Bach <bachww@rtsg.mot.com>
Subject: Re: Planning for Tcl 7.0
X-Xxdate: Thu, 8 Oct 92 17: 49:37 GMT
Organization: Motorola, Inc
X-Useragent: Nuntius v1.1.1d9
Date: Thu, 8 Oct 1992 22:49:15 GMT

In article <1992Oct8.143420.1947@cpu.com> Gerald W. Lester,
gwlester@cpu.com writes:
>	How about the recent discussion (it was on tk but..) on adding a file
>handler.  That is, being able to set up a procedure to automatically get
called
>when input is ready on a file.

Yes!
Newsgroups: comp.lang.tcl,news.answers