Страница 104 из 130

Добавлено: Ср дек 23, 2015 01:13
Flasher
MVV писал(а):Вот не надо ~ сюда втягивать, она внутри строки парсится.
Но в паарметрах может играть роль оператора и не играет роль ENTER-а.
MVV писал(а):Ну ты бы мог, скажем, выбрать символ ±...
А что с ним не так? Он как-то не так обрабатывается в строчном параметре? Запрещённым-то он не является.
MVV писал(а):А то завтра ты (или кто-то ещё) захочешь возможность записывать в INI строки с косой кавычкой...
Найти бы ещё такого глупца. Я подобной ерундой точно заниматься не стану. У меня только один запрос - решить проблему с переменными.

Добавлено: Ср дек 23, 2015 01:42
MVV
Flasher писал(а):А что с ним не так? Он как-то не так обрабатывается в строчном параметре? Запрещённым-то он не является.
Не является. Юникодным он тоже не является. При этом достаточно редкий.
Flasher писал(а):Найти бы ещё такого глупца. Я подобной ерундой точно заниматься не стану. У меня только один запрос - решить проблему с переменными.
А я пытаюсь мыслить шире и не вижу ничего ненормального в желании записать в конфиг, скажем, тот же путь к файлу, который может содержать эту несчастную косую кавычку. В голову пришли двухсимвольные кавычки для повышения редкости завершающей последовательности (в PowerShell есть @''@ и @""@, но у нас @ уже задействована, поэтому не катит). Можно сделать <``>, !``!, $``$, (``) - каждая по-своему уникальна, чтобы завершающая пара не встречалась в нормальных строках.

Добавлено: Ср дек 23, 2015 02:21
Flasher
MVV писал(а):При этом достаточно редкий.
Редкие я бы и не стал предлагать, иначе бы смысл в запросе терялся.
MVV писал(а):не вижу ничего ненормального в желании записать в конфиг, скажем, тот же путь к файлу, который может содержать эту несчастную косую кавычку
Пожалуйста, найди мне такого "нормального". Я буду только рад расширить свой мыслительный кругозор. :)
Нисколько не могу быть против общего случая, главное, чтобы это не остановило реализацию.
MVV писал(а):В голову пришли двухсимвольные кавычки
Т.е. "двухсимвольные"? @' или @" - в таком смысле? А что это даст?
MVV писал(а):Можно сделать <``>, !``!, $``$, (``) - каждая по-своему уникальна, чтобы завершающая пара не встречалась в нормальных строках.
Последние 3 не годятся, они не запрещённые. Поэтому остаётся только <>, как и предлагалось. Только зачем ещё и `` прописывать? Не проще только альтернативные символы использовать, создав возможность выбора, как в случае с test/eval?

Добавлено: Чт дек 24, 2015 00:52
MVV
Flasher,
Двухсимвольные кавычки - это в которых начало и конец строки определяются последовательностью из двух символов. В PowerShell многострочные строки могут кодироваться такими штуками (тут на самом деле всё сложнее, тут завершающая последовательность ещё и обязана быть в начале новой строки):

Код: Выделить всё

$s = @'раз
два
три
'@;
Нам многострочные не нужны, но нам тоже нужно, чтобы последовательность конца строки наименее вероятно могла встретиться в середине строки, используемой в TCFS2. И двухсимвольные последовательности в этом плане значительно превосходят односимвольные.

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

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

Добавлено спустя 2 часа 57 минут:

Насчёт предложенных вариантов могу сказать, что мне более-менее нравятся все, а вероятность "ложного срабатывания" любого из вариантов приблизительно одинакова - практически нулевая (с учётом значения грависа). Поэтому нужно просто изобразить примеры строк с разными вариантами и прикинуть, какой смотрится нагляднее. В этом плане, пожалуй, круглые скобки проигрывают, т.к. скобок в выражениях и так хватает. Угловые скобки, в свою очередь, являются символами перенаправления ввода-вывода, следовательно и источником потенциальных проблем (я бы избегал использования символов, которые у командного интерпретатора на особом счету).

Код: Выделить всё

TCFS2 /ef "tcd(, !`D:\My dir\Бла-бла-бла\Файл.txt`!, s)"
TCFS2 /ef "tcd(, #`D:\My dir\Бла-бла-бла\Файл.txt`#, s)"
TCFS2 /ef "tcd(, $`D:\My dir\Бла-бла-бла\Файл.txt`$, s)"
TCFS2 /ef "tcd(, (`D:\My dir\Бла-бла-бла\Файл.txt`), s)"
TCFS2 /ef "tcd(, ?`D:\My dir\Бла-бла-бла\Файл.txt`?, s)"
TCFS2 /ef "tcd(, [`D:\My dir\Бла-бла-бла\Файл.txt`], s)"
TCFS2 /ef "tcd(, {`D:\My dir\Бла-бла-бла\Файл.txt`}, s)"
TCFS2 /ef "tcd(, ~`D:\My dir\Бла-бла-бла\Файл.txt`~, s)"
TCFS2 /ef "tcd(, <`D:\My dir\Бла-бла-бла\Файл.txt`>, s)"

Добавлено: Чт дек 24, 2015 02:07
Flasher
MVV писал(а):я хочу сохранить обрамляющий строки символ, чтобы неподготовленному человеку было понятно, что это всё-таки строка, а не какое-нибудь непонятное выражение.
Неподготовленный к чему? Для этого же ReadMe есть.
MVV писал(а):вероятность "ложного срабатывания" любого из вариантов приблизительно одинакова - практически нулевая (с учётом значения грависа).
Т.е., выбери мы !, и имя файла будет таким - Внимание!`важный файл!`, tcd(, !`D:\My dir\Внимание!`важный файл!``!, s) сработает как надо?
Если нет, то остаётся сойтись на знаке вопроса, раз угловые скобки тебя не устраивают.

Добавлено: Чт дек 24, 2015 12:22
sa
MVV писал(а):Угловые скобки, в свою очередь, являются символами перенаправления ввода-вывода, следовательно и источником потенциальных проблем
Но мы же используем их в параметрах, как операторы "больше', "меньше" и как-то не натыкаемся на проблемы.

Добавлено: Чт дек 24, 2015 16:33
MVV
Flasher писал(а):Т.е., выбери мы !, и имя файла будет таким - Внимание!`важный файл!`, tcd(, !`D:\My dir\Внимание!`важный файл!``!, s) сработает как надо?
Если нет, то остаётся сойтись на знаке вопроса, раз угловые скобки тебя не устраивают.
Ты уж чересчур надуманный пример привёл. Покажи мне ненормального, который так назовёт файл. Грависы - они не для такой ерунды. :D
sa писал(а):Но мы же используем их в параметрах, как операторы "больше', "меньше" и как-то не натыкаемся на проблемы.
Да, действительно.

Добавлено: Чт дек 24, 2015 16:42
Flasher
MVV
Неважно, какой я пример привёл. Важно, как это будет работать, т.е. исключить любую потенциальную проблему, если есть такая возможность. Иначе можно сослаться и на отсутствие смысла в наличии косой кавычки в именах.

Добавлено: Чт дек 24, 2015 16:56
MVV
В русских именах ей и нечего делать, но в некоторых языках это вполне себе символ, который, тем не менее, используется не абы где.

Ещё вариант - утроить косые кавычки в начале и конце строки. Выглядеть вроде будет не особо сложно, встречаться вряд ли где-то будет в именах, при этом такой вариант гораздо проще внедрить.

Код: Выделить всё

TCFS2 /ef "tcd(, ```D:\My dir\Бла-бла-бла\Фа`ил.txt```, s)"
(только в таком случае нельзя будет конкатенировать пустую строку с другими: `` `...`, хоть в этом и нет смысла)

Добавлено: Чт дек 24, 2015 17:27
Flasher
Утроить? А чего сразу не удесятерить? Я остаюсь при своём. Гадать, встречается где-то та или иная допустимая комбинация или нет, смысла не имеет. У меня встретилась косая кавычка, вылезла проблема, я и запросил. Не хочется, чтобы потом ещё что-то всплыло. Поэтому меня устроит любой запрещённый символ (<>, ? либо ещё какой, неважно).

Добавлено: Чт дек 24, 2015 18:50
MVV
Угловые скобки запрещёнными являются только в путях, но не в текстовых строках вообще, поэтому то, что захочет всплыть, ещё вполне сможет это сделать. 8)
Потому я и ломаю голову, как сделать универсальный вариант, а не костыль только для путей.

Добавлено: Чт дек 24, 2015 19:16
Flasher
Если совсем уж редкие незапрещённые ANSI брать, то есть такие варианты: ‘’ ‚ “”„ ‹ ›

Добавлено: Чт дек 24, 2015 19:50
MVV
Хорошие символы, вроде даже в большинстве кодовых страниц на одном месте расположены, я бы привёл их здесь как пример, если бы знал, что они такие. Правда, китайцы отдыхают... но у них вряд ли обычный гравис используется как-то.

Добавлено: Чт дек 24, 2015 20:19
Flasher
Если соглашаться на них, то как минимум нужно, чтобы открывающие и закрывающие были разные, и после открывающих следующие открывающие игнорировались до появления закрывающих.

Добавлено: Чт дек 24, 2015 20:23
MVV
Если соглашаться на них, то как минимум нужно, чтобы открывающие и закрывающие были разные
Это уже не имеет особого значения. В строке может встретиться любая.
и после открывающих следующие открыващие игнорировались до закрывающих
И это тоже не сильно важно. В строке может быть только одна открывающая, одна закрывающая или вообще каша.

Пока смотрю, что получается с <``>.