ronald@robobar.co.uk (Ronald S H Khoo) (08/04/90)
In article <9000@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: > If you have select: Err, last I looked, the "having of select(4 args)" was rather too heavily buried within the BSD networking package #ifdefs. I have the former, but not the latter (not on all my machines, at any rate), and I recall that it appeared to be more work than the 5 mins I had at the time to extricate it. Was I wrong ? Any chance of an "official" extrication thereof ? Cheers... -- Eunet: Ronald.Khoo@robobar.Co.Uk Phone: +44 81 991 1142 Fax: +44 81 998 8343 Paper: Robobar Ltd. 22 Wadsworth Road, Perivale, Middx., UB6 7JD ENGLAND.
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (08/07/90)
In article <1990Aug4.155801.6598@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: : In article <9000@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: : : > If you have select: : : Err, last I looked, the "having of select(4 args)" was rather too : heavily buried within the BSD networking package #ifdefs. I have the : former, but not the latter (not on all my machines, at any rate), and I : recall that it appeared to be more work than the 5 mins I had at the : time to extricate it. Was I wrong ? Any chance of an "official" : extrication thereof ? The chance is 1.0. Larry
cander@unisoft.UUCP (Charles Anderson) (10/04/90)
While debugging a script using the perl debugger, I noticed that
sometimes I could print variables (print $foo) and other times I
couldn't. Further investigation showed that after issuing a
"select(FILEHANDLE)" in the script under debug, printing variables
failed. I discovered that "print STDOUT $foo" works after the select.
Now, is this a bug or feature of the debugger that it doesn't notice
that default output file handle has changed? I would argue that it's
a bug and it's a pain to have to include STDOUT in every print command.
This was observed on a Pyramid running perl 3.0 Patch level 28.
--
Unix is the Winchester Mystery | Charles Anderson, UniSoft Corp.
House of software design. | {sun, ucbvax, uunet}!unisoft!canderlwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/04/90)
In article <3148@unisoft.UUCP> cander@unisoft.UUCP (Charles Anderson) writes:
: While debugging a script using the perl debugger, I noticed that
: sometimes I could print variables (print $foo) and other times I
: couldn't. Further investigation showed that after issuing a
: "select(FILEHANDLE)" in the script under debug, printing variables
: failed. I discovered that "print STDOUT $foo" works after the select.
: Now, is this a bug or feature of the debugger that it doesn't notice
: that default output file handle has changed? I would argue that it's
: a bug and it's a pain to have to include STDOUT in every print command.
This is why there's a "p" command. You shouldn't be depending on STDOUT
for debugging output anyway, since it might be redirected somewhere. The
"p" command prints to DB'OUT, which is opened on /dev/tty. It's only
accidental that "print" happens to work, because the debugger executes
an unrecognized command as a Perl statement. And Perl lets you select
your default filehandle for the print statement.
If your reflexes cause you to type "print" when you really want "p", then
alias "print" to "p".
Larry