Что делает команда cat

[QWERTYASDF]

Поспорила тут с одним чуваком о том, так ли логически верно общепринятое определение команды cat, как команды объединения файлов. Особенно в контексте сравнения с такой сущностью, как каталог файлов в фс. Ведь, по сути, объединения файлов A и B через

Код: Выделить всё

cat A B

не происходит, а происходит объединение данных, содержащихся в этих файлах в некий третий файл (в данном случае, в файл stdout).
Есть ли в этих выкладках резон на Ваш взгляд?

[lazhu]

Поспорила тут с одним чуваком о том, так ли логически верно общепринятое определение команды cat, как команды объединения файлов. Особенно в контексте сравнения с такой сущностью, как каталог файлов в фс. Ведь, по сути, объединения файлов A и B через

Код: Выделить всё

cat A B

не происходит, а происходит объединение данных, содержащихся в этих файлах в некий третий файл (в данном случае, в файл stdout).
Есть ли в этих выкладках резон на Ваш взгляд?

Код: Выделить всё

% man cat
NAME
       cat - concatenate files and print on the standard output

SYNOPSIS
       cat [OPTION]... [FILE]...

DESCRIPTION
       Concatenate FILE(s), or standard input, to standard output.

[QWERTYASDF]

lazhu
Думаю, Вы совсем не внимательно читали написанные мною строчки. Но хоть за такое внимание, наверное, спасибо.

[yars]

man cat говорит, что cat копирует стандартный ввод или файл на стандартный вывод (первое -- без аргументов, второе -- когда передано в качестве аргумента имя файла. Файлов может быть и несколько). А объединение нескольких файлов получается уже благодаря не cat, а перенаправлению вывода.

[lazhu]

lazhu
Думаю, Вы совсем не внимательно читали написанные мною строчки. Но за внимание, наверное, спасибо.

Не за что. А Вы совсем невнимательно прочитали определение команды cat. В нем ни слова не сказано об объединении файлов.

Concatenate FILE(s), or standard input, to standard output

- последовательно вывести ФАЙЛ(ы) или стандартный ввод на стандартный вывод.

UPD: Как верно отметил предыдущий оратор, чтобы объединить файлы A и B, надо выполнить

Код: Выделить всё

cat A B > C

[QWERTYASDF]

Ок. Допускаю, что меня в очередной раз подводит мое не знание английского, и строки описания в мане переводятся именно как Вы сказали.

Резон моего вопроса в определенной запутанности вокруг cat (как, впрочем, и многого другого) для тех, кто не владеет (увы) нормально
английским и вынужден полагаться на те или иные русскоязычные источники. Ибо, во первых, все словари мне говорят примерно одно и тоже насчет
слова "concatenate" - само по себе оно переводится, как "сцеплять" (на мой взгляд синоним "объединять" звучит благозвучнее). Во вторых (надо
было сделать первым) такие, например, источники, как (беру навскидку) "Скотт Граннеман - Linux, карманный справочник" говорят примерно
следущее:

Имя команды cat представляет собой сокращение от слова cancatenate , т.е. объединения файлов. Основное назначение данной команды -
объединение нескольких файлов в один. Вывод на экран одного файла - лишь частный случай ее использования.

...Что, как понимаю, не верно, а я права в своем маленьком замечании: cat НЕ является программой конкатенации т.е. объединения файлов (?)

И до кучи. Все-таки,

Код: Выделить всё

cat A B > C

это разве объединение файлов? У нас ведь не создается некий гипотетический файл С с инодами и именами А и B ? Создается независимый файл С, в который помещается объединенное содержимое первых двух. Не?

[lazhu]

Ок. Допускаю, что меня в очередной раз подводит мое не знание английского, и строки описания в мане переводятся именно как Вы сказали.

Резон моего вопроса в определенной запутанности вокруг cat (как, впрочем, и многого другого) для тех, кто не владеет (увы) нормально
английским и вынужден полагаться на те или иные русскоязычные источники. Ибо, во первых, все словари мне говорят примерно одно и тоже насчет
слова "concatenate" - само по себе оно переводится, как "сцеплять" (на мой взгляд синоним "объединять" звучит благозвучнее).

Здесь употребляется не просто 'concatenate' (означающее, Вы абсолютно правы, именно "сцеплять", т.е. не просто объединять, а последовательно связывать в цепь), а переходная форма этого глагола 'concatenate to', что буквально перевести на русский невозможно, но смысл предельно понятен - последовательный вывод "на стандартный вывод" (to stdout)
BSD'шный и POSIX'овый маны дают более понятное определение:
FreeBSD:

The utility reads files sequentially, writing them to the standard output

- утилита читает файлы последовательно, выводя их на стандартный вывод.
POSIX:

The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence

- утилита cat прочитает файлы по порядку и выведет их содержимое на стандартный вывод в таком же порядке.

Во вторых (надо
было сделать первым) такие, например, источники, как (беру навскидку) "Скотт Граннеман - Linux, карманный справочник" говорят примерно
следущее:

Имя команды cat представляет собой сокращение от слова cancatenate , т.е. объединения файлов. Основное назначение данной команды -
объединение нескольких файлов в один. Вывод на экран одного файла - лишь частный случай ее использования.

...Что, как понимаю, не верно, а я права в своем маленьком замечании: cat НЕ является программой конкатенации т.е. объединения файлов (?)

Никогда не интересовался исходным текстом утилиты cat, возможно оный автор и прав, но исходя из официальной документации, его утверждение в корне неверно.

И до кучи. Все-таки,

Код: Выделить всё

cat A B > C

это разве объединение файлов? У нас ведь не создается некий гипотетический файл С с инодами и именами А и B ? Создается независимый файл С, в который помещается объединенное содержимое первых двух. Не?

Ну само собой cat работает не с инодами

[QWERTYASDF]

Ну, собственно, понятно. Спасибо : )

[drBatty]

http://emulek.blogspot.ru/2013/04/cat.html

[Bizdelnick]

А Вам не всё равно, как оно там "определяется" где-то?
Большинство юниксовых команд работают с текстом, в том числе в файлах. К тексту и относится это самое "объединение".
Тем, кто утверждает, что "concatenate" к соединению отношения не имеет, не помешало бы заглянуть в словарь.

[drBatty]

Bizdelnick
ага, а tar только для ленточных накопителей. И всем, кто его с HDD применяет, пора словарь смотреть, а кто с SSD пора к психиатору.

[QWERTYASDF]

drBatty
: ) Спасибо. Точно и креативно : )

Bizdelnick
Конкретно сейчас у меня вышел спор с человеком, чей статус претендует на гораздо большие IT-познания (в UNIX, в частности) по сравнению с моими. А он, ссылаясь на собственный статус и на источники, подобные приведенному, утверждает, что cat суть команда объединения файлов. С чем категорически не согласна я, ибо никакие файлы не объединяются. Однако много чего формально существует против здравого смысла, вот и решила уточнить на форуме. И потом, то, что в учебниках пишут ересь - само по себе раздражает.

[Bizdelnick]

ага, а tar только для ленточных накопителей. И всем, кто его с HDD применяет, пора словарь смотреть, а кто с SSD пора к психиатору.

Вообще-то да. Но куда деваться, если нормальных архиваторов нет.

[Hephaestus]

это разве объединение файлов? У нас ведь не создается некий гипотетический файл С с инодами и именами А и B ? Создается независимый файл С, в который помещается объединенное содержимое первых двух. Не?

Ну, как Вам сказать... Любое объединение файлов подразумевает объединение данных, содержащихся в этих файлах. Будь то cat или sox.
Потому что пользователя файл интересует прежде всего с точки зрения содержимого, а не инода. Сам по себе инод бывает нужен значительно реже. Поэтому для простоты формулировки говорят об объединении файлов.

Буквальное же объединение файлов, как вы говорите на уровне инодов и имён - оно вообще имеет смысл?
Вы можете придумать задачу, где бы это потребовалось?

[QWERTYASDF]

fflatx
Если говорить про объединение файлов буквально - то лично мне первым и последним приходит на ум каталог (файл и с именами и с инодами двух объединяемых). Какую-то еще сущность, для которой эта буквальная интерпретация имела бы смысл - не придумать.
А в случае с cat такая "простота", имхо, оборачивается лишними мытарствами на пути к пониманию сути. Пользователи, знаете ли, тоже разные ведь могут быть, с разными интересами.

[drBatty]

QWERTYASDF
ЕМНИП в исходниках cat вообще пусто - она как многие команды открывает файлы и их просто читает и просто выводит. Объединие получается лишь потому, что кошка _ничего_ не делает. К приеру sed '' *.txt тоже "объединяет" файлы. Единственное, что умеет делать cat осмысленного -- нумеровать строки с ключом -n.

Т.е. действительно, объединение происходит уровнем выше, ВНЕ команды.

Потому что пользователя

какая разница, что там кажется пользователю? Пользователям Win до сих пор кажутся floppy диски A: и B:. И что?

[QWERTYASDF]

drBatty
А вот тут немножко больше (или наоборот) на апельсинах. Не поняла, на каком уровне "выше"? И с кошкой-лентяйкой тоже не понятно. В каталоге открытых cat-процессом файлов или как происходит это "объединение"? )

[drBatty]

QWERTYASDF
ну cat читает первый файл, а потом, _независимо_ читает второй. Объединение получается лишь потому, что cat выводит в один и тот же файл. Если написать

Shell

$ tail f1; tail f2 хвост1 хвост2

мы увидим, что две tail тоже "объединяют" хвосты.

tail достаточно умная, и если заставить её печатать два хвоста сразу, она перед ними печатает ещё и заголовки,

# tail f1 f2

==> f1 <== a b c ==> f2 <== 1 2 3

ну а cat глупая, никаких заголовков не печатает, вот файлы и сливаются вместе.

[QWERTYASDF]

drBatty
Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст). Которое добавляется в третий файл стандартного выхода (последовательная распечатка текста файлов на экран).

[Bizdelnick]

Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст).

А кто сказал, что файл должен обязательно рассматриваться "в понятиях" той или иной ФС, тем более что изнутри разные ФС могут очень сильно отличаться? Пока мы не лезем внутрь ядра, всё, что нам может понадобиться от файла, - его содержимое.

[drBatty]

Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст).

ИМХО "файл" это ограниченная область информации. Т.е. содержимое файла -- это и есть файл. Но кроме содержимого у файла есть и атрибуты, например у многих файлов есть inode, а у некоторых файлов есть имена. Т.е. ИМХО неправильно разделять содержимое и атрибуты.

Которое добавляется в третий файл стандартного выхода (последовательная распечатка текста файлов на экран).

да. Но содержимое добавляется отдельно, объединяется оно уже внутри файла. Т.е. команды

$

cat f1 >f; cat f2 >>f

эквивалентны

$

cat f1 f2 >f

(за исключением того, что в первом случае файл f закрывается и сразу открывается лишний раз)

[drBatty]

А кто сказал, что файл должен обязательно рассматриваться "в понятиях" той или иной ФС

а где вы видели файлы вне фс? Файлы они на то и файлы, что-бы лежать в фс.

тем более что изнутри разные ФС могут очень сильно отличаться?

это не важно.

Пока мы не лезем внутрь ядра, всё, что нам может понадобиться от файла, - его содержимое.

нет. Нам ещё куча атрибутов файла нужна. Иногда даже специфические inum (например что-бы узнать, один и тот же это файл, или два разных? Без inum мы можем определить этот факт только методом тыка(тыкать один файл, и смотреть что со вторым)). Остальные атрибуты ещё более востребованы, и позволяют нам экономить кучу времени, НЕ получая доступ к содержимому(это во первых долго, а во вторых может быть вообще запрещено для нас).

[QWERTYASDF]

Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст).

А кто сказал, что файл должен обязательно рассматриваться "в понятиях" той или иной ФС, тем более что изнутри разные ФС могут очень сильно отличаться? Пока мы не лезем внутрь ядра, всё, что нам может понадобиться от файла, - его содержимое.

В принципе, к соответствующим словам drBatty мне нечего добавить.

Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст).

ИМХО "файл" это ограниченная область информации. Т.е. содержимое файла -- это и есть файл. Но кроме содержимого у файла есть и атрибуты, например у многих файлов есть inode, а у некоторых файлов есть имена. Т.е. ИМХО неправильно разделять содержимое и атрибуты.

Имхо, биты-содержимое файла и сам файл т.е. его биты суть разные понятия. Можно взять набор содержимого-битов и пустить их куда-нибудь куда угодно, например в сеть, и оно будет существовать вне изначального файла. Также и файл может существовать вовсе без содержимого в виде тех битов, которые его и составляют.

Которое добавляется в третий файл стандартного выхода (последовательная распечатка текста файлов на экран).

да. Но содержимое добавляется отдельно, объединяется оно уже внутри файла. Т.е. команды

$

cat f1 >f; cat f2 >>f

эквивалентны

$

cat f1 f2 >f

(за исключением того, что в первом случае файл f закрывается и сразу открывается лишний раз)

Все-равно не понимаю логики объединения файлов здесь. Т.е., если принять Ваше утверждение выше, то понятно. Но все-таки не могу с ним согласиться : (

[drBatty]

Имхо, биты-содержимое файла и сам файл т.е. его биты суть разные понятия.

разница как между "пространством" и "объёмом". Пространство -- это такая общая категория, которая постулируется в физике. Это та ерунда трёхмерная, в которой мы живём. О "объём" -- кусочек пространства.

Так и "файл" отличается от "информации".

Можно взять набор содержимого-битов и пустить их куда-нибудь куда угодно, например в сеть, и оно будет существовать вне изначального файла.

ни будут существовать внутри какого-то иного файла. К примеру, если вы пишите письмо по почте, то оно какое-то время существует в виде копии на почтовом сервере, а потом приходит ко мне. А вот "в интернете" письмо в общем случае существовать и не обязано. Под словом "интернет" понимают обычно среду передачи, а не хранилище. Среда конечно тоже может "хранить" информацию (наше пространство может например "хранить" информацию в свете), но это особый случай (в силу того, что такая "хранимая" информация может существовать только строго фиксированное время, которое равно максимальной скорости передачи информации в данной среде. Ускорить её невозможно, но можно замедлить. Замедленная(замороженная) информация как раз и возвращает нас к понятию "файл").

Также и файл может существовать вовсе без содержимого в виде тех битов, которые его и составляют.

ну это тоже такой файл в моей терминологии. Например 101110001 -- это файл, в файловой системе http://unixforum.org (и это 101110001 действительно существует как часть файла СУБД сервера UFO).

"А файлы без ФС" может и существуют, но меня совершенно не волнуют. Как и инопланетяне ;)

[QWERTYASDF]

Имхо, биты-содержимое файла и сам файл т.е. его биты суть разные понятия.

разница как между "пространством" и "объёмом". Пространство -- это такая общая категория, которая постулируется в физике. Это та ерунда трёхмерная, в которой мы живём. О "объём" -- кусочек пространства.

Так и "файл" отличается от "информации".

По мне скорей "пространство"="фс", а тот или иной выделенный его "объем-участок"="файл". Это больше похоже на уровень таки пользователя, а не программиста.

Можно взять набор содержимого-битов и пустить их куда-нибудь куда угодно, например в сеть, и оно будет существовать вне изначального файла.

ни будут существовать внутри какого-то иного файла. К примеру, если вы пишите письмо по почте, то оно какое-то время существует в виде копии на почтовом сервере, а потом приходит ко мне. А вот "в интернете" письмо в общем случае существовать и не обязано. Под словом "интернет" понимают обычно среду передачи, а не хранилище. Среда конечно тоже может "хранить" информацию (наше пространство может например "хранить" информацию в свете), но это особый случай (в силу того, что такая "хранимая" информация может существовать только строго фиксированное время, которое равно максимальной скорости передачи информации в данной среде. Ускорить её невозможно, но можно замедлить. Замедленная(замороженная) информация как раз и возвращает нас к понятию "файл").

Упорно не понимаю, почему не будут существовать внутри иного файла. Допустим, имеем файл А с его содержимым. Выполняем строку

Код: Выделить всё

cat A > B ; rm A

После этой команды данные, которые изначально были в файле А, переехали жить в файл В, а файла А вообще не стало. Вывод - можно взять набор содержимого-битов из файла и пустить их в другой файл, где они будут существовать вне изначального файла. А сеть, про которую у нас речь, можно вполне в духе UNIX представить тоже каким-нибудь файлом network и сделать

Код: Выделить всё

cat A > network ; rm A

После этой команды данные будут существовать в файле network, а сколько времени - нас не волнует. И в UNIX есть множество таких реальных примеров с его сокетами, дырками etc.

Замедленная(замороженная) информация как раз и возвращает нас к понятию "файл"

Возьмите банальные "сигнал" и "носитель" в контексте передачи данных - обычно первое на Земле существует многократно меньше второго. Однако возможно и обратное - радиосигнал будет блуждать в космосе много лет, а оптический диск в герметичном корпусе разобьет метеоритом. Или сеть может быть настроена таким образом, что какой-то определенный набор пакетов будет ходить в ней несколько минут. Соответственно нет смысла в данном контексте разделять существование данных по времени.

[drBatty]

По мне скорей "пространство"="фс", а тот или иной выделенный его "объем-участок"="файл". Это больше похоже на уровень таки пользователя, а не программиста.

на самом деле, ФС это тоже файл. Пользователю можно об этом забыть, но тогда он будет ограничен в рамках этой ФС. Но IRL пользователю об этом забывать нельзя, хотя-бы потому, что он IRL соеденяет разные ФС (к примеру вставляет флешку в компьютер). В данном случае, пользователь просто обязан понимать, что _файл_ "флешка" соединяется с ФС "мой компьютер", и становится его составной частью (т.е. каталогом). При этом каталог принадлежит одновременно двум устройствам.

Код: Выделить всё

cat A > B ; rm A

После этой команды данные, которые изначально были в файле А, переехали жить в файл В, а файла А вообще не стало.

тут придётся ввести понятие "атомарность". Данная операция атомарной не является.

Упорно не понимаю, почему не будут существовать внутри иного файла.

А сеть, про которую у нас речь, можно вполне в духе UNIX представить тоже каким-нибудь файлом network и сделать

вот как раз в духе UNIX интерфейс eth0 файлом и НЕ является. По той простой причине, что ТАМ ничего не хранится. И не просто не хранится, а вообще _не_ _может_ хранится _в_ _принципе_.

Ну то есть хранилища информации, а есть среды передачи информации. В среде передачи информации сохранение лишено всякого смысла. Т.е. это не просто невозможно, а вообще НЕ ОПРЕДЕЛЕНО. Как "результат" деления на ноль.

Среду передачи информации можно использовать как хранилище тогда, и только тогда, когда у нас есть иная среда, в которой скорость выше.

После этой команды данные будут существовать в файле network, а сколько времени - нас не волнует.

не будут. network это _среда_, а не файл. Там файлы хранится не могут по определению. Файл может быть удалённый, он может быть даже виртуальный(как облако), но он должен БЫТЬ. Вы просто не неправильно понимаете понятие "среда передачи информации".

Однако возможно и обратное - радиосигнал будет блуждать в космосе много лет, а оптический диск в герметичном корпусе разобьет метеоритом.

сигнал конечно будет блуждать, но это не имеет никакого отношения к _сохранению_. Сохранение информации, это когда мы можем достать старую информацию откуда-то. Это возможно, я согласен. Проблема как раз во времени: представьте себе точки A и Б, расстояние между которыми 1 св. год. Т.е. если сейчас послать сигнал из А, то в Б он будет "через год". В кавычках потому, что это НЕ ПРАВИЛЬНО. На самом деле, сигнал в Б будет ОДНОВРЕМЕННО с А. Я понимаю, это сложно понять и представить, но это так. Всё дело в том, что для наблюдателя в Б, НЕ СУЩЕСТВУЕТ того времени, которое нужно свету что-бы долететь(год). Т.е. если через полгода уничтожить А, то в Б об этом узнают максимум через полтора года. Время для наблюдателя с Б сдвинуто, на год вперёд, считая от А. Т.о. время хранения в среде равно нулю, т.к. у реципиента просто нет никакой возможности в принципе, узнать, что было во время передачи. Он может только строить предположения, которые ничем не лучше, чем предположения о будущем в своём мире.

Вот если у нас имеются две среды передачи с разной скоростью или разной протяжённостью, то хранение возможно. Например А может попросить у Б поставить зеркало, и тогда получит устройство хранения, которое хранит любую информацию в течении двух лет. Но это лишь потому, что у А есть другой путь от А до А равный нулю. В интернетах такое сделать в принципе можно, но имеет мало практического смысла, т.к. понятие "расстояние" там является не константой, а случайной величиной. Потому мало смысла в устройстве хранения, которое может вернуть бит через секунду, может через минуту, а может и вообще потерять. Намного практичнее сделать зеркало с хранилищем, которое и выдаёт информацию по запросу.

[QWERTYASDF]

drBatty

вот как раз в духе UNIX интерфейс eth0 файлом и НЕ является. По той простой причине, что ТАМ ничего не хранится. И не просто не хранится, а вообще _не_ _может_ хранится _в_
_принципе_.

Т.е. /dev/null - это не файл, раз в нем ничего не хранится? Это как-раз НЕ в духе UNIX-а : ) В UNIX-е любой идентифицируемый (а иначе и никак) ресурс=файл=идентифицируемый ввод-вывод произвольных данных. А то, что эти данные после их ввода в определенный файл практически уничтожаются - так это устройство интерфейса пользователя такое, это у нас ресурс-уничтожитель данных (как уничтожитель бумаг) : )

network это _среда_, а не файл. Там файлы хранится не могут по определению. Файл может быть удалённый, он может быть даже виртуальный(как облако), но он должен БЫТЬ. Вы
просто не неправильно понимаете понятие "среда передачи информации".

А он и есть (ну т.е. это то название я наобум придумала, Вы можете подставить реальную аналогию на выбор) также, как есть /dev/null. Про него тоже можно сказать, что данные там как-бы хранятся, но под замком, от которого в принципе нет ключа. Мы же можем в математике, когда нужно избавиться от числа, сказать что оно возрастает в 0 раз - пользуемся унифицированной формулировкой - число умножается, но так, что его больше и нет, как мы и хотели. Возможно и не правильно понимаю "среда передачи", но какая разница - за маской файла может скрываться что угодно.

сигнал конечно будет блуждать, но это не имеет никакого отношения к _сохранению_. Сохранение информации, это когда мы можем достать старую информацию откуда-то. Это возможно, я
согласен. Проблема как раз во времени: представьте себе точки A и Б, расстояние между которыми 1 св. год. Т.е. если сейчас послать сигнал из А, то в Б он будет "через год". В
кавычках потому, что это НЕ ПРАВИЛЬНО. На самом деле, сигнал в Б будет ОДНОВРЕМЕННО с А. Я понимаю, это сложно понять и представить, но это так. Всё дело в том, что для наблюдателя

в Б, НЕ СУЩЕСТВУЕТ того времени, которое нужно свету что-бы долететь(год). Т.е. если через полгода уничтожить А, то в Б об этом узнают максимум через полтора года. Время для
наблюдателя с Б сдвинуто, на год вперёд, считая от А. Т.о. время хранения в среде равно нулю, т.к. у реципиента просто нет никакой возможности в принципе, узнать, что было во время

передачи. Он может только строить предположения, которые ничем не лучше, чем предположения о будущем в своём мире.

Вот если у нас имеются две среды передачи с разной скоростью или разной протяжённостью, то хранение возможно. Например А может попросить у Б поставить зеркало, и тогда получит
устройство хранения, которое хранит любую информацию в течении двух лет. Но это лишь потому, что у А есть другой путь от А до А равный нулю. В интернетах такое сделать в принципе
можно, но имеет мало практического смысла, т.к. понятие "расстояние" там является не константой, а случайной величиной. Потому мало смысла в устройстве хранения, которое может
вернуть бит через секунду, может через минуту, а может и вообще потерять. Намного практичнее сделать зеркало с хранилищем, которое и выдаёт информацию по запросу.

Респект, емко и понятно сформулированно. Но у нас же мир абстракций. Давайте предположим, что таки данные могут существовать после их перемещения в этот network. Какая разница, что
за физическая механика за этим будет скрываться? Главное, чтоб у нас интерфейс был. Как в математике - сущности то придуманы и доказаны, но с чем-то физическим их не соединить.
Однако до поры до времени.

К тому-же насчет

Сохранение информации, это когда мы можем достать старую информацию откуда-то

А кто "мы" и что значит "достать"? Например у нас есть текст, мы его переносим на бумагу письма, которое отдаем курьеру, чтоб он доставил адресату. После чего изначальную бумагу-носитель сжигаем. Курьер уже уехал, связи с ним нет, но мы знаем, что он его доставит. Далее, у кого (у нас или у адресата) текст будет находиться нам не важно, главное чтоб у кого-то находился. Если текст находится у курьера, везущего его оттуда сюда или наоборот - нас тоже устраивает. И мы точно знаем граничные сроки работы курьера, и они нас устраивают. Сохранен ли текст в таком случае после сжигания изначального носителя? Сохранен. Потому-как "мы" это и мы (кто письмо отправил) и адресат и даже курьер (т.к. он передаст текст кому-то из нас)

[drBatty]

вот как раз в духе UNIX интерфейс eth0 файлом и НЕ является. По той простой причине, что ТАМ ничего не хранится. И не просто не хранится, а вообще _не_ _может_ хранится _в_
_принципе_.

Т.е. /dev/null - это не файл, раз в нем ничего не хранится?

вы не понимаете разницу: 0(ноль) -- это число. Имеющее вполне реальную величину, которая равна нулю. Также и файл /dev/null имеет вполне себе реальный размер информации -- он содержит ровно ноль байт её. Есть таки разница между понятиями "ноль", "ничто", и "неопределённость". Ноль вполне себе существует, хотя его величина по странному совпадению нулевая. Это как ноль градусов по Цельсию -- вполне себе нормальная температура. А вот "ничто" не существует, т.е. его просто нет. Как не было секса в СССР (и колбасы в перестройку). Т.е. "ничто" вполне себе может и измениться, и даже в другом месте оно "что-то", но сейчас и здесь это "ничто". Неопределённость -- третье отдельное понятие, которое не имеет никакого смысла. Мы сами сделали его таким. Пример: сухая вода.

Это я всё к тому веду, что /dev/null это совсем не "ничто", и уж тем более не неопределённость. А вполне себе обычный файл(для чтения. Для записи не совсем обычный) нулевой длинны.

В UNIX-е любой идентифицируемый (а иначе и никак) ресурс=файл=идентифицируемый ввод-вывод произвольных данных.

не любой. Среда передачи под названием eth файлом как раз и не является. Также не являются файлами процессы, и это при том, что у них есть id, и они могут даже пересылать друг-другу информацию, не через файлы, а напрямую(сигналы. Сплошь и рядом процессам посылают SIGINT, дабы их завершить. Но их вообще-то много разных).

А он и есть (ну т.е. это то название я наобум придумала, Вы можете подставить реальную аналогию на выбор) также, как есть /dev/null. Про него тоже можно сказать, что данные там как-бы хранятся, но под замком, от которого в принципе нет ключа. Мы же можем в математике, когда нужно избавиться от числа, сказать что оно возрастает в 0 раз - пользуемся унифицированной формулировкой - число умножается, но так, что его больше и нет, как мы и хотели. Возможно и не правильно понимаю "среда передачи", но какая разница - за маской файла может скрываться что угодно.

в том-то и дело, что данные там НЕ хранятся. По определению.

[drBatty]

Но у нас же мир абстракций. Давайте предположим, что таки данные могут существовать после их перемещения в этот network.

нет. Не давайте. Network это и есть ПЕРЕМЕЩЕНИЕ. Одни их вариантов его. Как вы объясните "переместить в перемещение"?

Какая разница, что
за физическая механика за этим будет скрываться? Главное, чтоб у нас интерфейс был.

не всё так просто. Шутить с временем опасно, я не шучу. Проблема в том, что принцип причинности у нас в крови, для нас очевидно, что следствие будет ПОСЛЕ причины. Программисты, когда пишут программы, явно или неявно опираются на этот принцип. Потому и компьютеры на него "опираются", они просто так запрограммированы. Но если время сдвинуть, и нарушить причинность, то программы сходят с ума в буквальном смысле этого слова(в этом, кстати, сама суть "проблемы 2000").

Хорошая новость: это всё касается только тех Пространств, где Время течёт по разному.

Плохая новость: IRL у нас одно Пространство, но в компьютере мы их можем сделать сколько угодно.

Плохая новость №2: в компьютере это можно исправить, просто сделав глобальный счётчик событий. Но в интернетах это невозможно в принципе.

И мы точно знаем граничные сроки работы курьера, и они нас устраивают. Сохранен ли текст в таком случае после сжигания изначального носителя? Сохранен.

нет. Потерян. Можно восстановить конечно, но нужен ещё курьер + двойное время ожидание + 300% гарантии сохранности.

А кто "мы" и что значит "достать"?

кто угодно, что угодно. Это не важно. Камушек на развилке в лесу например, который мы положили, и который указывает тропинку, по которой мы уже гуляли, сохраняет ровно 1 бит информации(если нет другой возможности выбрать вторую тропинку, или такая возможность нам не известна). Важно, что любая информация вообще говоря субъективна, а не объективно. Потому "мы", т.е. те, кто договорился о взаимно однозначной интерпретации.

[QWERTYASDF]

вы не понимаете разницу: 0(ноль) -- это число. Имеющее вполне реальную величину, которая равна нулю. Также и файл /dev/null имеет вполне себе
реальный размер информации -- он содержит ровно ноль байт её.

Надеюсь я это правильно помню - для натуральных чисел, число 0 и есть формализованное "ничто". "Ничто", которое можно поставить между двумя
разрядами числовой записи, для ее (записи) рационализации. Также и для информации 0 байт ее - это формализованное ничто. Надо нам уничтожить
информацию-вывод какого-нибудь процесса на экран - используем ресурс /dev/null - перенаправляем ее туда.

Это я всё к тому веду, что /dev/null это совсем не "ничто", и уж тем более не неопределённость. А вполне себе обычный файл(для чтения. Для записи не совсем обычный) нулевой длинны.

Обычный файл. В том плане, что пользователю он представляется так-же, как и файл /home/*.mp3 Только вот реализуемая через него задача другая.

В UNIX-е любой идентифицируемый (а иначе и никак)
ресурс=файл=идентифицируемый ввод-вывод произвольных данных.

не любой. Среда передачи под названием eth файлом как раз и не является. Также не являются файлами процессы, и это при том, что у них есть id, и они
могут даже пересылать друг-другу
информацию, не через файлы, а напрямую(сигналы. Сплошь и рядом процессам посылают SIGINT, дабы их завершить. Но их вообще-то много разных).

Но все авторитетные учебники и прочие, не столь формальные, но не много менее авторитетные источники говорят - в Юниксе ВСЕ файл. И процессы можно
представить как файлы (и представлены). А почему нет? Процесс - это ведь ресурс - от него можно получить какой-то практический толк. Или Вы ссылаетесь на формулировку а-ля
Фигурнова "файл - физическая область на носителе данных"? Так это не в духе Юникса.

нет. Не давайте. Network это и есть ПЕРЕМЕЩЕНИЕ. Одни их вариантов его. Как вы объясните "переместить в перемещение"?

... Троллейбус - перемещение между точками А и В. Обозначаем троллейбус ярлыком network. После чего говорим - "переместить в network". Если наш гипотетический транспорт ходит только по одному маршруту между А и В, и время его движения мы не считаем, то по мне так тождественно "Переместить от А к В" и "Переместить от А в network"