So, this is a work thing, and work is kinda weird about what you can and cannot use. We have to use csh. We are also using clearcase, with a gui from the 1980's. I have worked on military classified projects, and my current company is the strictest place I've ever worked at. And we do consumer parts.
Anyway, I talked with someone who is like quasi IT for our group He couldnt figure it out. So he filed a ticket, and it has gone to our actual IT group, which is all based in europe. Apparently having IT people in the same building you work in is 'inefficient' I am doing a workaround for now. If I ever find out what the issue is, I'll let folks know. I will say that I didnt know anything about cshell scriots until now, and boy I wish I hadnt. I would have madd the whold scrit perl, but I am trying to boot something onto an existing project. Greg On Thu, April 27, 2017 1:02 pm, Andrew Feren wrote: > I'd definitely start by not using csh. It has a pile of problems as a > scripting language. Especially related to pipes and file descriptors. > > http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ > > > -Andrew > > >> On Apr 27, 2017, at 11:18, Bill Ricker <[email protected]> wrote: >> >> >> Apparently i replied off-list. Here's my reply for those following >> along at home. >> >> // Bill >> >> >> ---------- Forwarded message ---------- >> >> >> >> Is your interactive commandline provided by (ba)sh or [tcz]sh ? >> I see your script is Csh. >> That's one possible difference since that's where the pipe is actually >> created and sub-process spawned. >> >> $| won't >> do what you want. >> >> >> perldoc -v '$|' >> >> HANDLE->autoflush( EXPR ) >> $OUTPUT_AUTOFLUSH >> $| >> >> >> If set to nonzero, forces a flush right away and after every write or >> print on the currently selected output channel. Default is 0 (regardless >> of whether the channel is really buffered by the system or not; $| tells >> you only whether you've asked Perl explicitly to flush after each >> write). STDOUT will typically be line buffered if output is to the >> terminal and block buffered otherwise. Setting this variable is useful >> primarily when you are outputting to a pipe or socket, such as when you >> are running a Perl program under rsh and want to see the output as it's >> happening. This has no effect on input buffering. See getc for that. See >> select on how to select the output channel. See also IO::Handle. >> >> Mnemonic: when you want your pipes to be piping hot. >> >> >> If you want actual non-blocking output in an output pipe or to a >> file, I _think_ you'll need >> >> perldoc IO::Handle >> >> *$io->blocking ( [ BOOL ] )* >> >> >> If called with an argument blocking will turn on non-blocking IO if >> BOOL is >> false, and turn it off if BOOL is true. >> >> blocking will return the value of the previous setting, or the current >> setting if BOOL is not given. >> >> If an error occurs blocking will return undef and $! will be set. >> as in >> $io->blocking( 0 ) or croak "$!: io->blocking ( 0 )"; >> >> >> the "sub init" for SSL-capable netcat script "scnc" does : >> >> >> $SIG{INT} = sub { $self->exit }; >> $SIG{CHLD} = 'IGNORE'; >> >> >> STDOUT->blocking(0); >> STDOUT->autoflush(1); >> STDIN->blocking(0); >> STDIN->autoflush(1); >> >> >> >> _______________________________________________ >> Boston-pm mailing list >> [email protected] >> http://mail.pm.org/mailman/listinfo/boston-pm >> > > _______________________________________________ > Boston-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/boston-pm -- _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
