From kellert at ohsu.edu Sat Dec 2 14:13:03 2000 From: kellert at ohsu.edu (Tom Keller) Date: Wed Aug 4 00:05:14 2004 Subject: passing temp file names to another script Message-ID: Greetings, I am creating a temp file with some "current" data in it. I want another script to have access to this temp file. How do I give the second script the filename? I create the temp file using IO::File $fh = IO::File->new_tmpfile or die; then write the data to $fh. How do I get the temp file name to another script? Thanks, Tom Keller PS. Whenever you want to have another meeting at OHSU. It's available. The last one was excellent, as was the gathering afterwards at the pub. Thomas J. Keller, Ph.D. Oregon Health Sciences University MMI Core Facility 503-494-2442 kellert@ohsu.edu http://www.ohsu.edu/core TIMTOWTDI From rtanner at cheshire.onlinemac.com Sat Dec 2 14:44:16 2000 From: rtanner at cheshire.onlinemac.com (Rob Tanner) Date: Wed Aug 4 00:05:14 2004 Subject: passing temp file names to another script In-Reply-To: Message-ID: <7810000.975789856@cheshire.onlinemac.com> --On Saturday, December 02, 2000 12:13:03 PM -0800 Tom Keller wrote: > Greetings, > I am creating a temp file with some "current" data in it. I want another script > to have access to this temp file. How do I give the second script the filename? > > I create the temp file using IO::File > $fh = IO::File->new_tmpfile or die; > then write the data to $fh. > > How do I get the temp file name to another script? > Tom, Insufficient problem definition. Do you mean two programs that run at different times or two programs running simultaneously? Is there any reason you can't use a standardized file name (e.g., mytemp or mmi.data, etc) so that both programs already know the name? Is there any reason you can't have another file somewhere that both programs know about and the first can write the filename there for the second to read? Lastly, you can delve into the world of interprocess communication and set up either a named pipe or UNIX socket, etc. Details are pretty well covered in both the camel book and the cookbook. Hope that helps > Thanks, > Tom Keller > > PS. Whenever you want to have another meeting at OHSU. It's available. The last > one was excellent, as was the gathering afterwards at the pub. > BTW: On my calendar I have marked a gathering for this Tuesday (social I think), but I don't have any other information. Am I just out is left field (probably true in any event) or did I get too carried away deleting on subject line? Or has it just fallen through the cracks. BTW2: About getting carried away deleting based on subject lines, is it possible to get majordomo to prepend '[PDX-PM]' to the subject line? At least that way I would KNOW that I just deleted something I shouldn't have. -- Rob _ _ _ _ _ _ _ _ _ _ /\_\_\_\_\ /\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_/ /\/_/ /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon rtanner@cheshire.onlinemac.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://mail.pm.org/archives/pdx-pm-list/attachments/20001202/2cce2cca/attachment.bin From rtanner at cheshire.onlinemac.com Sat Dec 2 15:12:47 2000 From: rtanner at cheshire.onlinemac.com (Rob Tanner) Date: Wed Aug 4 00:05:15 2004 Subject: Any perl/tk gurus out there??? Message-ID: <8730000.975791567@cheshire.onlinemac.com> Greeting to all, I have a window with a scrollable list box, and I bound the up/down arrow keys, page up/down, etc, so that I can scroll the box from the keyboard. The keys are all bound to the main window, simply $mw. The listbox contains sorted data, so it's a natural for a quick and dirty simple search. I added an entry widget (the only one in the application) so that the program searches and displays as I type. Thus I also bound to the entry widget with a callback to the search routine. The problem is that once I've clicked into the entry widget, the binding attached to that widget gobbles up my motion keys. I've played with bindtags without success. I also tried creating a virtual binding and doing event deletes for the arrow keys. So, other than doing 96 separate and specific bindings (one for key), how do I keep the entry widget binding from seeing keystrokes bound to $mw? BTW: I mentioned that the widget is the only entry widget -- that also means that once you get the cursorin, you can't get it out again, which is only a problem because of the binding issue. Also, once the cursor is in the entry widget, disabling the widget, besides being a pain in terms of user friendliness, doesn't resolve the problem. -- Rob _ _ _ _ _ _ _ _ _ _ /\_\_\_\_\ /\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_/ /\/_/ /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon rtanner@cheshire.onlinemac.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://mail.pm.org/archives/pdx-pm-list/attachments/20001202/aa9ee538/attachment.bin From tex at off.org Sat Dec 2 16:33:52 2000 From: tex at off.org (Austin Schutz) Date: Wed Aug 4 00:05:15 2004 Subject: passing temp file names to another script References: Message-ID: <200012022233.OAA09093@peace.off.org> On Sat, Dec 02, 2000 at 12:13:03PM -0800, Tom Keller wrote: > Greetings, > I am creating a temp file with some "current" data in it. I want another script to have access to this temp file. How do I give the second script the filename? > > I create the temp file using IO::File > $fh = IO::File->new_tmpfile or die; > then write the data to $fh. > > How do I get the temp file name to another script? > Here's a bad answer: # Returns hashref w/ each file being a key that has a value of 1. sub get_open_files { my($filenames) = {}; my(@lsof_open_files) = `lsof -p $$`; shift @lsof_open_files; for(@lsof_open_files) { chomp; $filenames->{(split(/\s+/, $_))[8]} = 1; } return $filenames; } my($before_open_files) = get_open_files(); $fh = IO::File->new_tmpfile or die; my($after_open_files) = get_open_files(); my($tmp_file_name); for(keys(%$after_open_files)) { if(! exists($before_open_files->{$_})) { $tmp_file_name = $_; last; } } print "File opened is: $tmp_file_name\n"; No, I haven't actually tried to run this. But is seems like it would work in theory. I'm sure there's some magical way of doing this but I wouldn't know what. Austin TIMTOWTDI From tex at off.org Sat Dec 2 23:31:24 2000 From: tex at off.org (Austin Schutz) Date: Wed Aug 4 00:05:15 2004 Subject: New module: Debug_Messages Message-ID: <20001202213124.A10240@gblx.net> Who: me Where: http://off.org/debugm.tgz When: now What: New debugging module This module is one of my favorite pieces of my own code, which I haven't released to the public until now for fear that everyone would tear it apart and tell me what a dork I am for releasing it because there are similar tools, etc. etc. etc. Anyway, I figured by letting a few people try it on this small list that I could get some feedback before going further with it. There's a few different ways of using this module, so if the first bit doesn't seem interesting to you, please keep reading. Debug_Messages (better name suggestions are welcome) is a debugging and error reporting swiss army knife. It allows you to: -debug variables and entire perl object structures quickly and easily. -trace the execution of your code, in part or in full. -do more effective and concise error handling. -pinpoint how your code is executed. -provide debugging facilities to the users of your code. -do all of the above in any of syslog, stderr, or stdout in html format. Ok, did you get all that? There's a longer explanation of what the module is/does below. Why: Because there is no existing tool that is as complete in its utility, and because it provides a clean and consistent error reporting device. It's very different (and better, IMO) than anything you might think is similar, e.g. Carp. Please let me know what you think. Austin perldoc Debug_Messages: Debug_Messages(User Contributed Perl DocumentaDebug_Messages(3pm) DESCRIPTION A module for concise error reporting, process tracing, variable debugging. Multiple destinations are easy, so you can send output to a web page, syslog, or STDERR without extra code. Debugging code is very easy to use and may be left in the final version of scripts without creating a lot of overhead. You should really look at the docs on each sub to have an idea what can be done with this module. use Debug_Messages; use Debug_Messages ':standard'; :standard includes everything that can be imported. The following can be imported from Debug_Messages: debug() trace() marker() vprint() perror() eappend() eprint() eclear() The following special variables affect the behavior of Debug_Messages: debug(@messages) debug is handy for displaying non-error messages. debug prints a marker, followed by separate indented lines for each message, e.g.: $Debug = 2; sub test { debug "hello"; } produces: debug 2: ./test.pl line 8, package main: main::test(): hello Note that debug in this case would print _nothing_ if $Debug were less than 2 or undefined. See the next example for clarification. 2/Dec/2000 perl 5.005, patch 03 1 Debug_Messages(User Contributed Perl DocumentaDebug_Messages(3pm) One of the handy things this allows you to do is create a trace of the execution of your program, e.g.: use Debug_Messages ':standard'; $Debug = 4; sub a { debug; b(); } sub b { debug; c(); } sub c { debug; print "hi there\n"; } a(); produces: debug 2: test.pl line 8, package main: main::a() debug 3: test.pl line 13, package main: main::b() debug 4: test.pl line 18, package main: main::c() hi there The number after 'debug' refers to the recursive 'depth' of the call. If you set $Debug = a smaller number, you will only see lines that are of lower depth. Here's the output with Debug set to 3: debug 2: test.pl line 8, package main: main::a() debug 3: test.pl line 13, package main: main::b() hi there Notice that the variable set is $main::Debug. Debugging level is set per package, so you can debug or not debug each package. See the Special Variables section for more information. trace($depth) Will return an array representing a subroutine stack trace. Ex.: sub a { b(); } sub b { c(); } sub c { print( map( " ".$_."\n", trace())); } a; produces: 2/Dec/2000 perl 5.005, patch 03 2 Debug_Messages(User Contributed Perl DocumentaDebug_Messages(3pm) ./test.pl line 5, package main: main::c() ./test.pl line 4, package main: main::b() ./test.pl line 3, package main: main::a() ./test.pl line 6, package main: (not in a sub) trace is mostly used like: debug( trace ); which would output: debug 4: ./test.pl line 7, package main: main::c(): ./test.pl line 7, package main: main::c() ./test.pl line 6, package main: main::b() ./test.pl line 5, package main: main::a() ./test.pl line 8, package main: (not in a sub) marker($starting_depth,$maximum_depth) Like trace, but by default only returns the first line. Typically you would just call marker();. It will create a trace of calls starting with whatever the starting depth is. This is handy if you have a sub that wants to report a marker of its parent. Ex: sub test { report(); } sub report { print "Marker from test:".marker(1); } marker(), which is the first line printed by debug(), is a string, or array of strings, containing the following: $filename line $line_number, package $package $I( @sub_args ) e.g. "./test.pl line 5, package main: main::a()" where $filename is the file containing the marker() line, $line_number is the line in $filename where marker() was called, $package is the package in scope where marker() was called, $sub is the name of the sub being executed where marker was called, and @sub_args are the arguments which were passed to $sub when it was called. vprint(\variable, 'variable name', $recursive_display_depth); 2/Dec/2000 perl 5.005, patch 03 3 Debug_Messages(User Contributed Perl DocumentaDebug_Messages(3pm) Print a marker, followed by the name and contents of variable. Both the name of the variable and $recursive_display_depth are optional. vprint needs to be passed B<_a_reference_to_> the variable in question, indicated as \variable above. 'variable' can be a variable of any type, or a reference to a variable of any type. vprint knows how to deal with SCALARs, ARRAYs, HASHes, GLOBs, and CODE refs. I wasn't sure to to represent a generic variable reference, so I chose \variable. Sorry for the confusion. 'variable name' is optional. It's not trivial to have vprint be able to tell what the name of a variable is with only its reference to go by, so you have to pass it if you want the name printed in vprint's output. Otherwise vprint will print '(no name passed)'. $recursive_display_depth refers to how deep within the variable / object you want to go displaying the contents of references. Default is 20, which is pretty deep. perror(@messages) Like debug but will always print, not just when $Debug is set. eappend(@messages) Set error messages for the current location. This is extremely handy for giving detailed information about why something failed. Ex.: sub get_filehandle { local(*FILE); my($filename) = shift; unless( open(FILE, $filename)) { eappend( "couldn't open file", $!); return undef; } return \*FILE; } sub process_file { my($filename) = shift; my($file); unless( defined($file = get_filehandle($filename))) { eappend( "Couldn't get filehandle" ); return undef; } ... } unless(defined(process_file($my_file))) { eappend( "Couldn't process $my_file"); eprint(); exit; } 2/Dec/2000 perl 5.005, patch 03 4 Debug_Messages(User Contributed Perl DocumentaDebug_Messages(3pm) This is extremely handy method for a few reasons. First, the error isn't necessarily printed by any of the subs that get called. This is important if you are writing a module where someone else may not want you crapping your error messages to the screen. It's up to them to do it. eappend() merely stores the errors. Second, errors are extremely verbose and printed (by eprint) in a very easy to read fashion pinpointing the exact location and nature of the problem. Third, calling subs get to decide whether or not an error is catastrophic or ignorable. Fourth, Debug_Messages can print messages to several locations (or none!) depending on the whim of the user. Maybe error messages should be printed to syslog, or maybe they should be totally ignored. Or maybe the errors should be in html because the user has a web application. Fifth, there are probably other reasons I can't think of right now. eprint() print errors to all configured places, then clear errors. See the special variables section for details. Returns the errors as a string as would be printed to STDERR if $Debug_Messages::Debug_Styles->{stderr} is set. eclear() clears $Debug_Messages::Errors; Useful if you have caught and ignored an error, or dealt with the error manually. close_log() close syslog handle. Useful if you want to change the syslog facility. Close the log, which will automatically be reopened the next time a message is printed. See special variables for syslog vars. Special Variables $Debug_Messages::Errors is an array reference containing the stack of the last error messages and their "depth". More on this in the 'Internals' section. 2/Dec/2000 perl 5.005, patch 03 5 Debug_Messages(User Contributed Perl DocumentaDebug_Messages(3pm) $Debug_Messages::Debug_Styles is a hash ref containing the different output styles currently selected, e.g.: $Debug_Messages::Debug_Styles = { 'stderr' => 1, 'html' => 1, 'syslog' => 1 } will turn on all styles of printing. 'stderr', 'html', and 'syslog' are the currently supported styles. $Debug_Messages::Indent_String, normally set to ' ' x 8, is the string used to format errors printed to STDERR. $Debug_Messages::Auto_Clear_Errors, if set, eprint() will clear the $Debug_Messages::Errors variable after printing errors. Set to 1 by default. $Debug_Messages::Syslog_Facility is the facility syslog uses for syslog messages. Default is 'local3'. Do close_log(); $Debug_Messages::Syslog_Facility='new_facility'; if you want to change the facility. $Debug_Messages::Syslog_Debug_Priority is the priority used for debug messages. Default is 'debug'. $Debug_Messages::Syslog_Error_Priority is the priority used for error messages. Default is 'err'. $Debug_Messages::Print_Args is used to determine whether or not to print the arguments to a sub in marker(). Not putting in the args can be useful in the situation where you don't want the user to see them, e.g. you pass a password to a routine. marker will then print the number of args passed to the sub. $Debug is the depth of debug calls that will be printed when debug is called. If unset no debugging messages will be printed. Notice that Debug can be set B or in main::. This is an extremely important point. The reason for this is to make it possible to only debug messages from a certain package, if the user so wishes. If the caller's $Debug is set, its value will have precedence over $Debug_Messages::$Debug, which has precedence over $main::Debug. Setting $Debug to a large number and putting debug; at the top of each of your subs will generate a call trace when your program is run. $Syslog_SockType is set to 'unix' by default. This is the type of socket Sys::Syslog will use when Debug_Messages internally calls setlogsock(). This only applies if you are logging to syslog, naturally. See perldoc Sys::Syslog for clarification. 2/Dec/2000 perl 5.005, patch 03 6 Debug_Messages(User Contributed Perl DocumentaDebug_Messages(3pm) Internals The $Debug_Messages::Errors variable contains the output from eappend. It looks is an arrayref that looks like: [ [ $depth, [ @messages ] ], [ $depth2, [ @messages2] ], ... [$depthN, [ @messagesN] ] ] Where each depth is how far back caller($depth) could go before coming up undefined. The messages are the messages (including a marker as the first item in the array) passed to eappend. In practice having a single variable to hold all errors seems to work well. It is much more convenient than having one per package or using a scheme like blessing a 'Debug_Messages' object and doing $object->eappend(@messages). BUGS My experience with Sys::syslog::openlog() is that is returns undef even when it succeeds. Syslog may silently fail, and I'm not really sure what to do about that. 'recursive depth' is used by using caller() until it returns undef. See perldoc caller() for the limitations of caller(). AUTHOR Austin Schutz (tex@off.org) 2/Dec/2000 perl 5.005, patch 03 7 TIMTOWTDI From daniel at chetlin.com Mon Dec 4 02:45:11 2000 From: daniel at chetlin.com (Daniel Chetlin) Date: Wed Aug 4 00:05:15 2004 Subject: HTML::TreeBuilder, Tidy.exe In-Reply-To: <3A144F9C.23E2CED9@vpservices.com>; from jeff@vpservices.com on Thu, Nov 16, 2000 at 01:20:28PM -0800 References: <20001115142918.J314@surly.eli.net> <20001116022715.A999@darkstar.chetlin.org> <3A144F9C.23E2CED9@vpservices.com> Message-ID: <20001204004511.I9244@darkstar.ebizquality.net> [ Finally started to catch up with email, news, and work backlog created from Thanksgiving vacation. Sorry for the tardiness. ] On Thu, Nov 16, 2000 at 01:20:28PM -0800, Jeff Zucker wrote: > Daniel, thanks for a great talk the other night. My pleasure. [snip] > Here's a snippet that will change the base href if one exists, or > insert one if none exists. [snip] > Is this how you'd do it? > > sub insert_base { > my($html_string,$new_URI) = @_; > use HTML::TreeBuilder; > my $tree = HTML::TreeBuilder->new; > $tree->parse($html_string); > $tree->eof; > my $head = $tree->look_down('_tag','head'); > my $base = $tree->look_down('_tag','base') > || $head->new('base'); > $base->{href} = $new_URI; > $head->push_content($base); > $html_string = $tree->as_HTML; > $tree->delete; > return($html_string); > } I would probably use TokeParser for this task, but if doing it in TreeBuilder, it would likely look similar to that. > Interestingly this works regardless of whether the original HTML > includes a head tag or not, since TreeBuilder seems to insert one if > none exists. Yep; that's one of TreeBuilder's interesting quirks^Wfeatures -- it creates fairly standard/correct HTML where none existed to begin with. I don't often use TreeBuilder to create HTML, partially because of this; generally my uses for TreeBuilder are its ability to show me how a browser would parse HTML, and to help in pulling specific content from a document. -dlc TIMTOWTDI From tex at off.org Mon Dec 4 15:06:25 2000 From: tex at off.org (Austin Schutz) Date: Wed Aug 4 00:05:15 2004 Subject: New module: Debug_Messages In-Reply-To: <20001202213124.A10240@gblx.net>; from tex@off.org on Sat, Dec 02, 2000 at 09:31:24PM -0800 References: <20001202213124.A10240@gblx.net> Message-ID: <20001204130625.A14783@gblx.net> Well I can tell from the number of downloads that people have real work to do. :-) Anyway, I had an idea last weekend that I added to the module in the form of the following: A try() sub that allows you to do error handling quickly, e.g.: sub drive_to_town() { try(get_in_car(), "Can't get in car" ) || return undef; try(start_car(), "Can't start car") || return undef; try(drive_car(), "Can't drive car") || return undef; } sub(get_in_car()) { try(unlock_car_door(), "Can't unlock car" ) || return undef; try(sit_in_car(),"Can't sit in car" ) || return undef; } sub sit_in_car() { try( $drivers_seat, "There's no drivers seat" ) || return undef; } undef($drivers_seat); # Take it out to reupholster it unless (defined(drive_to_town()){ eprint(); } might generate the following stack trace: test.pl line 6, package main: main::drive_to_town(): Can't get in car test.pl line 9, package main: main::get_in_car(): Can't sit in car test.pl line 12, package main: main::sit_in_car(): There's no drivers seat Anyway, I always spend about half of my time writing perl code dealing with error conditions, so I think it's handy. Austin TIMTOWTDI