Chris Breemer Wrote:

<snip my reply text deleted>

@ Ok, that's good enough for me at this moment. Just put a script around it that
@ always suplies the -n flag. Still, it worries me; why would "ls -l" need
@ anything from STDIN ? Why does "uname -a" not have this problem ?

  It worries me as well. It's even more worrisome that if you do do
  remsh;info="foo -l user ls"
  and hit CR once or twice, you get the output.....
  So someone is waiting for something.

  To be honest I didn't think too much about it since the Unix version
  points out that things like more  are not useable due to their reading
  of STDERRR. I assumed this was more of the same. Ah well that's the joy
  of assumptions. Asi es la vida.

  Hopefully I'll be able to work on this today.

 <snip discussions of -n option and implementing client portion of
 functionality but not server, deleted>

@ >  I looked at the remshd issue enough to know it's not a quick and easy
@ >  implementation. That's why it's likely to be something one of us can't
@ >  add via CPE or Gee-job routes. Sorry.
@ >
@ So if it's easy, it just gets slipped in, but if it's not it needs a business
@ case... Doesn't that sound familiar !

  Well it ought to. Sorry but it is a fact of life that HP wants to make
  money off our time. So if it's easy to do, it's easy to get permission
  to do it, or easy to do on our own time. Otherwise we have to prioritize
  the work based on what the most customers will get a benefit from and
  therefore continue to fund us by buying new machines. I understand the
  frustration on your end, but I can't think of a better way to do the
  business myself.

 <snip observation that TIO is a problem for interoperability and that I
  may be linking the rlogin issue to remshd improperly in my head deleted.
  I'll try to come back to those in a future message>

@ BTW Why is remsh not served by inetd ? That's something I have never
@understod.

 I assume you're wondering why remsh client is not handled under inetd,
 but the server is. INETD is a superserver listening on the network for
 incoming service requests. It is designed to spawn off servers(daemons)
 for the requested service. The client functionality is just a userspace
 application invoked through the CI or shell and needs no server daemon
 to do any work on the local machine. Telnet works the same way, ie
 there's a client and a server(telnetd). If you look in /usr/bin you'll
 see things like remsh, rexec, telnet, tftp and ftp (at least they're
 there on my HPUX 9.X system). These are all the client halves of the
 service (I think).

 I haven't addressed all of Chris' points. I'll come back to the others in
 a future message. I really want to look at this bloody ls hang he
 discovered. It's most annoying.

 Hope this helps and is of general enough content to be useful to the
 list.

 Later
 cas


--
=======================================================================
[log in to unmask] (Cas Caswell)   By the way: I said it, not my company.
 =======================================================================