man \n

отложенная запись происходит или по \n или по exit(0), но уже в обеих процессах

правельней даже сказать по неявному close(stdio) в ядре при exit(0)

s/stdio/stdin/

Нашёл:

в некоторых версиях - перед любой операцией чтения из канала stdin (например, при вызове gets), при условии, что stdout буферизован построчно (режим _IOLBF, смотри ниже), что по-умолчанию так и есть.

Следовательно «\n» скидывает буфер, т.к. заканчивает строку.

внесите царя!

причём здесь c++

ну можно и рукаме fflush(stdout);

Выхлоп предсказуем:
faust@localhost 1]$ ./2
1234 1234 [faust@localhost 1]$

почему?

Тега C не нашёл.

потому что оба процесса пишут в один и тот же файл/буфер.

обеих процессах

правельней

Ну ничего, скоро снова в школу.

|почему?
А теперь вопрос: «Кто именно скидывает буфер?»
Я так понял, что это делает драйвер tty:

[faust@localhost 1]$ ./2 
1234 
[faust@localhost 1]$ ./2 >1
[faust@localhost 1]$ cat ./1
1234 
1234 
[faust@localhost 1]$

ну толсто же, ну.

Ну нельзя повеселиться что ли?

окей, не буду мешать.

Так призови его. Что тут сложного?
sudo cast carb_blog8
А то у меня нет настроения объяснять про работу fork и \a \b \f \n \r \t \v и т.д. А так и Царю развлечение и нам потеха.

он уже 8-й ник меняет???

Это последняя цифра года рождения.
</толсто>

По сабжу - ни разу не сишник, интересно.

На правах оффтопа

Тега C не нашёл.

си же.

Теперь увидел: ansi c называется :)

Стандартный, все-таки си. На нем в 9 раз больше тем.

Во втором случае вместо построчной буферизации поблочная, поэтому \n буфер не сбрасывает.

Это я уже понял. Но почему в обычном stdout система ведет себя по разному - сколько ещё ньюансов должОн учесть программер....
Ведь выхлоп загоняет в блочный pipe уже не прога а терминал/шелл...

те по \n флашит сама прога, конкретно вызываемая ей libc

сколько ещё ньюансов должОн учесть программер

это не важно, расценки в резюме

По \n флашит ОСь, а не libc. см. посты Обьясните суть происходящего при добавлении в stdout «\n» (комментарий) и Обьясните суть происходящего при добавлении в stdout «\n» (комментарий)

ты не можешь читать код? Обьясните суть происходящего при добавлении в stdout «\n» (комментарий)

в случае редиректа в файл libc отключает флаш по \n, например

По \n флашит ОСь, а не libc.

А теперь замени printf("1234 "); на write(1, "1234 ", 5);, и подумай ещё раз.

И как по-твоему libc узнаёт, что был редирект в канал, осуществлённый средствами bash?

Я не понял, какого хрена в первом варианте 2 раза напечаталось???

Тьфу ты! Дошло: форкнутый процесс унаследовал stdout буфер и по завершению выплюнул этот буфер! А во втором случае буфер был выплюнут до форка!!!

Вот:

/tmp/1.c                                                                                                                             137/137  KOI8-R       100%
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

int main()
{

  printf("1234 ");
  fflush(stdout);
  fork();
  exit(0);
}

И как по-твоему libc узнаёт, что был редирект в канал, осуществлённый средствами bash?

man isatty

Т.е. libc при старте начинает просматривать и открывать std-файлы (stdout,stderr,stdlog) и при открытии проверяет, а не tty ли файлик?
Если обнаруживает не-tty(в случае pipe) открывает файл как блочно-буферизированное, в случае tty(терминал) открывает как строчно-буферизированное?

Данунафиг!

Записью в файл занимается же ведро! А libc тупо буферизует строками в stdio. Не?

Дошло: форкнутый процесс унаследовал stdout буфер и по завершению выплюнул этот буфер!

Причём криво-форкнутый. Может проскочить ситуёвина, когда «ребёнок» не успеет что-либо вывести, а «папаша» уже закончит свою жизнь через exit(0) и грохнет только-только родившегося «ребёночка» :)
Это был «слегка» перефразированный «тест яндекса», положение и применение fork сохранено :D

Данунафиг

Я приводил пример с «\n» загнанный в pipe:
./2 > 1 | cat 1
где выводятся обе строки.

Ну так нужно ж демонизироваться "ребеночку", если папаша внезапно ласты склеить может... Не так это и сложно сделать ведь: позакрывал 1,2 и 3; открыл (если надо) вместо них /dev/null; заигнорировал SIG_HUP — вуаля!

Ну, получается, что баш трубы буферизует посимвольно. Сам.

А libc тупо буферизует строками в stdio. Не?

Не. Если isatty(1) == 1, буферизация stdout построчная, иначе поблочная.

Понятно. Я никогда как-то об этом не задумывался, потому что перед fork всегда делал close(1);close(2);close(3)

А isatty использую — чтобы выхлоп изменять (на консольку идет цветной, а в файл или пайп — обычный, чтобы спецсимволами не засирать.

Це ж пример из задачек «яндекса» по различию выхлопа stdout(строчный) и stderr(нет буфера).

Дурацкий пример.

Согласен.
Вот ещё одна идиотская математическая задачка от яндекса:
Дана функция на языке Python. Завершится ли когда-нибудь вызов dio()?Почему?

def dio():
       x = 1L
       while 1:
           for y in xrange(1, x):
             for z in xrange(1, y):
               if x*x == y*y + 12752041*z*z:
               return "Found it"
           x = x + 1

нет отступа при return -> завершится на первой же итерации?

//не питонист

Неправильно скопипастил - вот правильно:

def dio():
   x = 1L
   while 1:
       for y in xrange(1, x):
           for z in xrange(1, y):
               if x*x == y*y + 12752041*z*z:
                   return "Found it"
       x = x + 1

Пхытон == идиотизм априори.

Завершится ли когда-нибудь вызов dio()?Почему?

Судя по x = 1L, пытаются намекнуть на то, что xrange, работает только в диапазоне «коротких» чисел, а искомый ответ попадает в диапазон «длинных», поэтому найден никогда не будет.

Питон не знаю, считать лень :)

завершится если у уравнения x*x == y*y + 12752041*z*z есть решение

почему? потому что в питоне у лонга нет предела :)

x = 3572, y = 1, z = 1