Код: Выделить всё
cat A B
не происходит, а происходит объединение данных, содержащихся в этих файлах в некий третий файл (в данном случае, в файл stdout).
Есть ли в этих выкладках резон на Ваш взгляд?
Модератор: Модераторы разделов
Код: Выделить всё
cat A B
QWERTYASDF писал(а): ↑15.07.2013 22:51Поспорила тут с одним чуваком о том, так ли логически верно общепринятое определение команды 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 писал(а): ↑15.07.2013 23:02lazhu
Думаю, Вы совсем не внимательно читали написанные мною строчки. Но за внимание, наверное, спасибо.
- последовательно вывести ФАЙЛ(ы) или стандартный ввод на стандартный вывод.Concatenate FILE(s), or standard input, to standard output
Код: Выделить всё
cat A B > C
Имя команды cat представляет собой сокращение от слова cancatenate , т.е. объединения файлов. Основное назначение данной команды -
объединение нескольких файлов в один. Вывод на экран одного файла - лишь частный случай ее использования.
Код: Выделить всё
cat A B > C
QWERTYASDF писал(а): ↑15.07.2013 23:58Ок. Допускаю, что меня в очередной раз подводит мое не знание английского, и строки описания в мане переводятся именно как Вы сказали.
Резон моего вопроса в определенной запутанности вокруг cat (как, впрочем, и многого другого) для тех, кто не владеет (увы) нормально
английским и вынужден полагаться на те или иные русскоязычные источники. Ибо, во первых, все словари мне говорят примерно одно и тоже насчет
слова "concatenate" - само по себе оно переводится, как "сцеплять" (на мой взгляд синоним "объединять" звучит благозвучнее).
- утилита читает файлы последовательно, выводя их на стандартный вывод.The utility reads files sequentially, writing them to the standard output
- утилита cat прочитает файлы по порядку и выведет их содержимое на стандартный вывод в таком же порядке.The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence
Во вторых (надо
было сделать первым) такие, например, источники, как (беру навскидку) "Скотт Граннеман - Linux, карманный справочник" говорят примерно
следущее:
Имя команды cat представляет собой сокращение от слова cancatenate , т.е. объединения файлов. Основное назначение данной команды -
объединение нескольких файлов в один. Вывод на экран одного файла - лишь частный случай ее использования.
...Что, как понимаю, не верно, а я права в своем маленьком замечании: cat НЕ является программой конкатенации т.е. объединения файлов (?)
И до кучи. Все-таки,
Код: Выделить всё
cat A B > C
это разве объединение файлов? У нас ведь не создается некий гипотетический файл С с инодами и именами А и B ? Создается независимый файл С, в который помещается объединенное содержимое первых двух. Не?
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Ну, как Вам сказать... Любое объединение файлов подразумевает объединение данных, содержащихся в этих файлах. Будь то cat или sox.QWERTYASDF писал(а): ↑15.07.2013 23:58это разве объединение файлов? У нас ведь не создается некий гипотетический файл С с инодами и именами А и B ? Создается независимый файл С, в который помещается объединенное содержимое первых двух. Не?
Shell
$ tail f1; tail f2
хвост1
хвост2
# tail f1 f2
==> f1 <==
a
b
c
==> f2 <==
1
2
3
QWERTYASDF писал(а): ↑16.07.2013 12:40Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст).
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
QWERTYASDF писал(а): ↑16.07.2013 12:40Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст).
QWERTYASDF писал(а): ↑16.07.2013 12:40Которое добавляется в третий файл стандартного выхода (последовательная распечатка текста файлов на экран).
$
cat f1 >f; cat f2 >>f
$
cat f1 f2 >f
Bizdelnick писал(а): ↑16.07.2013 13:00А кто сказал, что файл должен обязательно рассматриваться "в понятиях" той или иной ФС
Bizdelnick писал(а): ↑16.07.2013 13:00тем более что изнутри разные ФС могут очень сильно отличаться?
Bizdelnick писал(а): ↑16.07.2013 13:00Пока мы не лезем внутрь ядра, всё, что нам может понадобиться от файла, - его содержимое.
Bizdelnick писал(а): ↑16.07.2013 13:00QWERTYASDF писал(а): ↑16.07.2013 12:40Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст).
А кто сказал, что файл должен обязательно рассматриваться "в понятиях" той или иной ФС, тем более что изнутри разные ФС могут очень сильно отличаться? Пока мы не лезем внутрь ядра, всё, что нам может понадобиться от файла, - его содержимое.
drBatty писал(а): ↑16.07.2013 13:35QWERTYASDF писал(а): ↑16.07.2013 12:40Так то не файлы в понятиях фс (не их имена+иноды), а содержимое (текст).
ИМХО "файл" это ограниченная область информации. Т.е. содержимое файла -- это и есть файл. Но кроме содержимого у файла есть и атрибуты, например у многих файлов есть inode, а у некоторых файлов есть имена. Т.е. ИМХО неправильно разделять содержимое и атрибуты.
drBatty писал(а): ↑16.07.2013 13:35QWERTYASDF писал(а): ↑16.07.2013 12:40Которое добавляется в третий файл стандартного выхода (последовательная распечатка текста файлов на экран).
да. Но содержимое добавляется отдельно, объединяется оно уже внутри файла. Т.е. команды
$
cat f1 >f; cat f2 >>f
эквивалентны
$
cat f1 f2 >f
(за исключением того, что в первом случае файл f закрывается и сразу открывается лишний раз)
QWERTYASDF писал(а): ↑16.07.2013 14:08Имхо, биты-содержимое файла и сам файл т.е. его биты суть разные понятия.
QWERTYASDF писал(а): ↑16.07.2013 14:08Можно взять набор содержимого-битов и пустить их куда-нибудь куда угодно, например в сеть, и оно будет существовать вне изначального файла.
QWERTYASDF писал(а): ↑16.07.2013 14:08Также и файл может существовать вовсе без содержимого в виде тех битов, которые его и составляют.
drBatty писал(а): ↑16.07.2013 15:12QWERTYASDF писал(а): ↑16.07.2013 14:08Имхо, биты-содержимое файла и сам файл т.е. его биты суть разные понятия.
разница как между "пространством" и "объёмом". Пространство -- это такая общая категория, которая постулируется в физике. Это та ерунда трёхмерная, в которой мы живём. О "объём" -- кусочек пространства.
Так и "файл" отличается от "информации".
drBatty писал(а): ↑16.07.2013 15:12QWERTYASDF писал(а): ↑16.07.2013 14:08Можно взять набор содержимого-битов и пустить их куда-нибудь куда угодно, например в сеть, и оно будет существовать вне изначального файла.
ни будут существовать внутри какого-то иного файла. К примеру, если вы пишите письмо по почте, то оно какое-то время существует в виде копии на почтовом сервере, а потом приходит ко мне. А вот "в интернете" письмо в общем случае существовать и не обязано. Под словом "интернет" понимают обычно среду передачи, а не хранилище. Среда конечно тоже может "хранить" информацию (наше пространство может например "хранить" информацию в свете), но это особый случай (в силу того, что такая "хранимая" информация может существовать только строго фиксированное время, которое равно максимальной скорости передачи информации в данной среде. Ускорить её невозможно, но можно замедлить. Замедленная(замороженная) информация как раз и возвращает нас к понятию "файл").
Код: Выделить всё
cat A > B ; rm A
Код: Выделить всё
cat A > network ; rm A
Возьмите банальные "сигнал" и "носитель" в контексте передачи данных - обычно первое на Земле существует многократно меньше второго. Однако возможно и обратное - радиосигнал будет блуждать в космосе много лет, а оптический диск в герметичном корпусе разобьет метеоритом. Или сеть может быть настроена таким образом, что какой-то определенный набор пакетов будет ходить в ней несколько минут. Соответственно нет смысла в данном контексте разделять существование данных по времени.Замедленная(замороженная) информация как раз и возвращает нас к понятию "файл"
QWERTYASDF писал(а): ↑16.07.2013 18:03По мне скорей "пространство"="фс", а тот или иной выделенный его "объем-участок"="файл". Это больше похоже на уровень таки пользователя, а не программиста.
QWERTYASDF писал(а): ↑16.07.2013 18:03Код: Выделить всё
cat A > B ; rm A
После этой команды данные, которые изначально были в файле А, переехали жить в файл В, а файла А вообще не стало.
QWERTYASDF писал(а): ↑16.07.2013 18:03Упорно не понимаю, почему не будут существовать внутри иного файла.
QWERTYASDF писал(а): ↑16.07.2013 18:03А сеть, про которую у нас речь, можно вполне в духе UNIX представить тоже каким-нибудь файлом network и сделать
QWERTYASDF писал(а): ↑16.07.2013 18:03После этой команды данные будут существовать в файле network, а сколько времени - нас не волнует.
QWERTYASDF писал(а): ↑16.07.2013 18:03Однако возможно и обратное - радиосигнал будет блуждать в космосе много лет, а оптический диск в герметичном корпусе разобьет метеоритом.
вот как раз в духе UNIX интерфейс eth0 файлом и НЕ является. По той простой причине, что ТАМ ничего не хранится. И не просто не хранится, а вообще _не_ _может_ хранится _в_
_принципе_.
network это _среда_, а не файл. Там файлы хранится не могут по определению. Файл может быть удалённый, он может быть даже виртуальный(как облако), но он должен БЫТЬ. Вы
просто не неправильно понимаете понятие "среда передачи информации".
сигнал конечно будет блуждать, но это не имеет никакого отношения к _сохранению_. Сохранение информации, это когда мы можем достать старую информацию откуда-то. Это возможно, я
согласен. Проблема как раз во времени: представьте себе точки A и Б, расстояние между которыми 1 св. год. Т.е. если сейчас послать сигнал из А, то в Б он будет "через год". В
кавычках потому, что это НЕ ПРАВИЛЬНО. На самом деле, сигнал в Б будет ОДНОВРЕМЕННО с А. Я понимаю, это сложно понять и представить, но это так. Всё дело в том, что для наблюдателя
в Б, НЕ СУЩЕСТВУЕТ того времени, которое нужно свету что-бы долететь(год). Т.е. если через полгода уничтожить А, то в Б об этом узнают максимум через полтора года. Время для
наблюдателя с Б сдвинуто, на год вперёд, считая от А. Т.о. время хранения в среде равно нулю, т.к. у реципиента просто нет никакой возможности в принципе, узнать, что было во время
передачи. Он может только строить предположения, которые ничем не лучше, чем предположения о будущем в своём мире.
Вот если у нас имеются две среды передачи с разной скоростью или разной протяжённостью, то хранение возможно. Например А может попросить у Б поставить зеркало, и тогда получит
устройство хранения, которое хранит любую информацию в течении двух лет. Но это лишь потому, что у А есть другой путь от А до А равный нулю. В интернетах такое сделать в принципе
можно, но имеет мало практического смысла, т.к. понятие "расстояние" там является не константой, а случайной величиной. Потому мало смысла в устройстве хранения, которое может
вернуть бит через секунду, может через минуту, а может и вообще потерять. Намного практичнее сделать зеркало с хранилищем, которое и выдаёт информацию по запросу.
А кто "мы" и что значит "достать"? Например у нас есть текст, мы его переносим на бумагу письма, которое отдаем курьеру, чтоб он доставил адресату. После чего изначальную бумагу-носитель сжигаем. Курьер уже уехал, связи с ним нет, но мы знаем, что он его доставит. Далее, у кого (у нас или у адресата) текст будет находиться нам не важно, главное чтоб у кого-то находился. Если текст находится у курьера, везущего его оттуда сюда или наоборот - нас тоже устраивает. И мы точно знаем граничные сроки работы курьера, и они нас устраивают. Сохранен ли текст в таком случае после сжигания изначального носителя? Сохранен. Потому-как "мы" это и мы (кто письмо отправил) и адресат и даже курьер (т.к. он передаст текст кому-то из нас)Сохранение информации, это когда мы можем достать старую информацию откуда-то
QWERTYASDF писал(а): ↑17.07.2013 16:02вот как раз в духе UNIX интерфейс eth0 файлом и НЕ является. По той простой причине, что ТАМ ничего не хранится. И не просто не хранится, а вообще _не_ _может_ хранится _в_
_принципе_.
Т.е. /dev/null - это не файл, раз в нем ничего не хранится?
QWERTYASDF писал(а): ↑17.07.2013 16:02В UNIX-е любой идентифицируемый (а иначе и никак) ресурс=файл=идентифицируемый ввод-вывод произвольных данных.
QWERTYASDF писал(а): ↑17.07.2013 16:02А он и есть (ну т.е. это то название я наобум придумала, Вы можете подставить реальную аналогию на выбор) также, как есть /dev/null. Про него тоже можно сказать, что данные там как-бы хранятся, но под замком, от которого в принципе нет ключа. Мы же можем в математике, когда нужно избавиться от числа, сказать что оно возрастает в 0 раз - пользуемся унифицированной формулировкой - число умножается, но так, что его больше и нет, как мы и хотели. Возможно и не правильно понимаю "среда передачи", но какая разница - за маской файла может скрываться что угодно.
QWERTYASDF писал(а): ↑17.07.2013 16:02Но у нас же мир абстракций. Давайте предположим, что таки данные могут существовать после их перемещения в этот network.
QWERTYASDF писал(а): ↑17.07.2013 16:02Какая разница, что
за физическая механика за этим будет скрываться? Главное, чтоб у нас интерфейс был.
QWERTYASDF писал(а): ↑17.07.2013 16:02И мы точно знаем граничные сроки работы курьера, и они нас устраивают. Сохранен ли текст в таком случае после сжигания изначального носителя? Сохранен.
вы не понимаете разницу: 0(ноль) -- это число. Имеющее вполне реальную величину, которая равна нулю. Также и файл /dev/null имеет вполне себе
реальный размер информации -- он содержит ровно ноль байт её.
Это я всё к тому веду, что /dev/null это совсем не "ничто", и уж тем более не неопределённость. А вполне себе обычный файл(для чтения. Для записи не совсем обычный) нулевой длинны.
QWERTYASDF писал(а): ↑17.07.2013 16:02В UNIX-е любой идентифицируемый (а иначе и никак)
ресурс=файл=идентифицируемый ввод-вывод произвольных данных.
не любой. Среда передачи под названием eth файлом как раз и не является. Также не являются файлами процессы, и это при том, что у них есть id, и они
могут даже пересылать друг-другу
информацию, не через файлы, а напрямую(сигналы. Сплошь и рядом процессам посылают SIGINT, дабы их завершить. Но их вообще-то много разных).
нет. Не давайте. Network это и есть ПЕРЕМЕЩЕНИЕ. Одни их вариантов его. Как вы объясните "переместить в перемещение"?