• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: One for the Unix gurus
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: One for the Unix gurus


  • Subject: Re: One for the Unix gurus
  • From: Allan Odgaard <email@hidden>
  • Date: Sat, 26 Jun 2004 10:59:08 +0200

On 26. Jun 2004, at 5:36, ryan wrote:

[...] The suggestion to investigate pseudo-ttys is a bit overboard,
many programs do what you are suggesting without resorting to ptys.

I'd second *investigating* it at least. Start with "man 4 tty" -- here I believe there is a ioctl function to manipulate device attributes. One of them is buffering mode, where stdin/out is by default buffered, and stderr is not, which could be why the OP only sees output from stderr (as you also implied).

Ptys are very complex to program - I've tried it... even 'advanced
programming in the unix environment' couldn't help me. Even reading
telnet source code wasn't helpful either. Best to avoid.

I can also second that! ;)

[...] If you are still stuck you can email me later and I should have more time to dig up a thing or two,

And, to the OP (and everyone else for that matter), post some of your code! When people post 95% working code I am much more inclined to taking a look and trying to fix it :) Oh... and do stop using these stupid subjects like "For the unix gurus", "Two simple questions", "Very simple questions" etc. -- DISCLAIMER: I am not the list moderator and am only expressing a personal bias here!

[...] and NSTask doesn't perfectly replicate this. Any responses that are buffered on the CLI side do not get flushed to the NSPipe you are listening/talking to.

For the records, I always end up dumping NSTask in favor of pipe+fork+execve -- not that I don't favor high level APIs, but with NSTask I always get into trouble or I want to manipulate the underlying file descriptors and it easily turns out to be much more code than with the "manual" pipe+fork+execve approach.

The problem is that I can't seem to get things like scp or ftp
working. For example, when running ftp from the command line, one
normally sees on the terminal a stream of information welcoming you to
the host, disclaimers, and finally an FTP> prompt. When I run ftp from
the GUI I've written (and I'm sure the arguments are being parsed
correctly), I only see the FTP> prompt in the NSTextView I've set up
to log stderr. Where does the other "stuff" go?

It's probably buffered -- but do you provide password on the command line? cause I do not think that you can just pipe the password to the ftp client.

I won't even talk about the stuff I'm trying to send to the command's
input -- I want to understand what's happening with the output first!
Any help would be appreciated immensely.

Well, you should talk about what you are actually sending to the client, as that might make the difference. But as implied above, the problem most likely is that stdout is buffered, and since ftp probably didn't close the stdout descriptor (since it's waiting for more input!?!), you won't see it -- but it might also just be your input which is wrong.

Try to store the input you give in a file and do "ftp < my_input" and see what that generates in the terminal.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >One for the Unix gurus (From: Glenn Zelniker <email@hidden>)
 >Re: One for the Unix gurus (From: John Pannell <email@hidden>)
 >Re: One for the Unix gurus (From: ryan <email@hidden>)

  • Prev by Date: Re: URL formatting in NSAttributedString
  • Next by Date: Re: URL formatting in NSAttributedString
  • Previous by thread: Re: One for the Unix gurus
  • Next by thread: Re: One for the Unix gurus
  • Index(es):
    • Date
    • Thread