RuntimeError 103 File not open

[Thaddy]

No, you are not too tired. It is Paule32. And he knows that and we are always trying to help.

[PascalDragon]

103 is one of the errors you can get when stdin/out/err or in real Pascal output/input and erroutput are not set.
On Windows, Lazarus defaults to that in a GUI application. (Why I do not know, it is a windows only issue)
If you add {$apptype console} these handles will be created.
You can subsequently hide the console window in code..

It is a really stupid decision that Lazarus works like that on Windows, but Hey who am I to complain?
The developers are aware of that platform only issue. 
There is no valid reason for it to be not solved after years from a technical point of view.
Btw this non-feature is Delphi compatible....

This is simply how Windows applications with subsystem type GUI behave. That has nothing to do with Delphi or Lazarus. ANY Windows application with subsystem type GUI will have its StdIO handles set to 0, only if it's of subsystem type CLI they will be allocated. You can see this easily when you start applications like notepad from the command line: the terminal will not be blocked by the program. If it would be of subsystem type CLI then it would block the terminal. This is simply how Windows is designed and both Delphi and Lazarus/FPC cater to this by defaulting to GUI for convenience considering that the main application type is a GUI application and you can be very sure that one of the first questions would be how to get rid of the console and followed by that how to have the application behave like any other GUI application on Windows.

So, no, this will not be changed.

[Thaddy]

Well, here's a unit that does what I proposed. It is also very safe and makes for the same behavior as in Linux.
Just include it in your GUI app and you won't get 103's and the likes:

Code: Pascal  [Select][+][-]

1. unit nuloutput;
2.  
3. interface
4.  
5. implementation
6. var
7.   Oblivion:Text;
8.   NullDevice:shortstring;
9.  
10. initialization
11.   NullDevice := {$IFDEF MSWINDOWS}'nul'{$ELSE UNIX}'/dev/null'{$ENDIF};
12. // Redirect standard output to NUL
13.   Assign(Oblivion, NullDevice);
14.   Rewrite(Oblivion);
15.   Output := Oblivion;
16.  
17. // Redirect standard input (optional, if used)
18.   Assign(Oblivion, NullDevice);
19.   Reset(Oblivion);
20.   Input := Oblivion;
21.  
22. // Redirect standard error
23.   Assign(Oblivion, NullDevice);
24.   Rewrite(Oblivion);
25.   ErrOutput := Oblivion;
26. end.

In fact you won't get anything because it writes to and reads from nul.
                               

[gues1]

It's better to use it under a global $DEFINE, 'cause if you forget these unit inside you app ... WriteLn will never work.

More better thing is to add the check if standard handle at runtime are in use and do the NULL assignement or not.

But, like I wrote I'm not a fan of this NULL assignement.

Bye

[Thaddy]

It was more like an exercise, but it can come in handy.
Advantages and disadvantages are the same as for any null device.
A good example for the use of any NUL device is to put it between {$ifopt D-}{$endif} to remove debug writes in release mode. This is more effective than conditionally compiling every single write with very little overhead.

See also:
https://en.wikipedia.org/wiki/Null_device

Above all, it will fix the original problem. -WG does not need to be removed.

[Thaddy]

@PascalDragon: I do not want to understand - but I do - your remarks as the fix is easy and I frankly can't find a valid reason not to implement this.
Redirection in code remains still possible, because the behavior is exactly like on Unix where the handles are already assigned to /dev/null or in some rare and special cases to a special but similar device.
And performance, or code size, is not an issue.

I think preventing IO errors and the fact that the use of a NUL device is present and supported is more important than that what you mentioned.

That on Windows an error is thrown if a console is missing is simply an incompatibility with Linux and can be fixed.
It is not an asset at all.

I think the LCL maintainers should consider this.

[marcov]

That on Windows an error is thrown if a console is missing is simply an incompatibility with Linux and can be fixed.

And since when is an OS that must be in its 25th attempt to have a "year of the lInux desktop" the gold standard for gui ?  ROTFL 

[gues1]

That on Windows an error is thrown if a console is missing is simply an incompatibility with Linux and can be fixed.

Is for that I cannot like NULL (in this case), is difform from Windows GUI standard (and also from logic).
And like I told, Windows is not Linux nor Unix.

I must agree with @PascalDragon.

[paule32]

it lay in your Hand's to write a Wrapper Member that consult the OS and check if it Windows or Linux ...
Then you don't need to thinking anymore which Device is to use - because the Wrapper Member does your Job.

This is the Standard Idea of nearly all Framework "to make" things easier by using standardized Class'es and Members.

I know this from C++ ...
There are an Standard C++ Library wich come with STD Container for Streams like:

std::cout <<  for Standard write Operation's on Console / Stream
std::cin   <<  for Standard read  Operation's on Console / Stream
std::cerr <<  for Standard write Operation's on Console / Stream for Error's

[Thaddy]

And since when is an OS that must be in its 25th attempt to have a "year of the lInux desktop" the gold standard for gui ?  ROTFL 

It isn't. It is about consistency between platforms.
We could also close the Unix handles instead (cross-platform 103, ROTFL). 

[marcov]

And since when is an OS that must be in its 25th attempt to have a "year of the lInux desktop" the gold standard for gui ?  ROTFL 

It isn't. It is about consistency between platforms.
We could also close the Unix handles instead (103 back ROTFL).

IMHO that should have happened for GUI programs 25 years ago yes.

[Thaddy]

Just curious Marco, WHY? Makes no sense. Btw closing the handles on Unix's works of course: "nice" IO errors.

Code: Pascal  [Select][+][-]

1. unit mutilateIO;
2. interface
3. implementation
4. initialization
5. $ifdef unix}
6.   close(output);
7.   close(input);
8.   close(erroutput);
9. {$endif}
10. end.

Windows compatible 103....
Toss a coin for the final solution 

( For others, even if less informed, test both options and tell us what you like best. Marco and I have a combined 70 years or so experience and like to tease now and then.)

[marcov]

Just curious Marco, WHY?

Simple. There can be only ONE. Either your standard input comes from the gui subsystem, or from the console subsystem.

Doing both makes no sense. But like many things Unix, everything is evolutionary, hard decisions are forever postponed( queue Wollmilchsau, Design by Committee). And the general Linux populace is extreme critical of any critique and behave they are the only true gospel.

[Thaddy]

Yes there can be only one .....consistent behaviour.... And I think the Unix one makes more sense for Lazarus.
Not my silly Windows compatibility unit for Unix. However funny to write it and test it.

[marcov]

Yes there can be only one .....consistent behaviour.... And I think the Unix one makes more sense for Lazarus.

I think Unix basically is a server OS now. So projecting it to be a leader or even relevant in a desktop sense is not even a funny hyperbole any more.