> Немного отхотя от темы замечу, что у шелла есть достаточно данных для
> анализа вводимой строки и теггирования её частей. Например, шелл всегда знает
> что является результатот глоббинга, знает через autocomplete что ожидается в какой-то
> позиции - через свою же подстановку путей или через вспомогательный скрипт,
> который делает некий синтаксический разбор и уже имеет теггированные части.
> Всем срать что ты там делаешь у себя в командной строчке. (ba)sh
> используется для автоматизации различных процессов и большая часть проблем возникает именно
> здесь, а не у тебя в ручном режиме. Оснвная задача теггированя
> это дать возможность защиты от ошибок в автоматике.ммм...
> знает через autocomplete
> большая часть проблем возникает именно здесь, а не в ручном режиме
1. Как это связано между собой?
2. Вы не думали о том, чтобы заменить для себя sh на что-нибудь другое. На python/ruby/php... На что-нибудь, что позволит вам при написании автоматизирующих скриптов, использовать более удачный интерфейс, который сможет исправлять недостатки? По-моему, это было бы правильно, ведь sh, всё же, не зря сокращение от shell -- это, в первую очередь, интерактивная командная строка.
>> Расскажите мне, как вы планируете тегировать поток черектеров проходящий через pipe. Ведь список аргументов может генерироваться сторонним процессом, и передаваться в качестве аргументов целевому.
> Я то тут причём? Мне лично до одного места как ты будешь
> решать эту проблему. Каждый делает всё в меру своего идиотизма.
Тогда поясните цели, которыми вы руководствуетесь, выступая здесь.
>> Отмечу, что теги придётся уметь хранить и в файле, потому, что создавая список файлов/опций для вызова программы (б.м. многократного), бывает удобно складывать список опций/файлов в файлик, по одной на строке.
> Аналогично, фантазии гогнокодера нет предела. Нормальные люди в файлах хранят структруированные
> данные на основне которых можно генерировать аргументы.
Этим я занимаюсь иногда, но не тогда, когда решаю задачу, которую надо решить *однократно*. Возиться со структурированными данными, писать программы и комплексы программ для *однократной* задачи -- это идиотизм по-определению, поскольку *однократную* задачу быстрее решить вручную, чем через полный цикл разработки программы.
>> я, как пользователь командной строки, должен иметь возможность использовать тогда, когда мне это удобно, потому что случается собирать аргументы из данных имеющих строковый или числовой тип.
> Уже выше писал как это работает. Теги это хинты назначаения частей строки,
> не знаю почему вдруг у вас голове они стали типами.
Потому что "тип" -- это очень удобное понятие из программирования, на которое красивым образом ложатся ваши "хинты", и позволяют разговаривать в привычных терминах, не изобретая велосипеда.
> Легаси код, или в случае невозможности проставить тег, ставит неопределённый тег RAW.
Это понятно. Но было бы неплохо, если бы хотя бы что-нибудь гарантированно имело бы тег, отличный от RAW. Например, чтобы опции команды, гарантированно имели бы тег OPT. Иначе какой смысл во всём этом тегировании?
>> В общем я к тому клоню, что если начать тегировать, то кончится это неуёмным использованием xml'я во все щели. Быть может, разработчики-таки придумают свой синтаксис, покомпактнее xml'я, но, боюсь, сильно лучше от этого не станет.
> у вас в голове всё смешалось в одну кучу. Прежде чем рассуждать
> нужно разобраться где есть что.
Несмотря на это ваше заявление, я всё же остаюсь при мнении, что вы не представляете себе проблему во всей её сложности. Вы понимаете, что для решения вашей проблемы, придётся заталкивать в язык шелла типизацию? То есть, переменные типа RAW, хранящие строки неопределённого назначения, переменные типа OPT, в которых идёт накопление опций для команды, которая будет запущена ниже. Заодно уж тогда, придётся завести переменные типа INT, и пр, дабы получив себе геморрой связанный с типизацией, иметь возможность извлечь из него максимум удобств. Опять же возникает вопрос: может вы используете не тот инструмент, для решения задач? Может на самом деле, взять python и написать в нём целый API заменяющий вызов system, который будет реализовывать эти самые типы данных, и по типам раскидывать опции и не-опции в командной строке так, чтобы запускаемая программа не путалась бы в соплях?
>> И, между прочим, чтобы решить описанную выше проблему, я могу предложить вам следующий скрипт
> это не решение, это последние беспомощные вопли утопающего.
Обоснуйте.
