Testing file handles

10 posts / 0 new
Last post
LyleHaze
LyleHaze's picture
Offline
Last seen: 1 year 4 months ago
Joined: 2011-05-26 03:58
Testing file handles

Code to print error message to the user, preferably to STDOUT or STDERR if available, but I'll open a CON: if those are not available.

  1. BPTR err_out;
  2.  
  3. // find best available output stream
  4. if(0 == (err_out = IDOS->ErrorOutput()))
  5. {
  6. err_out = IDOS->Output();
  7. }
  8.  
  9. if(0 == err_out)
  10. {
  11. err_out = IDOS->Open("CON:20/20/500/300/Error Output WIndow");
  12. }

This follows the comments in the ErrorOutput() autodoc by falling back
to Output() if ErrorOutput() returns zero.

Now the problem. If the program was run with redirection to nil:, I still
get an output handle, it's just not going to show anything I Write() to it.

Is there a way to test whether the file handle is re-directed to nil:, or
otherwise Write() impaired?

Thanks,
LyleHaze

jabirulo
jabirulo's picture
Online
Last seen: 11 min 27 sec ago
Joined: 2013-05-30 00:53
Doesn't IDOS->PutErrStr()

Doesn't IDOS->PutErrStr() take "care" where to show/output such error string?

AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonHD6570/SSD120GB/DVDRW :-P

hypex
hypex's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 2011-09-09 16:20
What about IsInteractive()

What about IsInteractive() ?

http://www.ummon.eu/En/Amiga/API/AmigaOS/Libraries/dos.library/IsInteractive.html

LyleHaze
LyleHaze's picture
Offline
Last seen: 1 year 4 months ago
Joined: 2011-05-26 03:58
@Jabirulo That will select

@Jabirulo
That will select between ErrorOutput and Output, but it will not tell me if either (or both) are going to nil:

@hypex
Thanks. That just might work. :)
I just made a working example with IsInteractive(), and it works well in the test code but the exact same code fails sometimes in the final program. Looks like I have more bug hunting to do.

Thanks to both of you!

LyleHaze

LyleHaze

xenic
xenic's picture
Offline
Last seen: 1 year 11 months ago
Joined: 2011-05-07 04:52
@LyleHaze Aren't you defying

@LyleHaze
Aren't you defying the users decision not to see output. Personally, I get really irritated when I redirect output to NIL: but still get console output. What's the point of using anycommand >NIL: *>NIL: if it has no effect?? What if all the AmigaDOS commands ignored redirection? Redirection, including NIL: redirection, is part of the way AmigaDOS works and should not be bypassed in my view. I think you should just return a "warning" code or "error code" (5 or 10) and set the secondary result code. This is all just my personal opinion.

X1000 - OS 4.1FE

LyleHaze
LyleHaze's picture
Offline
Last seen: 1 year 4 months ago
Joined: 2011-05-26 03:58
@Xenic, You make a good

@Xenic,
You make a good point, and under many conditions I'd agree with you fully.

What I have been doing lately though includes a few programs that must be started from user-startup.
While many understand output redirection, perhaps a few less than everybody understand that all three of stdin, stdout, and stderr must be re-directed if you want user-startup to complete normally and yield to the workbench.

So I jump through whatever hoops are necessary to make a program sever all ties with the parent shell by default, and then I am left with no simple means of notifying the user of a runtime failure.

Yes, if a user REALLY wants to ignore error messages they should have the option, but any program that wants to launch easily from user-startup has other issues to consider as well.

Maybe I should be launching from WBStartup instead..?? Something to think about for sure.
Thanks for your feedback!

LyleHaze

xenic
xenic's picture
Offline
Last seen: 1 year 11 months ago
Joined: 2011-05-07 04:52
@LyleHaze I reread my post

@LyleHaze
I reread my post and it sounded more like criticism than advice which is not how I meant it. I suppose a command that detaches from the shell might be an exception. I was going to suggest a timed dos requester (IDOS->TimedDosRequester) or rhingio notification but those might not be available during early system startup. If your command is detaching early in startup, a console window is probably the most reliable and likely to work. However TimedDosRequester with a TDR_NonBlocking tag might work too. Good luck with your project.

X1000 - OS 4.1FE

LyleHaze
LyleHaze's picture
Offline
Last seen: 1 year 4 months ago
Joined: 2011-05-26 03:58
"I reread my post and it

"I reread my post and it sounded more like .."
No worries at all. However you meant it I will try to do something positive with it if I can.

Your points makes sense, and I am now wondering if WBStartup might be more friendly than S:User-startup anyway.
In truth there's a lot of "nice things" in AmigaOS4 that I am just not too familiar with. My classics never went past 3.1 (or was it 3.0?) and many of the features that came out since then I am completely unfamiliar with.. Like WBStartup. I think there used to be a startup directory of some sort, but I'm not even too sure about that. I found WBStartup in prefs almost by mistake.. Some other things like dockies, ringhio, file notifications, and soft links are also things I need to learn more about.
The point I am trying to make is that I am not so smart that I shouldn't keep my mind open for better ways to do things. I appreciate suggestions that help me to do things better.

If I ever get so smart that I won't listen to other people.. well, that won't be a good day for me.

I am discussing this project now with a few others, and I am looking in to whether S:User-startup or WBStartup would work best for this program.

Thanks again. :)

LyleHaze

broadblues
broadblues's picture
Offline
Last seen: 4 years 1 month ago
Joined: 2012-05-02 21:48
What I have been doing lately


What I have been doing lately though includes a few programs that must be started from user-startup.
While many understand output redirection, perhaps a few less than everybody understand that all three of stdin, stdout, and stderr must be re-directed if you want user-startup to complete normally and yield to the workbench.

So I jump through whatever hoops are necessary to make a program sever all ties with the parent shell by default, and then I am left with no simple means of notifying the user of a runtime failure.

Don't do that. If some user doesn't undertsnd how to add a program to user startup with the correct redirection, then they will soon learn.

So unless your program always needs to detach from a console for functional reason, don't try and save the user pain in this way. Better to create an installer script that will set it up for them.

You then have correct access to the streams you need, and the user can remove redirection or redirect to a file to see the debug / error output.

broadblues
broadblues's picture
Offline
Last seen: 4 years 1 month ago
Joined: 2012-05-02 21:48
Bit more to your original

Bit more to your original question if you want to see where a FileHandle points too, try DevNameFromFH(), or perhaps ExamineObjectTags()

Log in or register to post comments