Можно ли использовать двоеточие в имени файла
Обновлено: 04.11.2024
Если вы создаете несколько наборов данных в Stata, вы можете присвоить им имена автоматически. В приведенном ниже коде показано, как создать имя файла на основе даты и отметки времени. Такой процесс именования файлов 1) не позволит вам дать одно и то же имя файла двум разным наборам данных (при условии, что они не созданы в одну и ту же минуту) и 2) позволит вам увидеть, когда файлы были впервые созданы. В приведенном ниже коде представлен пример.
Сначала мы создаем локальные макросы для текущей даты и времени.
В первой строке кода ниже мы объединяем две строковые переменные. Чтобы объединить две строковые переменные, мы перечисляем первую строку в кавычках (например, «`c_date’»), за которой следует знак плюс (+), а вторую строку заключаем в кавычки. Нам нужно подчеркивание между двумя строковыми переменными, поэтому мы включаем его в серию строк, которые нужно объединить. Затем мы используем display для просмотра строки, которая у нас есть. Обратите внимание, что строка содержит пробелы и двоеточия, которые могут создавать проблемы в именах файлов.
Ниже мы используем функцию subinstr(…) для «очистки» нашей строки. subinstr(…) принимает четыре аргумента, первый — это строка, которую мы хотим изменить (например, «`c_time_date'»), за которой следует строка, которую мы хотим заменить (например, «:»), и то, на что мы хотим ее заменить ( например "_"). Последний аргумент — это количество замен, которые мы хотим сделать, так как мы хотим заменить каждый экземпляр двоеточия, мы используем точку (.), но мы также могли бы использовать число 2, так как мы знаем, что в нашем коде есть два двоеточия. нить. Вторая строка синтаксиса ниже заменяет пробелы (например, " ") символами подчеркивания ( _ ). Третья строка отображает результат, чтобы мы могли видеть, как теперь выглядит наша строка. На этот раз наша строка имеет лучшую форму для имени файла.
В первой строке ниже мы загружаем набор данных, чтобы нам было что сохранить. Затем мы сохраняем существующий набор данных, используя макропеременную «time_string» в имени сохраненного набора данных.
Возможно, нам может понадобиться префикс имени файла с другим значением. В приведенном ниже синтаксисе мы повторяем команду сохранения, на этот раз добавляя к имени файла префикс «myfile_», так что имя нашего файла будет myfile_, за которым следуют дата и время.
Я предполагаю, что файл создается какой-то системой Unix или Linux, но я не уверен, как пользователи сохраняют его с недопустимым именем файла. Я закодировал часть, которая должна переименовывать документ при загрузке. Моя проблема в том, что я не могу проверить это, потому что я не могу получить файл в Windows, в имени которого есть двоеточие.
Есть несколько символов, которые просто не допускаются в именах файлов Windows, двоеточие — один из них. Извините.
Это можно сделать с помощью собственного API или драйвера устройства. Но вы не сможете загрузить файл из приложения Windows или сделать с ним что-либо еще.
Я часто использую двоеточие во всю ширину ： в именах файлов. Это символ Unicode, очень похожий на двоеточие, поэтому я использую его там, где Windows не разрешает использовать обычное двоеточие. Он визуально окружен пробелами, которые вы не можете удалить. Я наткнулся на него давным-давно, а теперь просто копирую и вставляю, когда мне это нужно.
7 ответов 7
Я нашел символ, очень похожий на двоеточие, "꞉". Это символ Юникода, который называется буквой-модификатором двоеточия. У него нет пробела, как у полноширинного двоеточия, и он почти такой же, как обычное двоеточие, но символ работает. Вы можете либо скопировать и вставить его сверху, либо использовать кодовую точку U+A789
Отлично. Я уже некоторое время отслеживаю эти замены юникода для имен файлов, так что спасибо! Ты обалденный. Я знаю, что вы не спрашивали, но если вам когда-нибудь понадобится вопросительный знак, вы можете использовать вместо него «⁇». (U+2047). Для косой черты вы можете использовать косую черту деления: '∕' (U+2215). Возможно, кому-то они пригодятся.
Двоеточие — это недопустимый символ для имени файла Windows. Вы не сможете разрешить ':' в имени файла, но вы можете обойти это.
Я думаю, что решил проблему, переименовав загруженные файлы на лету, но мне нужно каким-то образом загрузить файл на компьютер с Windows с двоеточием в имени файла. Наши клиенты каким-то образом делают это, поэтому это должно быть возможно.
@David: что заставляет вас думать, что ваши клиенты делают это? Вы уверены, что загрузка идет с компьютеров Windows?
Будьте осторожны - вы можете создать что-то с именем FOO:BAR, но тогда у вас будет файл с именем FOO, содержащий поток данных с именем BAR (а также безымянный поток данных). В списке каталогов вы увидите просто FOO.
Я получаю сообщение об ошибке, связанное с попыткой загрузки имени файла. Я подтвердил, что по крайней мере некоторые из попыток загрузки были с компьютеров Windows.
Я знаю, что это не предназначено, но мне как-то нужно убедиться, что мое решение устранило проблему. Как мне создать файл с именем foo:bar?
Другие замены, которые я нашел для зарезервированных символов,
Например, в Python вы бы сделали:
man 8 ntfs-3g заявляет: Запрещенными символами являются девять символов " * / : < >? \ | . Я насчитал 10 в вашем ответе, для чего он нужен: ⑊ ?
@malat в этом случае это не один символ, это будет замена двух символов \\ одним похожим символом ⑊ , потому что замена его двумя заменяющими односимвольными обратными косыми чертами будет выглядеть так ＼＼
Судя по имени файла, которое вы указали, возможно, что символ, который у вас есть в ваших именах файлов, не является буквальным двоеточием : , который является зарезервированным символом в именах файлов Windows, а двоеточием полной ширины ： Вместо этого. Это символ Unicode, очень похожий на двоеточие, визуально окруженный пробелами, которые вы не можете удалить. Вы можете обращаться с ним точно так же, как с любым символом Unicode, кодовая точка U+FF1A .
это не относится к вопросу ОП; хотя совет очень хороший, вы должны либо поместить его в комментарий к вопросу или задать/ответить на него в стиле вопросов и ответов, как в Jeopardy, сначала спросив «Как использовать двоеточие в именах файлов Windows?» вопрос, выбрав ответ в стиле вопросов и ответов и предоставив эту информацию там.
@vaxquis: наоборот, я думаю, что это действительно было причиной проблемы ОП; он думал, что в именах файлов, с которыми он пытался работать, были двоеточия, но они, вероятно, были двоеточиями во всю ширину.
Вы можете использовать CJK (китайский/японский/корейский)
что является довольно общим.
Затем вы можете создать двоеточие в своем дистрибутиве Linux.
КАК НАЗВАТЬ ФАЙЛ ИЛИ ПАПКУ, ИСПОЛЬЗУЯ СИМВОЛ, ПОХОЖИЙ НА ДВОРОТЫ
В приведенном ниже примере размер шрифта равен 12, за исключением символа, для которого заданы значения Subscript, Bold и размер шрифта 16. Код символа для символа, похожего на двоеточие, — 02F8.
Причина установки нижнего индекса заключается в том, чтобы расположить символ ниже относительно его вертикального положения. Параметры полужирного шрифта и более крупного шрифта применяются, чтобы символ был более различим на странице и не влиял на его использование в имени файла или папки.
Недавно я клонировал репозиторий git с конфигурацией puppet, который содержит файлы, в именах которых есть символ двоеточия (:).
Насколько мне известно, некоторые символы (например, / * ? : < >) нельзя было использовать в именах файлов. Когда стал разрешен символ ':'?
Это подводит меня к другому вопросу. какое неприятное возможное имя файла вы можете придумать? Может у вас есть файл с именем "sudo rm -rf/" или что-то в этом роде?
В имени файла нельзя использовать только символы косой черты ('/') и NULL ('\0').
Создание имен файлов, содержащих обратную косую черту ('/'), точку с запятой (';') и вертикальную черту ('|'), может привести к тому, что пользователь будет выполнять произвольные команды.
Это не обратная косая черта.
Это обратная косая черта ('\').
Двоеточия запрещены в мире Windows, поскольку они противоречат соглашению об именовании букв дисков (C:). В Linux такого запрета нет. При этом, если вы попытаетесь скопировать указанный файл в систему Windows, результаты будут «интересными».
Это ответ, который вы ищете, ОП. Остальные технически правильны, но не решают вашу конкретную дилемму.
Вы действительно можете скопировать их, если подключите диск Windows под Linux и скопируете их.
Windows сообщит вам, что не может прочитать файл, что имя неверно или путь неверный.
Windows запрещает использование всех символов, специально интерпретируемых оболочкой, и всех имен, используемых для имен устройств DOS. В Linux разрешено все, кроме «/» (косая черта) и NUL или файлов с именами «.» или "..".
Интересно, что NTFS позволяет создавать файлы с именами, запрещенными Windows. Вы можете сделать это с помощью Cygwin или если вы используете диск в Linux. Файловая система это позволяет, а Windows API — нет. У вас будет странное поведение с программами Windows, но Cygwin прекрасно с этим справится.
Попытка создать имя файла с двоеточием на диске, смонтированном с помощью drvfs, не работает, тогда как я могу создать файл на lxfs:
Подключенный накопитель является внешним USB-накопителем, отформатированным в файловой системе NTFS
Я что-то упустил?
Текст был успешно обновлен, но возникли следующие ошибки:
прокомментировал doehrm 17 декабря 2016 г.
Вариант использования: "chromium-os" ;-)
Я создал специальную версию для своего старого ноутбука. Официальным хостом сборки является Ubuntu 16.04.1. Вся сборка выполняется в среде chroot, поэтому в ОС необходимо установить лишь несколько инструментов (python, git, curl и некоторые другие), остальные загружаются и компилируются в chroot.
При загрузке описаний репозитория я обнаружил несколько файлов, которые невозможно синхронизировать из-за двоеточия:
Оригинальные источники действительно содержат это двоеточие:
Моя цель состояла в том, чтобы иметь «несколько нативную» возможность компилировать новую версию на моем ноутбуке, а не иметь Hyper-V, виртуальные сетевые карты и коммутаторы, которые возятся с моей нетривиальной настройкой сети/VPN (если вы когда-либо устанавливали полдюжины VPN (SSTP, OpenVPN и PPTP вперемешку с ipv4/ipv6) и ставишь Hyper-V и удивляешься, почему больше ничего не работает, сам поймешь ;-) )
Но я понимаю, что разрешить его будет проблематично, несмотря на то, что я не хочу использовать его как имя каталога, а "просто имя файла".
прокомментировал aasering 17 декабря 2016 г.
Tangent -- : был разделителем пути Mac до OS X. Графические приложения Mac по-прежнему позволяют именам файлов содержать / , а не : . По сути, : странно везде.
В любом случае, это интересный вопрос, следует ли разрешить DrvFs (в целях совместимости) создавать имена файлов, которые не разрешены для обычных приложений Windows, и если да, то какой должна быть семантика таких файлов.
прокомментировал aseering 17 декабря 2016 г. •
@doehrm -- нельзя ли встроить $HOME в WSL? Как вы упомянули, он поддерживает: . Кроме того, у него должна быть более высокая производительность.
прокомментировал doehrm 17 декабря 2016 г.
Я до сих пор работаю в ОС с такими именами файлов, как NODE::DKA0:[FOO.BAR.BAR2]foobar.dat;5, где двоеточие является разделителем, нет возможности создать имя файла с двоеточием, и я думаю, это также и то, где глубоко в ядре Windows (NT 4.0) это тоже [было|запрещено].
И да, я попробую это в следующий раз, как только смогу избавиться от некоторых старых инсайдерских сборок, все еще хранящихся на диске, и освободить место.
прокомментировал doehrm 17 декабря 2016 г.
Интересно, что я мог клонировать репозиторий с помощью GIT в Windows:
и кажется, что какая-то семантика уже существует:
Простой каталог показывает первую строку (размер 0, короткое имя файла до двоеточия), каталог /r показывает полное имя с "$DATA" в конце.
Прокомментировано fpqc 17 декабря 2016 г. •
@therealkenc Настоящая причина не имеет ничего общего с DOS iirc. Символ ":" зарезервирован для альтернативных потоков данных в NTFS и на самом деле, возможно, связан с древней подсистемой OS/2.
прокомментировал doehrm 17 декабря 2016 г.
прокомментировал doehrm 17 декабря 2016 г.
Теперь я смог загрузить весь код в $HOME. Когда я пытаюсь войти в chroot, система либо зависает (и мне приходится жестко перезагружаться), либо BSOD :-( с APC_INDEX_MISMATCH.
Я включил полный дамп и воспроизведу проблему снова (если это поможет).
Прокомментировано fpqc 17 декабря 2016 г. •
Кроме того, да, это верно, альтернативные потоки данных — это идея, вдохновленная VMS. Расширенные атрибуты — наследие OS/2.
прокомментировал doehrm 17 декабря 2016 г.
Выполнено, спасибо @fpqc за то, что указал мне направление, и извините за то, что испортил эту проблему с несвязанными BSOD.
Поскольку похоже, что NTFS умеет обрабатывать эти файлы, значит ли это, что и DrvFS должна делать то же самое?
Прокомментировано fpqc 17 декабря 2016 г. •
@doehrm Путь "a:b" относится к альтернативному потоку данных файла "a" в NTFS. Это недопустимый путь в Win32. В Powershell есть командлет (streams), который позволяет вам увидеть, какие ADS прикреплены к файлу. Тип потока по умолчанию называется просто " $DATA ". Знакомо?
iirc, GeoHot несколько лет назад продемонстрировал атаку на Windows с помощью ADS.
прокомментировал doehrm 17 декабря 2016 г.
или он внутренне "сопоставляется" с символом Unicode (U+F000 - U+F0FF).
Прокомментировано fpqc 17 декабря 2016 г. •
Результат вашего каталога /r указывает на то, что были сохранены альтернативные потоки данных.
В нем говорится: "Я создал пустой файл Open+Sans , а затем создал альтернативный поток $DATA для этого файла с именем 300.woff, который содержит фактическое желаемое содержимое файла". Git для Windows не должен этого делать. Это полностью нарушенное поведение.
Я только что проверил это на себе. Вот что он делает. Вероятно, поэтому он сходит с ума от BSOD. Никто (по крайней мере, не относящийся к Microsoft), насколько мне известно, не тестировал функциональность DrvFS с добавлением в смесь потоков с альтернативными именами $DATA.
Это работает в LXFS, поскольку драйверы WSL перехватывают все файловые операции ввода-вывода в среде и при необходимости экранируют символы, когда они оказываются на диске.
прокомментировал benhillis 20 декабря 2016 г. •
@doehrm - Я получил ваш дамп и посмотрел. Причиной синего экрана была проблема блокировки в терминале ioctl. Исправление только что попало в ветку rs_prerelease, поэтому оно должно быть включено в следующую сборку программы предварительной оценки Windows.
Спасибо, что сообщили о проблеме и отправили нам дамп памяти!
bitcrazed прокомментировал 7 апреля 2017 г.
Спасибо за сообщение.Закрытие, поскольку эта проблема должна была быть исправлена в инсайдерской сборке в начале 2017 года, и в последнее время по этой проблеме не было никаких действий.
Комментарий SRGOM от 5 мая 2017 г.
@bitcrazed это "исправление" и в обновлении создателей тоже? Если да, то разрешено ли иметь имя файла с двоеточием в разделе NTFS и быть доступным из WSL?
комментарий therealkenc от 5 мая 2017 г.
Нет, просто неправильно закрыли.
Комментарий SRGOM от 6 мая 2017 г.
Спасибо, @therealkenc Может быть, разработчик не будет возражать, если я открою новый, чтобы внести ясность..
комментарий therealkenc 6 мая 2017 г. •
Комментарий SRGOM от 7 мая 2017 г. •
комментарий therealkenc 7 мая 2017 г. •
Рич, вероятно, просто спутал BSOD, связанный с терминалом ioctl, который был раздавлен выше, с заголовком проблемы. Переключатель реестра для включения и выключения поддержки двоеточия имени файла в DrvFS не имел бы смысла, и даже если бы он имел место, это не был бы секретный переключатель. А также. если бы это был секретный переключатель. хорошо. знающие поклялись хранить тайну. не так ли.
therealkenc прокомментировал 14 февраля 2018 г.
Повторное открытие до тех пор, пока зарезервированные символы win32 ( : ? и т. д.) не будут исправлены, чтобы это могло получить тег fixedinsiders. Которые, как я понимаю, могут появиться в ближайшее время.
Benhillis прокомментировал 14 февраля 2018 г.
@therealkenc - Спасибо, не знал, что этот магазин закрыт.
Комментарий Брайана-Перкинса от 15 февраля 2018 г.
Проблема с зарезервированными символами должна быть решена в Insiders Build 17101.
Feaber прокомментировал 25 февраля 2018 г.
У меня Windows 10 Pro N (1803, сборка: 17101.1000)
Похоже, теперь можно создать файл с двоеточием в имени на / (rootfs) и на /mnt/
Тем не менее у меня есть некоторые проблемы с двоеточием в /mnt/
Я запускаю простой скрипт, который подключается к моему удаленному хосту с Debian и выполняет резервное копирование. Скрипт основан на rsync. На сервере у меня есть несколько сервисов, один из них — серверы Dovecot/Postfix.
Файлы, представляющие электронную почту, имеют сложные имена, например:
.1519283136.M726136P495.articode.pl,S=23068,W=23405:2,Sc.KXvFzt
Когда я запускаю свой скрипт из rootfs, все работает нормально. Но когда местом назначения для сохранения является какая-то папка внутри /mnt/, тогда rsync пытается выполнить какие-то странные действия по переименованию несуществующих файлов.
Пример:
rsync: rename "/mnt/e/articode.pl/current/mail/articode.pl/biuro/.Trash/cur/.1519283136.M726136P495.articode.pl,S=23068, W=23405:2,Sc.KXvFzt" -> "articode.pl/biuro/.Trash/cur/1519283136.M726136P495.articode.pl,S=23068,W=23405:2,Sc": Нет такого файла или каталога (2)
Исходные параметры rsync:
rsync -az -e ssh --delete --rsync-path="sudo rsync" "$@$:/var/mail/" "$/current/mail/"< /p>
Lotus1 обратился за советом к Монахам Perl по следующему вопросу:
Я использую Perl 5.24.1 x86 в системе Windows 10 (Edit) Server 2012 R2. Мой вопрос: почему нет ошибок, когда я открываю имя файла, содержащее символ двоеточия ( ':' )? Что происходит, так это то, что открытые работы и печать в дескриптор файла, похоже, работают, но созданный файл имеет усеченное имя, и в этот файл фактически не помещается вывод. Имя файла усекается до двоеточия.
Причина, по которой я спрашиваю, заключается в том, что до этого я доверял открытию, чтобы сообщить мне, была ли проблема с созданием выходного файла. Я пытался проверить свою логику в более крупной программе и поместил ':' в имя файла, чтобы вызвать ошибку открытия, но она не появилась. Программа молча завершила работу с искаженным именем файла журнала.
Тесткейс номер 8 в этой программе показывает проблему. Все остальные тесты либо работают, либо выдают ошибку открытия файла.
Вот что выводится на дисплей:
Вы попросили Windows создать файл и дали ему имя. Windows сказала: «Хорошо, нет проблем!», и вы получили успешный возврат из открытия, но за кулисами Windows исказила имя файла. Вот почему вы не получаете сообщение об ошибке, и, вероятно, нельзя разумно ожидать, что Perl поймает такого рода вещи, поскольку он работает на более чем сотне различных платформ и не гарантирует, что имя файла на входе = имя файла на выходе.
Именование Win32 немного запутано. Эта статья руководства по именованию MSDN иллюстрирует правила.
Я не уверен, почему вы получаете случайные символы в вашем выходном файле журнала при создании имени файла, но решение, вероятно, одно из: а) убедитесь, что ваша функция генератора имен файлов не использует эти символы или б) отфильтровать недопустимые символы перед вызовом open (или, возможно, исключить недопустимые символы).
Если вам нужна межплатформенная поддержка, это немного сложнее, но вы также просто должны быть очень разборчивы и разрешить, например, alnum, underscore и тире. Я не знаю модуля, который переносимо обрабатывает имена файлов, иначе я бы рекомендовал именно его.На практике обычно помогает простое регулярное выражение: $filename =~ s/[^\w-]//g;, но справку по компонентам тома и пути см. в File::Spec, если нужно. Обратите внимание на кодировку.
rjt, спасибо за ответ.
Посмотрите на вывод тестовых символов 4 и 5. Это были '/' и '\'. Для этих двух выдана ошибка: Нет такого файла или каталога: система не может найти указанный путь. Он пытался создать файл с именем «---.log» в несуществующей папке. Если двоеточие является допустимым символом пути в Windows, я ожидаю, что произойдет то же самое.
Я не уверен, почему вы получаете случайные символы в вашем выходном файле журнала, когда вы создаете имя файла,[. ],
Я не понимаю, что вы имеете в виду под случайными символами в выходных файлах. Оператор печати записывает файлы, которые были созданы успешно, за исключением тестового символа 8, двоеточия. В этом случае файл пустой. Кажется, это допустимый дескриптор файла, но печать не записывала в файл, и печать, похоже, прошла успешно, поскольку она вернула истинное значение.
Именно это восходит к тому, что я говорю: каждая операционная система имеет свои собственные правила для допустимых путей и свою собственную уникальную семантику того, что происходит, когда вы выходите за пределы этих правил. Perl, по большей части, уважает эту семантику, предоставляя программисту решать, как лучше с ней обращаться. Если вы просите открыть файл, Perl передает этот запрос ОС, а возвращаемое значение является функцией того, что возвращает сама ОС. Ошибки для других ваших случаев исходят от Windows, а не от Perl.
Я полностью согласен с тем, что такое поведение Win32 является сложным и местами странным, но именно Win32, а не Perl, дает вам такое поведение.
Я не понимаю, что вы имеете в виду под случайными символами в выходных файлах. Оператор печати записывает файлы, которые были созданы успешно, за исключением тестового символа 8, двоеточия. В этом случае файл пустой. Кажется, это допустимый дескриптор файла, но печать не записывала в файл, и печать, похоже, прошла успешно, так как она вернула истинное значение.
См. обсуждение альтернативных потоков данных в статье MSDN, на которую я дал ссылку. И добавьте это в список сюрпризов в поддержку проверки ваших имен файлов! Если вы прочитаете файл с помощью того же скрипта, вы получите его содержимое, даже если foo кажется существующим, но пустым (и введите foo< /tt> ничего не выводит):
Это «работает», потому что мы открываем альтернативный поток данных «bar.txt» файла «foo». Если вы удалите "foo", то "foo:bar.txt" также станет недоступным для чтения.
И это хорошо подчеркивает общую проблему: Perl не знает и не заботится о том, что вы открываете, а только о том, успешно ли это сделано. Perl доверяет вам знать, что вы просите ОС сделать. Точно так же, если системный вызов Windows подтвердит, что было записано 12 байт, Perl поверит Windows на слово. При желании вы можете проверить записанные байты, что не всегда возможно (например, при записи в сокеты). Знание семантики вашей целевой платформы (платформ) является обязанностью, когда вы имеете дело с кодом системного уровня.
Наконец, насколько я понимаю, для вас это эксперимент, и вы обнаружили интересное поведение Win32. Я надеюсь, что эти идеи помогут ответить на ваш вопрос.
-
Re^4: Почему нет ошибок при открытии имени файла, содержащего двоеточия, в Win10
от Lotus1 (Vicar) 11 октября 2019 г. в 20:32 UTC
-
Windows использует двоеточие не только для отделения имени тома от остального пути, но и для обозначения альтернативных потоков данных (расширение расширенных атрибутов), которые вы таким образом случайно создали. Они предоставляют инструмент для борьбы с ними
-
Re^2: Почему нет ошибок при открытии имени файла, содержащего двоеточия, в Win10
от Lotus1 (Vicar) 11 октября 2019 г. в 20:10 UTC
soonix, спасибо! Ваше объяснение и ссылки помогли мне наконец понять. Страница Microsoft предоставила простую демонстрацию в командной строке:
Вы ожидаете, что open определит и отклонит все недопустимые имена.
Что я на самом деле сказал в своем OP:
<цитата>[. ] до этого я доверял открытию, чтобы сообщить мне, была ли проблема с созданием выходного файла.
В этом случае с двоеточием в имени файла файл был создан успешно, и выходные данные были правильно записаны в альтернативный поток данных, как мне продемонстрировали другие монахи. Бьюсь об заклад, я не единственный, кто никогда не слышал об этой новой функции Windows. Меня это удивило и заинтересовало. Моему текущему сценарию на самом деле не нужно полностью проверять имена файлов, поскольку имена не являются пользовательскими. Однако у меня есть коллеги, которые иногда вносят неуклюжие изменения, поэтому я стараюсь делать вещи надежными.
Сталкивались ли вы со случаями, когда функция open() неправильно определяла и отклоняла недопустимые имена?
PerlMonks любезно предоставлен Тимом Врумом.
PerlMonks каким-то образом запутался с The Perl Foundation.
Мощные коробки и пропускная способность, щедро обеспечиваемые парными сетями
Построены на языке программирования Perl.
Читайте также: