SUMMARY: Interesting script problem

Thanks everyone who responded, Michael Maciolek and Dan Astoorian for the
solutions!

Here is the solution, provided by Michael Maciolek :

When a process is launched from cron, its 'standard input' (stdin) is
set to /dev/null.
   
Telnet disconnects when it cannot read from its (stdin).  You can see
this happen from the command line if you type:

	telnet some-system 1234 </dev/null

You'll get the initial 'connected' message, followed by an immediate
'connection closed' message as soon as telnet finds it can't read from
its stdin.
  
To get your cron task to work, you have to keep stdin open long enough
to read the response.  Here's a suggestion:

	#!/bin/sh
	sleep 5 | telnet some_system 1234 >file 2>&1

Adjust the sleep time according to your needs. 

>  -----Original Message-----
> From: 	Aleksandr Stolyar  
> Sent:	Thursday, October 04, 2001 10:56 AM
> To:	'sunmanagers@sunmanagers.org'
> Cc:	Aleksandr Stolyar
> Subject:	Interesting script problem
> 
> 
> 			I have a strange problem with a very simple script.
> I am using telnet to connect to a remote host on some port, and I am
> expecting certain output from that port, in the example below it is number
> 1.
> 			Ex:
> 			% telnet some_system 1234
> 			Trying 192.168.1.1
> 			Connected to 192.168.1.1.
> 			Escape character is '^]'.
> 			1
> 			Connection closed by foreign host.
> 
> 			Here is the script:
> 
> 			#!/bin/sh
> 			/usr/ucb/telnet some_system 1234 > file 2>&1
> 
> 			When I run the script from command line, I get the
> expected output in the file, but when I run the script as a cronjob, I get
> everything but my result, which in the example above is number:
> 			Trying 192.168.1.1
> 			Connected to 192.168.1.1.
> 			Escape character is '^]'.
> 			Connection closed by foreign host
> 
> 			So where else can number 1 go? I already redirect
> stdout and stderr.  I know the cronjobs do not inherit shell environment,
> so I even tried sourcing the startup files to set environment inside cron,
> but that doesn't help either.
> 
> 			Any help appreciated.
> 
> 			Thanks in advance!
> 
> 			Alex
> 
> 
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers