В чем отличие EOL от EOF?

EOL - end of line

EOF - end of file

Объясните пожалуйста по человечески, есть некий стандарт что ли?

Древнее юниксовое соглашение, ВСЕ строки должны заканчиваться на \n.

есть некий стандарт что ли?

да
https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-n...

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

Казалось бы а при чём тут другие файлы как css, js, scss? Этот постулат как я понял адресован только для сишной разработке не?

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

при чём тут другие файлы как css, js .. ?

почитай там вокруг да около:
есть стандарт:
https://en.wikipedia.org/wiki/Single_UNIX_Specification
в нём написано, что есть базовые определения
там есть определение «что такое строка»
Каждая строка в Unix должна заканчиваться символом EOL.

Прочие файлы тут при этом. Что-нибудь ещё?

Нет всё. Теперь стало уже более понятно. Спасибо за пояснения.

А EOF на никсах нету в принципе, потому что тут нет отдельного понятия текстовых файлов, как в DOS — все файлы бинарные. Забавно, что при этом EOF таки фигурирует в POSIX'овых системных вызовах в виртуальном виде.

Иксперды в треде.

А EOF на никсах нету в принципе

Ага-ага.

Шо ага? Покажи мне, чтоб EOF-символ в файле прерывал где-то его чтение.

EOF
Материал из Википедии — свободной энциклопедии
Перейти к навигацииПерейти к поиску
EOF (аббревиатура англ. end of file — конец файла) в компьютерной терминологии является индикатором операционной системы, означающим, что данные в источнике закончились. Источниками данных обычно являются файлы и потоки.

В стандартной библиотеке Си функции ввода-вывода, в частности доступа к файлам, могут возвращать значение, равное символьной константе (точнее макроопределению) EOF для индикации, что достигнут конец файла. Реальное значение EOF является отрицательным числом, зависящим от системы (в основном −1), что гарантирует несовпадение с кодом символа.

Макрос определён в stdio.h.

Для указания терминалу в UNIX и Linux «EOF» следует воспользоваться комбинацией клавиш Ctrl+D. В Windows — Ctrl+Z.

Нужно ли ставить новую строку в конце HTML, CSS, JS файлах?

по желанию. в униксах так принято, потому как, если не добавить перенос в конце получится следующее:

$ cat hello.txt
hello$

EOF-символ

Расскажи мне, что такое EOF-символ, чем он отличается от EOF и почему его нет в ascii.

нет в ascii

Здрасьтеприехали, 0x1a же.

Здрасьтеприехали, 0x1a же.

Схерали? Это substitute. Мнение билли шерифа не колышет.

Лол, а зачем? Ты хочешь, чтобы у тебя чтение файла прерывалось, если внутри будет бинарная каша или какой-нибудь юникод?

0x1a

0x4, но, понятное дело, не всегда.

Лол, а зачем?

Википедия говорит, что CP/M, который предок dos, не умел размеры файлов. Резервировался кратный кусок памяти, остаток заполнялся 0x1a.

Вот откуда у него вылез 0x1a, теперь понятно :)

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

Мнение билли шерифа не колышет.

Мнение прыщефашистов тоже.

Ну да, зачем тогда в пердоновском open, например, до сих пор ключи 'r' и 'rb' отдельно?

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

Мнение прыщефашистов тоже.

Схерали? Колышет, я же тебя спросил. Больше не неси такой чуши даже в ascii не заглянув.

Ну да, зачем тогда в пердоновском open, например, до сих пор ключи 'r' и 'rb' отдельно?

Дурак что-ли? Чтоб в венде автоматом \r\n вместо \n вставлять.

даже в ascii не заглянув

Какой версии? И ты так говоришь, будто есть едино пrавославная версия и интерпретация ASCII. В телетексте вон не ASCII, что ли? Там управляющие символы вообще под свистелки всякие забиты.

А это уже сайд-эффект :P

И ты так говоришь, будто есть едино пrавославная версия и интерпретация ASCII.

Да.

А это уже сайд-эффект :P

Сайд-эффект, это то, что ты себе в голове выдумал и до сих пор ни с кем этим не поделился.

А текстовый модус предназначен, чтобы автоматом читать-писать текстовые файлы по конвенции платформы, с нужной кодировкой и EOL. И подставлять 0x1a для костыльных платформ, ага.

Читай маны, балаболка.

Да

Нет. Нарисуй мне правильный 0x7f, например.

костыльных платформ

Давай рассказывай, чем конвенция ставить 0x0a в конце файлов, чтобы не ломался cat, менее костыльноплатформная, чем 0x1a ради текстовых файлов в DOS.

Давай рассказывай, чем конвенция ставить 0x0a в конце файлов, чтобы не ломался cat, менее костыльноплатформная, чем 0x1a ради текстовых файлов в DOS.

В том-то и дело, что 0xa - это соглашение, которое работает на уровне отдельного приложения, и которое выполнять необязательно, и это не повлияет на работоспособность. А 0x1a - костыль на уровне фс, и он должен выполняться всегда.

Нет. Нарисуй мне правильный 0x7f, например.

Ты долбоёб? 0x7f — непечатаемый символ, его нельзя нарисовать.

Давай рассказывай, чем конвенция ставить 0x0a в конце файлов, чтобы не ломался cat, менее костыльноплатформная, чем 0x1a ради текстовых файлов в DOS.

У тебя понос в голове.

cat'у на 0x0a вообще пофиг, он выведет тебе содержимое файла и всё.

Конвенции ставить 0x0a в конце файла нет, есть конвенция ставить 0x0a в конце строки. Потому что 0x0a — это, сцуко, символ перевода строки. В конце текстового файла, ВНЕЗАПНО, тоже строка, поэтому в конце неё ставится 0x0a.

Это менее костыльноплатформно, чем 0x1a в конце файла, потому что 0x0a — это, ещё раз сцуко, символ перевода строки, а 0x1a — не символ окончания файла. Не существует символа окончания файла, 0x1a — это переиначенный в говнокоде майкрософта substitute.

Дак неча бинарные файлы текстовыми помечать

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

и это не повлияет на работоспособность.

Повлияет, говнофайл создаст неразбериху в терминале.

и он должен выполняться всегда

Ни фига, достаточно открыть файл в бинарном режиме.

Ну-ну. Держи: ++. Как понять, это .txt или .bf? Помечать можно и нужно, для этого аж метаданные в ФС придумали, но они не взлетели, к сожалению, и теряются при переносе файлов чуть менее чем гарантированно, хоть и поддерживаются в теории много где.

0x7f — непечатаемый символ, его нельзя нарисовать

А если нарисую?

он выведет тебе содержимое файла и всё

И вывалит промт хз где.

в конце строки

А если строк нет? Просто текст. echo -n hello > dick — где тут строка? одно слово только.

0x0a — это, ещё раз сцуко, символ перевода строки

Начнём с того, что это символ перевода строки на одно знакоместо вниз. А не возврата каретки вдобавок. Какого хрена на никсах присобачили к нему сайд-эффект возврата каретки, а для перевода на знакоместо вниз выдумали отдельную escape-последовательность — мне решительно непонятно.

Повлияет, говнофайл создаст неразбериху в терминале.

Это все фигня, важная только для человеков. Машине терминал не нужен.

Как понять, это .txt или .bf?

Ты так каждый формат помечать планируешь?

Ни фига, достаточно открыть файл в бинарном режиме.

Это если драйвер фс тебе его сможет отдать полностью. И вообще, метки не нужны, т.к.

Как понять, это .txt или .bf?

Ты так каждый формат помечать планируешь?

А если нарисую?

Нарисуй, поржём.

И вывалит промт хз где.

cat о промпте ничего не знает.

А если строк нет? Просто текст. echo -n hello > dick — где тут строка? одно слово только.

Просто текста без строк не бывает.

Начнём с того, что это символ перевода строки на одно знакоместо вниз. А не возврата каретки вдобавок.

С чего ты взял? Опять из майкрософтовского говнокода вывел?

Какого хрена на никсах присобачили к нему сайд-эффект возврата каретки, а для перевода на знакоместо вниз выдумали отдельную escape-последовательность — мне решительно непонятно.

Потому-что раздельный \r\n — костыль для древних принтеров, у которых гловка не успевала сдвинуться в начало строки.

Это все фигня, важная только для человеков. Машине терминал не нужен.

Машине вообще посрать, по ней электрические импульсы бегают тупо.

Ты так каждый формат помечать планируешь?

Нет, ты. Выдумале тут всесильную эвристику на пустом месте. Эвристика и есть самый настоящий костыль.

если драйвер фс тебе его сможет отдать полностью

Дак драйверу-то по барабану, он и на DOS отдаёт, пока есть что отдавать.

Нарисуй, поржём.

␡

cat о промпте ничего не знает

В том и проблема. А шелл не знает о cat. Без взаимодействия получается фигня.

Просто текста без строк не бывает.

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

из майкрософтовского говнокода

А если говнокод юниксовый, то он священен и непрекословен? Один только бардак в опциях dd/tar чего стоит.

у которых гловка не успевала сдвинуться в начало строки

А должна? Вдруг я не хочу двигать головку, хочу

л
 е
  с
   е
    н
     к
      о
       й

Эвристика и есть самый настоящий костыль.

Ты еще про машинное обучение так скажи.

Дак драйверу-то по барабану, он и на DOS отдаёт, пока есть что отдавать.

Гы, так там в софте были настолько эпичные костыли? Не, серьезно, каждая прога должна была уметь обрабатывать 0x1a? Лол, хорошо что эти времена прошли :D

␡

Это юникодовый 2421, который нифига не 7f и даже не ascii.

В том и проблема. А шелл не знает о cat. Без взаимодействия получается фигня.

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

А если говнокод юниксовый, то он священен и непрекословен? Один только бардак в опциях dd/tar чего стоит.

Нет. Это был намёк, что все твои знания по теме ограничены вендой.

А должна?

Да. Если она не успеет доехать, то следующий знак напечатается где-то посреди листа.

Вдруг я не хочу двигать головку, хочу

Ну не двигай, кто тебе не даёт-то.

Ты еще про машинное обучение так скажи.

И скажу. Оно ещё хуже, чёрный ящик.

каждая прога должна была уметь обрабатывать 0x1a

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

Это юникодовый 2421, который нифига не 7f и даже не ascii

А ты хошь, чтоб я тебе в HTML настоящий управляющий символ вкопипастиле? :3

Промпт всегда появляется в том месте, где программа завершилась

Так в этом-то и проблема: чтоб промпт всегда красиво появлялся на новой строке, должен не шелл правильно работать и не cat, а должны все файлы быть правильные и заканчиваться на \n. Тебе не кажется, что это идиотизм? Мало того, в приличном софте этот \n в конце отображается явно как лишняя пустая строка, что вообще ни к селу, ни к городу.

Это был намёк, что все твои знания по теме ограничены вендой

А твои никсами.

то следующий знак напечатается где-то посреди листа

Я тебе говорю, что так и задумано может быть.

Ну не двигай, кто тебе не даёт-то.

Так для этого специальная костыльная escape-последовательность нужна. При том, что для этого специально придуман управляющий символ, но в никсах он реализован через жопу и делает два действия сразу, потому юзать его для этого нельзя.

И скажу. Оно ещё хуже, чёрный ящик.

Ну а что поделать, человеки слишком глупы и не могут по-другому. Так что оно все равно нужно. СР! УВЧ!

Чтобы промпт всегда был на новой строке, надо вставлять в него перевод строки.

И тогда при выводе сделанных по никсовых конвенциям файлов перед промптом всегда будет пустая строка. Нужна ли никсофанатикам такая красная таблетка?

Интересно, никогда не сталкивался с таким при гите. Но сборщики vue яростно ругаются, если в конце файла нет '\n'.

EOF - конец файла EOL - конец строки