Re: Determining size of Standard_Input (when file contents are piped into a program).

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 19-01-07 05:05 , Keith Thompson wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> On 19-01-06 13:02 , Bojan Bozovic wrote:
>>> Is there platform independent way to do this? I was unable to find
>>> anything in RM under Ada.text_IO.
>>
>> I would say that this is impossible in principle. On some systems, other
>> concurrent programs can write more data into the input file as your
>> program is reading the file, so the input file can grow during the
>> execution of the program, and may not even have any fixed upper bound on
>> its size (apart from the total space available in the system).
>>
>> IMO the only robust way is to read all of standard input and store it
>> within the program, or in a temporary file, and then process the stored
>> data.
>
> I mostly agree, but it could be possible in some limited
> circumstances.
>
> For example, if a program on Linux has its standard input redirected
> from a file, the system still keeps track of the identity of the
> file (/proc/$PID/fd/0 is a symbolic link to the file).

Ah, good to know.

> You can then determine the size of that file.

Yep, but the file-size may grow with time and -- on some systems -- the 
added data may become visible (readable) to a program reading the file. 
But not on all systems -- I ran across this quirk when a certain 
multi-process application which worked under Linux did not work under 
Apple OS/X, because it used such a growing file to communicate data from 
one process (writer) to another (reader). On OS/X, the reader never saw 
any data that the writer wrote _after_ the reader opened the file. Of 
course this may also depend on the Ada run-time in some way, although in 
both cases GNAT was used.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .