1

Topic: File descriptors

Explain, please, as this fragment works here: https://github.com/Member1221/sharpmake … #L504-L543 There there is a cycle in which lines are read out from stdout and stderr in turn. It seems to me an error as there is in  c a binding/synchronization between an output in stderr and stdout. I.e. the author of the program deduces messages in one order, and this fragment will mix an output in other order. All is correct or I do not understand something?

2

Re: File descriptors

Hello, Ejnstok Fajr, you wrote: > it seems To me an error as there is in  c a binding/synchronization between an output in stderr and stdout. I.e. the author of the program deduces messages in one order, and this fragment will mix an output in other order. stdout and stderr is 2 different file flows, with all from this following. Opening both, it is possible to read from everyone independently. To similarly that it is possible to read independently from two flows opened on different files. By the way, under a bushel here files also lie (more precisely, )

3

Re: File descriptors

PD> it is possible to read independently from two flows opened on different files. I was mistaken, in a C communicate among themselves not stdout and stderr, and stdout and stdin: http://qaru.site/questions/211294/why-d … nd-stdcout

4

Re: File descriptors

PD> stdout and stderr is 2 different file flows But when there is the virtual terminal, at it there only two handle - one for input and one for an output. It means that stdout and stderr both are located in one flow in the certain order, and this code breaks this order. I.e. in the present console of the message will be in one order, and at handling by this program - in other. And from this undesirable effect it would be desirable gets rid.

5

Re: File descriptors

Hello, Ejnstok Fajr, you wrote: PD>> stdout and stderr is 2 different file flows > But when there is the virtual terminal, at it there only two handle - one for input and one for an output. > It means that stdout and stderr both are located in one flow in the certain order, and this code breaks this order. > I.e. in the present console of the message will be in one order, > and at handling by this program - in other. And from this undesirable effect it would be desirable gets rid. If it so, means, in the terminal is caused expressly or by implication freopen http://www.cplusplus.com/reference/cstdio/freopen/ This function is especially useful for redirecting predefined streams like stdin, stdout and stderr to specific files (see the example below).

6

Re: File descriptors

PD> If it so, means, in the terminal is caused expressly or by implication freopen Not so understood, at what here freopen and at what here the program "terminal", after all both of them in the code in a considered fragment C# do not correct an error. So, there are two scenarios: 1) forms the terminal, in it is launched bash, it launches the application program, the application program deduces in stdout and stderr thus stderr and stdout physically get to one "channel" in that sequence as they are deduced by application program 2) the program on C# launches the application program, the application program deduces in stdout and stderr thus the program on C# alternates lines from stderr and stdout as it is pleasant to it. That fact that somewhere in the terminal something has been caused that the program on C# is written crookedly does not influence in any way.

7

Re: File descriptors

Hello, Ejnstok Fajr, you wrote: > 1) forms the terminal, in it is launched bash, it launches the application program, the application program deduces in stdout and stderr > thus stderr and stdout physically get to one "channel" in that sequence as they are deduced by the application program quite probably that this application program reassigned all on one flow. > 2) the program on C# launches the application program, the application program deduces in stdout and stderr > thus the program on C# alternates lines from stderr and stdout as it is pleasant to it. > That fact that somewhere in the terminal something has been caused that the program on C# is written crookedly does not influence in any way. She simply reads in the assumption. That it is different flows, that's all. Generally it is true.

8

Re: File descriptors

PD> She simply reads in the assumption. That it is different flows, that's all. Generally it is true. This simply simplifying assumption. Wrong. Because of its abnormality then in the real world there are problems at users: https://bugs.eclipse.org/bugs/show_bug.cgi?id=9720 https://hisham.hm/2016/11/24/fun-hack-t … -in-order/ https://unix.stackexchange.com/question … xs-command https://stackoverflow.com/questions/176 … provenance https://github.com/jupyter/help/issues/111 https://askubuntu.com/questions/382375/ … rong-order https://superuser.com/questions/517256/ … and-stderr

9

Re: File descriptors

Hello, Ejnstok Fajr, you wrote: PD>> She simply reads in the assumption. That it is different flows, that's all. Generally it is true. > This simply simplifying assumption. Wrong. Because of its abnormality then in the real world there are problems at users: your Business. You can consider it as the simplifying and wrong assumption, but nevertheless it so. For Linux I will not be guaranteed, but here for Windows https://docs.microsoft.com/en-us/window … tstdhandle it is possible to receive  all three flows, that is file . And when in Windows business reached native it HANDLE - the known rules, concerning these  (HANDLE there is an implicit pointer on a kernel object, and for everyone HANDLE this kernel object) here start to operate.

10

Re: File descriptors

1. The problem at users is 2. The problem needs to be solved (me - for Linux, in Windows for the decision of problems there is a Microsoft) 3. Without the proof to say that this problem a problem is incapable of solution - without adducing any proof. 4. Presence of three descriptors proves nothing

11

Re: File descriptors

Hello, Ejnstok Fajr, you wrote: > I.e. in the present console of the message will be in one order, > and at handling by this program - in other. And from this undesirable effect it would be desirable gets rid. And can  be mutually exclusive, i.e. it is written either in stderr, or in stdout? Therefore they also can be subtracted in one cycle.