Re: Вопрос про винды
нельзя. А оно тебе надо?
Мне - не надо. Раньше было надо, в NT4 
А вот у кого-нибудь есть теории, зачем нельзя? Ведь это же для совместимости с DOS только, так, казалось бы, пусть DOS-программы и не могли бы работать с такими файлами, а нормальным можно было б и разрешить...
А вот у кого-нибудь есть теории, зачем нельзя? Ведь это же для совместимости с DOS только, так, казалось бы, пусть DOS-программы и не могли бы работать с такими файлами, а нормальным можно было б и разрешить...
ДОС тут ни причем. В досе, конечно, тоже были зарезервированные имена, но их было меньше.
А сделано это, как я понимаю, чтоб было легче работать с этими всякими устройствами... По большей части из консоли, конечно.
А сделано это, как я понимаю, чтоб было легче работать с этими всякими устройствами... По большей части из консоли, конечно.
> В досе, конечно, тоже были зарезервированные имена, но их было меньше.
А какие потом добавили?
> А сделано это, как я понимаю, чтоб было легче работать с этими всякими устройствами...
Т.е. использование этих имён поощряется при создании новых приложений, пусть даже и консольных? Разве нет специальных API для работы с соотв. устройствами?
А какие потом добавили?
> А сделано это, как я понимаю, чтоб было легче работать с этими всякими устройствами...
Т.е. использование этих имён поощряется при создании новых приложений, пусть даже и консольных? Разве нет специальных API для работы с соотв. устройствами?
> А какие потом добавили?
полный список влом искать
> Т.е. использование этих имён поощряется при создании новых приложений, пусть даже и консольных?
> Разве нет специальных API для работы с соотв. устройствами?
дело не в приложениях, а в управлении ими из консоли.
полный список влом искать
> Т.е. использование этих имён поощряется при создании новых приложений, пусть даже и консольных?
> Разве нет специальных API для работы с соотв. устройствами?
дело не в приложениях, а в управлении ими из консоли.
> полный список влом искать
Ну хоть одно? Я думаю, нет таких.
> а в управлении ими из консоли
Поясни плиз.
Ну хоть одно? Я думаю, нет таких.
> а в управлении ими из консоли
Поясни плиз.
> Ну хоть одно? Я думаю, нет таких.
похоже ты прав.
> Поясни плиз.
я имею в виду перенаправление ввода и вывода
похоже ты прав.
> Поясни плиз.
я имею в виду перенаправление ввода и вывода
> я имею в виду перенаправление ввода и вывода
Трудно представить ситуацию когда бы это было действительно удобно.
Для PRN есть специальная программа.
CON и так по умолчанию.
COMx мало полезны без возможности настроить параметры (или она есть?)
Кроме того, перенаправление ввода/вывода устанавливается командной оболочкой (cmd.exe) и эти возможности могли бы быть реализованы там, так как вроде бы перенаправления в/в в стиле DOS по-другому и не получить.
Трудно представить ситуацию когда бы это было действительно удобно.
Для PRN есть специальная программа.
CON и так по умолчанию.
COMx мало полезны без возможности настроить параметры (или она есть?)
Кроме того, перенаправление ввода/вывода устанавливается командной оболочкой (cmd.exe) и эти возможности могли бы быть реализованы там, так как вроде бы перенаправления в/в в стиле DOS по-другому и не получить.
Читаем MSDN в окрестности CreateFile, File Name Conventions и т.п...
The following reserved words cannot be used as the name of a file: CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also, reserved words followed by an extension-for example, NUL.tx7-are invalid file names.
не помню уже, какие из них в DOS имелись...
The following reserved words cannot be used as the name of a file: CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also, reserved words followed by an extension-for example, NUL.tx7-are invalid file names.
не помню уже, какие из них в DOS имелись...
> какие из них в DOS имелись...
все
все
меня терзают смутные сомнения, что CLOCK$ в досе не было...
> Трудно представить ситуацию когда бы это было действительно удобно.
ну не скажи... я NUL не променяю ни на что
> CON и так по умолчанию.
Это на вывод... а если мне надо "не по умолчанию"? случаи были... А на ввод так тут ничего кроме CON не сделаешь кроме спец проги...
> COMx мало полезны без возможности настроить параметры (или она есть?)
не понял, что ты имеешь в виду... Но на COMx можно отправлять комманды момеду.
> Для PRN есть специальная программа.
что за программа такая, которая умеет посылать на печать стандартный вывод консольных приложений и скриптов?
> Кроме того, перенаправление ввода/вывода устанавливается командной оболочкой (cmd.exe) и эти
> возможности могли бы быть реализованы там,
О целесообразности такого решения можно долго спорить... Но я могу тебе предложить пару примеров для неконсольных прог, когда это может понадобиться.
Fred - фанат консоли
ну не скажи... я NUL не променяю ни на что
> CON и так по умолчанию.
Это на вывод... а если мне надо "не по умолчанию"? случаи были... А на ввод так тут ничего кроме CON не сделаешь кроме спец проги...
> COMx мало полезны без возможности настроить параметры (или она есть?)
не понял, что ты имеешь в виду... Но на COMx можно отправлять комманды момеду.
> Для PRN есть специальная программа.
что за программа такая, которая умеет посылать на печать стандартный вывод консольных приложений и скриптов?
> Кроме того, перенаправление ввода/вывода устанавливается командной оболочкой (cmd.exe) и эти
> возможности могли бы быть реализованы там,
О целесообразности такого решения можно долго спорить... Но я могу тебе предложить пару примеров для неконсольных прог, когда это может понадобиться.
Fred - фанат консоли
> NUL не променяю ни на что
Принято
> что за программа такая, которая умеет посылать на печать стандартный вывод ...
| print не работает?
> не понял, что ты имеешь в виду... Но на COMx можно отправлять комманды момеду.
параметры: скорость передачи, контроль чётности etc.
Команды момеду и другим подобным девайсам удобнее отправлять с помощью специальных программ. Даже в UN*X.
> Но я могу тебе предложить пару примеров для неконсольных прог, когда это может понадобиться.
Т.е. с запуском не используя cmd.exe и символы ">", "<" в командах?
Тогда я не понимаю, о чем ты говоришь, поясни.
Принято
> что за программа такая, которая умеет посылать на печать стандартный вывод ...
| print не работает?
> не понял, что ты имеешь в виду... Но на COMx можно отправлять комманды момеду.
параметры: скорость передачи, контроль чётности etc.
Команды момеду и другим подобным девайсам удобнее отправлять с помощью специальных программ. Даже в UN*X.
> Но я могу тебе предложить пару примеров для неконсольных прог, когда это может понадобиться.
Т.е. с запуском не используя cmd.exe и символы ">", "<" в командах?
Тогда я не понимаю, о чем ты говоришь, поясни.
Ну вот... может хватит уже...
Тебя же почему-то не бесит, что в *никсе нельзя для своих целей создать файл /dev/null - потому что он там уже есть... Вот и считай, что NUL в Виндах = /dev/null в *никс...
>параметры: скорость передачи, контроль чётности etc.
>Команды момеду и другим подобным девайсам удобнее отправлять с помощью специальных программ. Даже в UN*X.
та же фигня... почему-то тебя не раздражает наличие /dev/ttyS* или чего-то такого... в которые и гадят эти программы... и здесь все точно так же...
ну и так далее... непонятно только, зачем все эти гоны...
Тебя же почему-то не бесит, что в *никсе нельзя для своих целей создать файл /dev/null - потому что он там уже есть... Вот и считай, что NUL в Виндах = /dev/null в *никс...
>параметры: скорость передачи, контроль чётности etc.
>Команды момеду и другим подобным девайсам удобнее отправлять с помощью специальных программ. Даже в UN*X.
та же фигня... почему-то тебя не раздражает наличие /dev/ttyS* или чего-то такого... в которые и гадят эти программы... и здесь все точно так же...
ну и так далее... непонятно только, зачем все эти гоны...
В никсе они все окуратненько лежат в '/dev', а, например, '/tmp/null' создать, небось, никто не мешает.
Да... убийственный аргумент... а кто вам мешает создать my_NUL или NUL_2 или i_dont_need_fuckin_nul или еще чего-нибудь... Просто интересно даже, что это за ситуация такая, в которой уважаемому Анонимусу обязательно был нужен файл с таким именем...
Во-первых, непонятно, почему нельзя создавать файлы вида 'NUL.*', а во-вотрых, тебе-бы наверное стало обидно, если-бы тебе сказали, что ты можешь называть своего котёнка как угодно, кроме "Мурзик", "Рыжик" и "Васька". ( И ещё "Васька.кот" 
)
( И ещё "Васька.кот" )Да... я буду от этого жестоко страдать... Кстати, тебя почему-то не мучит сознание того, что в именах файлов нельзя использовать \ , /, *, ? и еще много других символов, нельзя создать файл с именем " " (пробел) и т.п...
Во-первых, успокойся, я не собираюсь оспаривать тот факт, что Windows - современная операционная система, используемая настоящими профессионалами, вобравшая в себя ...., предоставляющая ....(можешь продолжить сам).
Во-вторых, с моей точки зрения было бы правильно разрешать в качестве имени файла любую последовательность байт (ну хорошо, от ограничения на длину избавиться непросто ). То, что в юниксах никак не получить в имени файла символы '/' и '\0', мне не нравится.
Все остальные (ещё более искусственные) ограничения только сильнее усложняют описание пространства допустимых имён, и, как следствие, затрудняют использование файловой системы прикладными программами. То есть, на первый взгляд разработчику кажется удобным использовать значимые имена файлов для хранения полезной информации, а сложность устройства пространства имён затрудняет это.
Пример (из реальной жизни, как ты просил). Разработчикам Java показалось удобным, если исходные тексты и скомпилированные классы будут храниться в дереве каталогов, где названия каталогов совпадают с названиями пакетов, а имена файлов строятся из имён классов. При этом были учтены очевидные грабли: запрещённые символы, чувствительность к регистру букв.
Кроме того, Java позиционируется как кроссплатформенная технология, а значит, Windows может не являться основной средой разработки. Сможет ли разработчик, не использующий Windows, догадаться не использовать nul или aux в качестве компонента в названии класса? Мой опыт показал, что совсем не обязательно.
Могу привести ещё несколько примеров, как недостаточно полное понимание разработчиками устройства пространства имён приводит к появлению ошибок (в том числе брешей в безопасности) в программах.
Во-вторых, с моей точки зрения было бы правильно разрешать в качестве имени файла любую последовательность байт (ну хорошо, от ограничения на длину избавиться непросто
). То, что в юниксах никак не получить в имени файла символы '/' и '\0', мне не нравится.Все остальные (ещё более искусственные) ограничения только сильнее усложняют описание пространства допустимых имён, и, как следствие, затрудняют использование файловой системы прикладными программами. То есть, на первый взгляд разработчику кажется удобным использовать значимые имена файлов для хранения полезной информации, а сложность устройства пространства имён затрудняет это.
Пример (из реальной жизни, как ты просил). Разработчикам Java показалось удобным, если исходные тексты и скомпилированные классы будут храниться в дереве каталогов, где названия каталогов совпадают с названиями пакетов, а имена файлов строятся из имён классов. При этом были учтены очевидные грабли: запрещённые символы, чувствительность к регистру букв.
Кроме того, Java позиционируется как кроссплатформенная технология, а значит, Windows может не являться основной средой разработки. Сможет ли разработчик, не использующий Windows, догадаться не использовать nul или aux в качестве компонента в названии класса? Мой опыт показал, что совсем не обязательно.
Могу привести ещё несколько примеров, как недостаточно полное понимание разработчиками устройства пространства имён приводит к появлению ошибок (в том числе брешей в безопасности) в программах.
>Во-первых, успокойся, я не собираюсь оспаривать тот факт, что Windows - современная операционная система, используемая настоящими профессионалами, вобравшая в себя ...., предоставляющая ....(можешь продолжить сам).
Хммм... а кто тут беспокоицца?
Я вовсе не являюсь апологетом этой операционки... также, как и любой другой... просто интересно было, в чем принципиальность сего момента...
>Во-вторых, с моей точки зрения было бы правильно разрешать в качестве имени файла любую последовательность байт (ну хорошо, от ограничения на длину избавиться непросто ). То, что в юниксах никак не получить в имени файла символы '/' и '\0', мне не нравится.
>Все остальные (ещё более искусственные) ограничения только сильнее усложняют описание пространства допустимых имён, и, как следствие, затрудняют использование файловой системы прикладными программами. То есть, на первый взгляд разработчику кажется удобным использовать значимые имена файлов для хранения полезной информации, а сложность устройства пространства имён затрудняет это.
Что уж тут спорить... это, конечно, удобно, когда можно просто обозвать файл нужной строкой и все... врочем, это повсеместно практикуется... проблемы типа описанной зачастую просто склонны не замечать...
>Пример (из реальной жизни, как ты просил). Разработчикам Java показалось удобным, если исходные тексты и скомпилированные классы будут храниться в дереве каталогов, где названия каталогов совпадают с названиями пакетов, а имена файлов строятся из имён классов. >При этом были учтены очевидные грабли: запрещённые символы, чувствительность к регистру букв.
>Кроме того, Java позиционируется как кроссплатформенная технология, а значит, Windows может не являться основной средой разработки. >Сможет ли разработчик, не использующий Windows, догадаться не использовать nul или aux в качестве компонента в названии класса? Мой опыт показал, что совсем не обязательно.
Понятно... чего-то в таком духе я и ожидал...
>Могу привести ещё несколько примеров, как недостаточно полное понимание разработчиками устройства пространства имён приводит к появлению ошибок (в том числе брешей в безопасности) в программах.
Давай... интересно...
Хммм... а кто тут беспокоицца?
Я вовсе не являюсь апологетом этой операционки... также, как и любой другой... просто интересно было, в чем принципиальность сего момента...>Во-вторых, с моей точки зрения было бы правильно разрешать в качестве имени файла любую последовательность байт (ну хорошо, от ограничения на длину избавиться непросто ). То, что в юниксах никак не получить в имени файла символы '/' и '\0', мне не нравится.
>Все остальные (ещё более искусственные) ограничения только сильнее усложняют описание пространства допустимых имён, и, как следствие, затрудняют использование файловой системы прикладными программами. То есть, на первый взгляд разработчику кажется удобным использовать значимые имена файлов для хранения полезной информации, а сложность устройства пространства имён затрудняет это.
Что уж тут спорить... это, конечно, удобно, когда можно просто обозвать файл нужной строкой и все... врочем, это повсеместно практикуется... проблемы типа описанной зачастую просто склонны не замечать...
>Пример (из реальной жизни, как ты просил). Разработчикам Java показалось удобным, если исходные тексты и скомпилированные классы будут храниться в дереве каталогов, где названия каталогов совпадают с названиями пакетов, а имена файлов строятся из имён классов. >При этом были учтены очевидные грабли: запрещённые символы, чувствительность к регистру букв.
>Кроме того, Java позиционируется как кроссплатформенная технология, а значит, Windows может не являться основной средой разработки. >Сможет ли разработчик, не использующий Windows, догадаться не использовать nul или aux в качестве компонента в названии класса? Мой опыт показал, что совсем не обязательно.
Понятно... чего-то в таком духе я и ожидал...
>Могу привести ещё несколько примеров, как недостаточно полное понимание разработчиками устройства пространства имён приводит к появлению ошибок (в том числе брешей в безопасности) в программах.
Давай... интересно...
> Давай... интересно...
Можно упомянуть различные варианты использования ".." в URL как способ заставить веб-сервер отдать нужный файл. Исправляется и вновь возникает в других местах с завидной регулярностью.
Novell вроде бы была вынуждена встроить специальную обработку вышеперечисленных имён в свои файл-серверы, чтобы у клиентов не было проблем. Распаковщики архивов тоже, по идее, должны это учитывать, но не знаю, как на практике.
Ввели в Windows символические ссылки - поломались многие обходилки каталогов.
Хватит пока, устал думать
Можно упомянуть различные варианты использования ".." в URL как способ заставить веб-сервер отдать нужный файл. Исправляется и вновь возникает в других местах с завидной регулярностью.
Novell вроде бы была вынуждена встроить специальную обработку вышеперечисленных имён в свои файл-серверы, чтобы у клиентов не было проблем. Распаковщики архивов тоже, по идее, должны это учитывать, но не знаю, как на практике.
Ввели в Windows символические ссылки - поломались многие обходилки каталогов.
Хватит пока, устал думать
ну что же теперь делать, а?
я ".." и линки тоже ни на что не поменяю
я ".." и линки тоже ни на что не поменяю
А! Забыл про <IMG SRC="file:///dev/mouse"> и аналоги для Windows.
Но это, правда, уже не к пространству имен, а к их семантике относится, как и пример с символическими ссылками.
Но это, правда, уже не к пространству имен, а к их семантике относится, как и пример с символическими ссылками.
Оставить комментарий
w3w231
Интересно, в последних версиях виндов (2000, XP) уже можно создавать файлы и каталоги (сорри, папки