Файлы и дескрипторы — бесплатный тест онлайн

Вопрос 1 из 25

Как завершится этот код по правилам Perl 5.40?

open my $fh, '<', $path or die "$path: $!";
my $line=<$fh>;

Трёхаргументный open отделяет режим от пути и не интерпретирует специальные символы пути как режим или канал. Трёхаргументный open отделяет режим от пути и не интерпретирует специальные байты пути как режим или канал. При выполнении первым проявится другое последствие: Двухаргументный open может трактовать начало или конец строки как режим и опасен с внешним путём. Для результата здесь достаточно учесть лишь такое условие: open с '-|' или '|-' запускает процесс без shell при списковой форме команды; строковая форма может привлечь оболочку. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Явный режим безопаснее и понятнее для чтения файла.

Вопрос 2 из 25

Как точнее всего описать действие фрагмента с `$fh`, `$path` и `$line`?

open my $fh, '<:encoding(UTF-8)', $path or die $!;
while (my $line = <$fh>) {
    process_line($line);
}

Слой encoding декодирует байты в символы и сообщает о проблемах кодировки согласно настройкам слоя. Для результата здесь достаточно учесть лишь такое условие: binmode меняет слои уже открытого дескриптора, но лучше установить требуемый слой сразу в open. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Режим raw уместен, когда нужен точный поток байтов, например для хеша или бинарного формата. Этот код приведёт к иному эффекту: Ручное декодирование без проверки может смешать уже декодированные строки и сырые байты. Слой encoding декодирует символы в символы и сообщает о проблемах кодировки согласно настройкам слоя.

Вопрос 3 из 25

Что в этом примере с `$line`, `$fh` и `process` происходит на самом деле?

while (my $line = <$fh>) { process($line) }

Текущее поведение совпадает с результатом предлагаемой правки: Явная проверка defined корректно отличает EOF даже от строки '0'. Результат фрагмента «Потоковая обработка» зависит от случайного порядка выполнения и не определяется самим кодом. При выполнении первым проявится другое последствие: Весь файл материализуется в памяти, что опасно при неизвестном размере. Построчное чтение использует ограниченную память; readline в условии while неявно проверяется на defined, поэтому строка '0' тоже будет обработана. Для результата здесь достаточно учесть лишь такое условие: local $/ = undef читает весь остаток файла одним скаляром; это осознанный выбор только при контролируемом размере.

Вопрос 4 из 25

Что в этом примере с `$fh`, `$tmp` и `$data` происходит на самом деле?

open my $fh,'>',$tmp or die $!;
print {$fh} $data;
close $fh or die "close: $!";

Ошибка записи может проявиться только при close из-за буферизации, поэтому результат закрытия проверяется. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Проверяются обе границы, включая отложенную ошибку закрытия. Ошибка записи не может проявиться только при close из-за буферизации, поэтому результат закрытия проверяется. Единственное существенное правило этого запуска — следующая оговорка: Лексический дескриптор обычно закроется при уничтожении, но автоматическое закрытие не даёт удобного места проверить ошибку. Этот код приведёт к иному эффекту: Код не проверяет ни запись, ни закрытие и может удалить временный файл до фиксации ошибки.

Вопрос 5 из 25

Не запуская фрагмент «Ошибки интеграции», выберите точное описание его работы.

open my $out, '>', $target or die $!;
print {$out} render();

При выполнении первым проявится другое последствие: Блокировка после усечения файла не защищает предыдущую версию от уничтожения конкурентным процессом. Прямая запись в целевой файл оставляет частичный результат при сбое процесса. В показанном коде «Ошибки интеграции» проявляется другой эффект: блокировка после усечения файла не защищает предыдущую версию от уничтожения конкурентным процессом. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Запись во временный файл в том же файловом разделе с последующим rename уменьшает окно частичного состояния. Итог этого фрагмента полностью задаёт следующая оговорка: rename обычно атомарен в пределах одной файловой системы, но не заменяет fsync, если нужна стойкость после аварии питания.

Вопрос 6 из 25

Обычный случай проходит. Что в блоке «Трёхаргументный open» всё же сделано неверно?

open my $fh, $path or die $!;

Двухаргументный open может трактовать начало или конец строки как режим и опасен с внешним путём. Источником дефекта становится само изменение: Явный режим безопаснее и понятнее для чтения файла. Причина сбоя совпадает с обычным результатом примера: Трёхаргументный open отделяет режим от пути и не интерпретирует специальные символы пути как режим или канал. Двухаргументный open не может трактовать начало или конец строки как режим и опасен с внешним путём. Показанный сбой объясняется не кодом, а таким пределом механизма: open с '-|' или '|-' запускает процесс без shell при списковой форме команды; строковая форма может привлечь оболочку.

Вопрос 7 из 25

Почему вариант с `$fh`, `$path` и `$_` нельзя считать безопасным для рабочих данных?

open my $fh, '<', $path;
utf8::decode($_) while <$fh>;

Дефект объясняется базовым поведением фрагмента: Слой encoding декодирует байты в символы и сообщает о проблемах кодировки согласно настройкам слоя. Ручное декодирование без проверки не может смешать уже декодированные строки и сырые байты. Ручное декодирование без проверки может смешать уже декодированные строки и сырые байты. Существенная проблема здесь связана с иной границей: binmode меняет слои уже открытого дескриптора, но лучше установить требуемый слой сразу в open. Проблема возникает в исправленном варианте: Режим raw уместен, когда нужен точный поток байтов, например для хеша или бинарного формата.

Вопрос 8 из 25

Почему участок с `@lines`, `$fh` и `$_` ненадёжен на пограничном входе?

my @lines = <$fh>;
for (@lines) { process($_) }

Проблема возникает в исправленном варианте: Явная проверка defined корректно отличает EOF даже от строки '0'. Причина сбоя совпадает с обычным результатом примера: Построчное чтение использует ограниченную память; readline в условии while неявно проверяется на defined, поэтому строка '0' тоже будет обработана. Дефект следует искать в другой оговорке: local $/ = undef читает весь остаток файла одним скаляром; это осознанный выбор только при контролируемом размере. Показанный код уже соблюдает правило «Потоковая обработка предпочтительна, когда результат можно вычислять по частям и размер входа не ограничен», поэтому отдельного дефекта нет. Весь файл материализуется в памяти, что опасно при неизвестном размере.

Вопрос 9 из 25

Какой диагноз точнее всего относится к участку с `$fh`, `$data` и `$tmp`?

print {$fh} $data;
unlink $tmp;

Основная проблема здесь — сам результат штатного случая: Ошибка записи может проявиться только при close из-за буферизации, поэтому результат закрытия проверяется. Источником дефекта становится само изменение: Проверяются обе границы, включая отложенную ошибку закрытия. Код не проверяет ни запись, ни закрытие и может удалить временный файл до фиксации ошибки. Код проверяет ни запись, ни закрытие и может удалить временный файл до фиксации ошибки. Код не проверяет ни запись, ни закрытие и не может удалить временный файл до фиксации ошибки.

Вопрос 10 из 25

Обычный случай проходит. Что в блоке «Ошибки интеграции» всё же сделано неверно?

open my $out,'>',$target;
flock $out,2;

Источником дефекта становится само изменение: Запись во временный файл в том же файловом разделе с последующим rename уменьшает окно частичного состояния. Дефект объясняется базовым поведением фрагмента: Прямая запись в целевой файл оставляет частичный результат при сбое процесса. Блокировка после усечения файла не защищает предыдущую версию от уничтожения конкурентным процессом. Показанный код уже соблюдает правило «Интеграционный код должен учитывать конкурентную запись, атомарную замену, права и поведение файловой системы», поэтому отдельного дефекта нет. Дефект следует искать в другой оговорке: rename обычно атомарен в пределах одной файловой системы, но не заменяет fsync, если нужна стойкость после аварии питания.

Вопрос 11 из 25

Что изменилось в работе фрагмента «Трёхаргументный open»?

open my $fh, '<', $path or die "open $path: $!";

Польза изменения состоит только в снятии такой оговорки: open с '-|' или '|-' запускает процесс без shell при списковой форме команды; строковая форма может привлечь оболочку. Явный режим безопаснее и понятнее для чтения файла. Правка лишь воспроизводит исходное поведение: Трёхаргументный open отделяет режим от пути и не интерпретирует специальные символы пути как режим или канал. После изменения сохраняется прежний дефект: Двухаргументный open может трактовать начало или конец строки как режим и опасен с внешним путём. Изменение формы записи само по себе обеспечивает правило «Для обычных файлов используют трёхаргументный open и проверяют ошибку открытия до чтения».

Вопрос 12 из 25

Какое свойство новой версии с `$fh`, `$path` и `$bytes` важно закрепить тестом?

open my $fh, '<:raw', $path or die $!;
my $bytes=do { local $/; <$fh> };

Польза изменения состоит только в снятии такой оговорки: binmode меняет слои уже открытого дескриптора, но лучше установить требуемый слой сразу в open. После изменения сохраняется прежний дефект: Ручное декодирование без проверки может смешать уже декодированные строки и сырые байты. Правка лишь воспроизводит исходное поведение: Слой encoding декодирует байты в символы и сообщает о проблемах кодировки согласно настройкам слоя. Режим raw уместен, когда нужен точный поток символов, например для хеша или бинарного формата. Режим raw уместен, когда нужен точный поток байтов, например для хеша или бинарного формата.

Вопрос 13 из 25

Что именно стало надёжнее после изменения в блоке «Потоковая обработка»?

while (defined(my $line=<$fh>)) { process($line) }

Явная проверка exists корректно отличает EOF даже от строки '0'. Явная проверка defined корректно отличает EOF даже от строки '0'. Явная проверка undef корректно отличает EOF даже от строки '0'. Явная проверка defined корректно отличает EOF даже от строки '1'. Правка лишь воспроизводит исходное поведение: Построчное чтение использует ограниченную память; readline в условии while неявно проверяется на defined, поэтому строка '0' тоже будет обработана.

Вопрос 14 из 25

Почему этот вариант пригоднее для рабочего кода?

print {$fh} $data or die "write: $!";
close $fh or die "close: $!";

Проверяются обе границы, включая отложенную ошибку закрытия. Правка лишь воспроизводит исходное поведение: Ошибка записи может проявиться только при close из-за буферизации, поэтому результат закрытия проверяется. После изменения сохраняется прежний дефект: Код не проверяет ни запись, ни закрытие и может удалить временный файл до фиксации ошибки. Гарантию исправления даёт исчезновение ограничения: Лексический дескриптор обычно закроется при уничтожении, но автоматическое закрытие не даёт удобного места проверить ошибку. Проверяются обе границы, включая отложенную успех закрытия.

Вопрос 15 из 25

Какую гарантию добавляет правка «Ошибки интеграции» с `$out`, `$tmp` и `$target`?

open my $out,'>',$tmp or die $!;
print {$out} render() or die $!;
close $out or die $!;
rename $tmp,$target or die $!;

Правка лишь воспроизводит исходное поведение: Прямая запись в целевой файл оставляет частичный результат при сбое процесса. Запись во временный файл в том же файловом разделе с последующим rename уменьшает окно частичного состояния. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: rename обычно атомарен в пределах одной файловой системы, но не заменяет fsync, если нужна стойкость после аварии питания. После изменения сохраняется прежний дефект: Блокировка после усечения файла не защищает предыдущую версию от уничтожения конкурентным процессом. Изменение формы записи само по себе обеспечивает правило «Интеграционный код должен учитывать конкурентную запись, атомарную замену, права и поведение файловой системы».

Вопрос 16 из 25

Какое положение темы «Трёхаргументный open» помогает выбрать надёжную реализацию?

Главный ориентир — не допустить следующую ситуацию: Двухаргументный open может трактовать начало или конец строки как режим и опасен с внешним путём. Для обычных файлов используют трёхаргументный open и проверяют ошибку открытия до чтения. Общее правило темы «Трёхаргументный open» сводится к частному результату: Трёхаргументный open отделяет режим от пути и не интерпретирует специальные символы пути как режим или канал. Для обычных файлов используют трёхаргументный open и проверяют успех открытия до чтения. Для обычных файлов используют трёхаргументный open и проверяют ошибку открытия после чтения.

Вопрос 17 из 25

Какую закономерность проверяют задания темы «Кодировки»?

Правило «Кодировку задают на границе ввода-вывода; внутри программы текст держат как декодированные символы» гарантирует, что ограничение «binmode меняет слои уже открытого дескриптора, но лучше установить требуемый слой сразу в open» больше не проявится. Общее правило темы «Кодировки» сводится к частному результату: Слой encoding декодирует байты в символы и сообщает о проблемах кодировки согласно настройкам слоя. Весь контракт блока обеспечивает такая правка: Режим raw уместен, когда нужен точный поток байтов, например для хеша или бинарного формата. Кодировку задают на границе ввода-вывода; внутри программы текст держат как декодированные символы. Основной принцип блока описывает только такой риск: Ручное декодирование без проверки может смешать уже декодированные строки и сырые байты.

Вопрос 18 из 25

Что является главным ориентиром при работе с «Потоковая обработка»?

Потоковая обработка предпочтительна, когда результат можно вычислять по частям и размер входа не ограничен. Для всех случаев темы подходит одно изменение: Явная проверка defined корректно отличает EOF даже от строки '0'. Главный ориентир — не допустить следующую ситуацию: Весь файл материализуется в памяти, что опасно при неизвестном размере. Правило «Потоковая обработка предпочтительна, когда результат можно вычислять по частям и размер входа не ограничен» гарантирует, что ограничение «local $/ = undef читает весь остаток файла одним скаляром; это осознанный выбор только при контролируемом размере» больше не проявится. Общее правило темы «Потоковая обработка» сводится к частному результату: Построчное чтение использует ограниченную память; readline в условии while неявно проверяется на defined, поэтому строка '0' тоже будет обработана.

Вопрос 19 из 25

Что точнее всего описывает контракт механизма «Закрытие ресурса»?

Один приём полностью закрывает тему: Проверяются обе границы, включая отложенную ошибку закрытия. Правило «Явное закрытие особенно важно для записываемых файлов, каналов и протоколов, где close завершает операцию» гарантирует, что ограничение «Лексический дескриптор обычно закроется при уничтожении, но автоматическое закрытие не даёт удобного места проверить ошибку» больше не проявится. Явное закрытие особенно важно для записываемых файлов, каналов и протоколов, где close завершает операцию. Для ревью достаточно исключить частный дефект: Код не проверяет ни запись, ни закрытие и может удалить временный файл до фиксации ошибки. Общее правило темы «Закрытие ресурса» сводится к частному результату: Ошибка записи может проявиться только при close из-за буферизации, поэтому результат закрытия проверяется.

Вопрос 20 из 25

Какой вывод объединяет результат, дефект и исправление в теме «Ошибки интеграции»?

Интеграционный код не должен учитывать конкурентную запись, атомарную замену, права и поведение файловой системы. Всю тему можно представить как защиту от одного отказа: Блокировка после усечения файла не защищает предыдущую версию от уничтожения конкурентным процессом. Общее правило темы «Ошибки интеграции» сводится к частному результату: Прямая запись в целевой файл оставляет частичный результат при сбое процесса. Для всех случаев темы подходит одно изменение: Запись во временный файл в том же файловом разделе с последующим rename уменьшает окно частичного состояния. Интеграционный код должен учитывать конкурентную запись, атомарную замену, права и поведение файловой системы.

Вопрос 21 из 25

Как точнее всего обозначить границу безопасного использования приёма «Трёхаргументный open»?

Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Open с '-|' или '|-' запускает процесс без shell при списковой форме команды; строковая форма не может привлечь оболочку. Базовое правило «Для обычных файлов используют трёхаргументный open и проверяют ошибку открытия до чтения» автоматически снимает указанную границу. Open с '-|' или '|-' запускает процесс без shell при списковой форме команды; строковая форма может привлечь оболочку. Ограничение «open с '-|' или '|-' запускает процесс без shell при списковой форме команды; строковая форма может привлечь оболочку» исчезает, если обычный пример один раз завершился успешно.

Вопрос 22 из 25

Что остаётся верным о теме «Кодировки», если учитывать контекст, отказ и побочный эффект?

Базовое правило «Кодировку задают на границе ввода-вывода; внутри программы текст держат как декодированные символы» автоматически снимает указанную границу. Ограничение «binmode меняет слои уже открытого дескриптора, но лучше установить требуемый слой сразу в open» исчезает, если обычный пример один раз завершился успешно. Binmode меняет слои уже открытого дескриптора, но лучше установить требуемый слой сразу в open. Binmode меняет слои уже открытого дескриптора, но лучше установить требуемый слой только при следующем вызове в open. В актуальной версии Perl эта граница больше не действует.

Вопрос 23 из 25

Как точнее всего обозначить границу безопасного использования приёма «Потоковая обработка»?

Базовое правило «Потоковая обработка предпочтительна, когда результат можно вычислять по частям и размер входа не ограничен» автоматически снимает указанную границу. Ограничение «local $/ = undef читает весь остаток файла одним скаляром; это осознанный выбор только при контролируемом размере» исчезает, если обычный пример один раз завершился успешно. Local $/ = undef читает весь остаток файла одним скаляром; это осознанный выбор только при контролируемом размере. Local $/ = defined читает весь остаток файла одним скаляром; это осознанный выбор только при контролируемом размере. В актуальной версии Perl эта граница больше не действует.

Вопрос 24 из 25

Что остаётся верным о теме «Закрытие ресурса», если учитывать контекст, отказ и побочный эффект?

Пакетный дескриптор обычно закроется при уничтожении, но автоматическое закрытие не даёт удобного места проверить ошибку. Базовое правило «Явное закрытие особенно важно для записываемых файлов, каналов и протоколов, где close завершает операцию» автоматически снимает указанную границу. Ограничение «Лексический дескриптор обычно закроется при уничтожении, но автоматическое закрытие не даёт удобного места проверить ошибку» исчезает, если обычный пример один раз завершился успешно. Лексический дескриптор обычно закроется при уничтожении, но автоматическое закрытие не даёт удобного места проверить успех. Лексический дескриптор обычно закроется при уничтожении, но автоматическое закрытие не даёт удобного места проверить ошибку.

Вопрос 25 из 25

Какую оговорку нужно добавить к основному правилу темы «Ошибки интеграции»?

Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Базовое правило «Интеграционный код должен учитывать конкурентную запись, атомарную замену, права и поведение файловой системы» автоматически снимает указанную границу. Ограничение «rename обычно атомарен в пределах одной файловой системы, но не заменяет fsync, если нужна стойкость после аварии питания» исчезает, если обычный пример один раз завершился успешно. Rename обычно атомарен в пределах одной файловой системы, но не заменяет fsync, если нужна стойкость после аварии питания. При strict и warnings отдельная проверка этой оговорки не требуется.