Re: [Boston.pm] Fwd: script works ok on command line, hangs when run from shell script

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