И что он с этим сделает?

Что скажешь, то и сделает. За тебя то он задачу решать не будет - компьютер ее не знает.

Поправка: в случае чуть более сложных скриптов выигрывает у баша.

Я думал, это понятно из контекста.

Представим, что в юниксе все данные хранятся в посвоему закодированных блобах и у каждого своя программа для добычи оных (кто сказал «man journald»?!).

А что представлять, если так и есть? Данные хранятся в файлах (все есть файл), а всякие тулзы, которые дергает баш - читают эти файлы (которые представлены в виде иерархии, то есть как раз структурированно) и дают плейнтекст выхлоп.

Сколько вариантов выдаёт ПШ при автокомплите слова get-?

Ну так в линуксе тебе надо было знать имя файла, который хочешь открыть, в случае пош - это имя как раз после get- и есть.

cat filename = get-filename

Сам факт «ужеразобранности» экономит небольшую и самую простую часть работы.

Это зависит, конечно, от задачи.

Аттрибут объекта «что там get-* умеет возвращать»? Кажется, ты забыл контекст - мы искали неоченьпонятночто в везде, задампив все аттрибуты всех объектов в текстовый вид. vim не умеет такое редактировать.

Аттрибут объекта «что там get-* умеет возвращать»?

Ну выбираешь атрибут и возвращаешь. В чем проблема?

Кажется, ты забыл контекст - мы искали неоченьпонятночто в везде, задампив все аттрибуты всех объектов в текстовый вид. vim не умеет такое редактировать.

Такое никто не умеет редактировать, что дальше-то?

что представлять, если так и есть? Данные хранятся в файлах

Кодировка одинаковая. Допустим, часть в utf8, другая cp1251, третья в ebcdic, в разных вариантах ucs-а... Это ещё хорошо, можно говорить «их все iconv открывает». В вашем случае для каждого свой get-(filename для файлов, process для просессов, и т.д.). Считай, по отдельной кодировке для каждого типа файлов.

файлы ... представлены в виде иерархии

Файлы внутри плоские, и содержат сериализацию объектов, с данными которых приходится работать. Можно работать напрямую с сериализацией (которая есть последовательность строк и т.д.)

в линуксе тебе надо было знать имя файла, который хочешь открыть

Давно отучился пользоваться автокомплитом для файлов, имя которых неизвестно. Непродуктивно это. Кажется, ты говоришь только об объектах типа «файл». В этом изолированном аспекте ПШ даже хуже остальных - где «файл» как объект не видим пользователю, который оперирует всегда только с именами или ещё какими аттрибутами, того же типа(строка). В ПШ тебе придётся(вероятно - я не настойко с ним знаком, может там есть какой костыль для обхода) иметь дело как с именами(которые есть просто строка) так и с объектами(с кучей редкополезных аттрибутов и медодов), и «смотри, не перепутай, Кутузов!».

Такое никто не умеет редактировать

ПШ умеет. Проблема в том, чтобы сказать ему, что нужно сделать. Для этого нужно знать как он называет то, что ты хочешь изменить.

Скажем, я могу(:ну, если рискну:) заменить ttyS0 на ttyS1 во всех настройках, логах, доках всего, юниксвейного, что есть в системе одной командой(не из-за ПШ, а из-за сериализованных данных). Тебе придётся сначала как-то добыть список объектов (у тебя есть команда «get-all-objects»?), в аттрибуты которых затесалась эта строка, найти название соответствующего аттрибута и сгенерить что-то типа «&{ $_.$attr=newvalue }» для каждого $_ и $attr(ни за что не ручаюсь).

Это зависит, конечно, от задачи

Конечно. Если задача требует обработки каждого «аттрибута»(назовём это пока так) каждого объекта и это представлено в перловом синтаксисе - ты попал. Но такое нужно редко, обычно тебе нужно 2 штуки, котрые ты находишь регекспами, остальные детали вообще не парсятся (.* съедает) и не участвуют в pipeline. Примерно то же ты получишь, если вырежешь только нужные данные первой командой. Только в «нашем» случае это упрощает работу, а в «вашем» - усложняет.

Считай, по отдельной кодировке для каждого типа файлов.

По какой еще отдельной кодировке, если она одна?

Файлы внутри плоские, и содержат сериализацию объектов, с данными которых приходится работать.

Файлы плоские, только вот объект - не файл, а папка, которая содержит другие папки (подобъекты), которые уже в самом конце содержат файлы.

Давно отучился пользоваться автокомплитом для файлов, имя которых неизвестно.

Ну так если неизвестно, то идешь читать мануалы. Все одинаково, никакой магии.

В этом изолированном аспекте ПШ даже хуже остальных - где «файл» как объект не видим пользователю

Он и в баше не виден. Более того, в случае баша у тебя еще большая степень косвенности из-за утилит-прокладок между шеллом и системным апи.

В ПШ тебе придётся(вероятно - я не настойко с ним знаком, может там есть какой костыль для обхода) иметь дело как с именами(которые есть просто строка) так и с объектами(с кучей редкополезных аттрибутов и медодов), и «смотри, не перепутай, Кутузов!».

Это как? Ничего кроме атрибутов и методов у объекта, что с чем ты путать собрался?

ПШ умеет.

Нет, не умеет, потому что это не редактор.

Для этого нужно знать как он называет то, что ты хочешь изменить.

Это и для файлов точно также. Как ты собрался менять то, не знаешь что? То есть в теории это возможно, но зачем?

Скажем, я могу(:ну, если рискну:) заменить ttyS0 на ttyS1 во всех настройках, логах, доках всего, юниксвейного, что есть в системе одной командой(не из-за ПШ, а из-за сериализованных данных).

Тебе придётся сначала как-то добыть список объектов (у тебя есть команда «get-all-objects»?)

Если бы была get-all-objects, то можно было бы обойти все объекты и поменять везде соответствующее свойство, но поскольку такая команда гарантированно повиснет (как и в линуксе) то, конечно, так сделать нельзя (как и в линуксе) :)

Если задача требует обработки каждого «аттрибута»(назовём это пока так) каждого объекта

Но посколкьу эта задача неразрешима, то она не существует на практике. Так тчо ее можно не учитывать.

Только в «нашем» случае это упрощает работу, а в «вашем» - усложняет.

Вообще-то наоборот. В первом случае тебе придется искать имена колонок, парсить, дебажить опечатки и т.д.

Во втором случае автокомплит, произведенный за тебя парсинг, гарантия отсутствия ошибок. В итоге выполняется строго меньшее количество работы. Ну да мы это уже обсуждали.

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

Да, я еще забыл python.

Про javascript ты не совсем прав. node.js не существовало, но ECMAScript не только существовал, но еще и люди умудрились довести его до стандарта ISO. Я думаю, это вполне обеспечивает ему достаточную обратную совместимость. Собственно, js десятилетней давности и сейчас беспроблемно исполняется, насколько мне известно.

Руби — это вкусовщина. Я тоже не большой фанат (кто-то из знакомых сказал «руби слишком магический»), но puppet labs демонстрирует возможность кросс-платформенного управления посредством довольно сложного софта на руби.

lua есть много где, где нужно встраивание. В той же Cisco. Я вполне допускаю, что если бы кто-то взялся писать puppet на lua, получилось бы не хуже, а, возможно, даже лучше.

команды общаются друг с другом не текстовыми потоками, а типизированными объектами

Опыт использования ActiveX их ничему не научил?

А перед этим dcom «который так же имел существенный недостаток»

Не существует ни одной пользовательской задачи, которая решается через удобнее, чем мышкой.

Хрена вам, как раз самые распространенные вопросы от пользователей при изменении ui, а он за последние годы все чаще и чаще меняется под всеми ос и софтом, «где мне сделать хорошо? раньше было теперь найти не могу»

Так что шелл - это инструмент только администраторов.

А вот он не так меняется как ui. Стабильность.

Ничего кроме атрибутов и методов у объекта, что с чем ты путать собрался

Вас в школе не учили отличать яблоко от слова «яблоко»? То же с файлами. ПШ есть нечто с названием «объект типа файл» с кучей всего. И есть имя файла(строка, по которой можно достать объект, или, возможно, содержимое аттрибута «имя» в этом объекте). Это сложнее, чем в баше - там есть только строка, содержащая имя.

Как ты собрался менять то, не знаешь что? То есть в теории это возможно, но зачем?

Я знаю, что менять, я не хочу вспоминать где. Нужно для, например, починки систем при существенных изменениях структуры сети:

find /etc -type f -exec sed -i -e 's/старый адрес/новый адрес/g' 

Вообще-то наоборот

В этом посте чушометр зашкалил, отвечать не стану.

Один из анонимусов, конечно, хуйню несет, но я пока не увидел ни одного реального примера, где PS хуже текстовых шеллов. Есть ли хоть один пример, где объекты реально мешают сделать то же самое, что в традиционном шелле? Я в этой теме уже несколько раз написал, что тот факт, что он объектный ничуть не уменьшает его возможности работы с текстом. Ну то есть ничто не мешает написать ту же команду в PS и она выполнится точно так же. Кроме того там где надо - он умеет преобразовывать объекты в текст (ну, например, если сделать подстановку в строку объекта файл, то он заменится на путь файла).

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

Хрена вам, как раз самые распространенные вопросы от пользователей при изменении ui, а он за последние годы все чаще и чаще меняется под всеми ос и софтом, «где мне сделать хорошо? раньше было теперь найти не могу»

Так шелл тоже меняется, и еще быстрее и чаще чем иу. И привыкать к изменениям шелла гораздо больнее. Тут штука такая, что если по факту - да, теоретически бывают задачи, с которыми проще справиться через шелл. Но они встречаются раз в год. Если человек уже умеет работать с шеллом (как это выходит, например, в случае линукса) - то он может решить ее через шел. Если же речь о винде - то только кретин будет изучать шелл, чтобы немного быстрее решить одну задачу раз в год.

Это сложнее, чем в баше - там есть только строка, содержащая имя.

Со строкой, содержащей имя файла, нет способа совершить какие-то полезные действия. На практике у тебя есть строка и куча команд/софтин, которые умеют с ней работать. То же самое и в ПШ, просто там часть этих команды засунуты в методы класса.

Я знаю, что менять, я не хочу вспоминать где.

Это одно и то же.

И ни разу оно не зависнет.

Если будешь искать _по всем_ файлам - конечно зависнет, но ты же ищешь не везде, ты знаешь, что то, что ты ищешь - находится в /etc

То есть это не подмонтированные к фс системные объекты, о которых мы говорили до этого, а какие-то конфиги чего-то там. Точно так же будешь искать это в поше.

У меня чушометр зашкалил еще на прошлой странице. Ты не устал черное белым называть?

Со строкой, содержащей имя файла, нет способа совершить какие-то полезные действия

Это ты не подумавши сказал. показать клиенту, преобразовать как-то, и передать куче команд-софтин - иногда полезные действия.

часть этих команды засунуты в методы класса

Ну да. Программисты до сих пор спорят о том, насколько это усложняет жизнь. Я отстаиваю более безумную идею, не о методах(в простых случаях оно изоморфно), а о простых «свойствах», значения которых в «юниксвейном» подходе свалены в одну кучу строк в файле, имя которого - единственное, что пользователью стоит знать(о то необязательно), а в ПШном - загружается в некие «объекты», которые предоставляют пользователю досуп к конкретному значению, если он попросит это посредством .имяаттрибута. Очевидно, второе предоставляет кучу преимуществ для кучи задач - тем интереснее доказывать, что это не так. Остальное в ответе соседнему анониму, тут почему-то не принимает.

И вот, мне кажется, я нашёл случай, когда это доказуемо - обычная работа пользователя шела. Маленькая ниша между мышетыкательной и програмописательской активностью. Когда вручную уже слишком долго, а загружать мозги сложными структурами ещё лень. Сюда попадает задача «массового управления серверами», для чего ПШ, вероятно, и предназначался, и в чём достаточно хорош. Но он притянул относительно сложные (для ленивого недопрограммиста) абстракции, что делает ПШ излишне сложным для задачи «шела». А необходимость «шельности» не даёт возможности стать удобным языком программирования общего назначения.

ничуть не уменьшает его возможности работы с текстом

Само собой. Он усложняет ввод-вывод данных в пользователя.

Посмотрим на это издали. Есть yaml, на котором удобно писать данные. Есть, например, питон, на котором удобно писать программы. Но данные на питоне выглядят, мягко говоря, не очень (много синтаксического мусора). И, наверное, так же бы выглядели программы в yaml-е. Потому, что нельзя коротко записать всё, ты оптимизируешь вид одних элементов за счёт вида других.

Шел - пользовательская оболочка. Пользователь нужен компу для поставки или потребления данных. Т.о. его шел должен быть ближе к языку описания данных. В олдскульных шелах - всё относительно просто, любое слово есть аргумент (кусок текста) - за исключением какого-то минимума для нужд мелкой автоматизации, а с остальным пусть программы разбираются. И это именно то, на что способен stdout человека. Отсюда куча неприятностей с пробелами в именах файлов(уже приходится «» расставлять). stdin чуть богаче - он двумерный и может некоторые цвета различать. Но если формат ввода и вывода сильно отличается, человеку приходится заниматься трансляцией, что отнимает ограниченные ресурсы процессора. Потому лучше не злоупотреблять.

В ПШ структуры данных сложнее, потому так просто не отделаешься. И пользователю приходится думать/вводить/выводить более высокими абстракциями. А его жалеть нужно, он недостаточно мощный для этого. Ну, если не считать привыкших думать деревьями программистов и жителей ложбанистана.

Ты не устал черное белым называть

Доказывать очевидное не так интересно. А по поводу того сообщения - аноним выпал из контекста, какой смысл повторять уже написанное, если оно в его голове не удерживается.

Про могучий автокомплит.

подсказано автокомплитом...ни одного мануала не пришлось читать

Как на самом деле выглядит попытка использования автокомплита, из моего опыта.

Хотим достать список хостов из CMDB. Находим, как загрузить её интерфейс, и, вдохновлённые идеей автокомплита, получаем объект «application». Пишем $app. - читаем список из 30 методов, нужный находим 4м сзади, по дороге подолбавшись об встретившийся по дороге CreateSession, ничего полезного не делающий. Ок, получили объект «сессия». У него приходится пересматривать порядка 30 методов, начинающихся на «get» и, ничего не обнаружив, 40 свойств. Убеждаемся, что слова «index» и «inventory» не имеют отношения к искомым данным. Перечитываем уже полный список из 100 методов и свойств. Находим, что наиболее вероятный кандидат на хранение информации почему-то называется «requestFolders». Тут уже можно воспользоваться поиском, но присоветованный тут sls выводит пустой список. Читаем всё, находим нужный фолдер всего 114м.,. К этому времени фантазия авторов прогрелась и готова ко взлёту, но это уже не о пользе автокомплита, а о преимуществах структурированных данных.

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

Так шелл тоже меняется, и еще быстрее и чаще чем иу. И привыкать к изменениям шелла гораздо больнее.

Да что вы говорите... вот смотрю я стопку bash скриптов написанных мной в 2003 году и удивляюсь почему они без изменений продолжают работать и на современных дистрах...

Опять поехали. Еще раз - приведи ХОТЬ один пример, где объекты мешают работать. Ты говоришь «усложняет ввод-вывод данных в пользователя» - покажи пример. Пока ты только словами разбрасываешься. Я не могу представить ни одного случая, где работать пользователю с PS было бы сложнее или менее удобно.

показать клиенту, преобразовать как-то, и передать куче команд-софтин - иногда полезные действия.

Именно об этом я и сказал, читай внимательнее. Все как в пош.

Ну да. Программисты до сих пор спорят о том, насколько это усложняет жизнь.

Ни на сколько.

(в простых случаях оно изоморфно)

Нет, методы удобнее.

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

Пользователь _обязан знать внутреннюю структуру файла, чтобы работать с ним через баш. Ты не можешь ни запросать какую-то колонку, ни даже отфильтровать какие-то строки, если структуры не знаешь.

Когда вручную уже слишком долго, а загружать мозги сложными структурами ещё лень.

Ты никак не хочешь понять, что загружать мозги структурой надо тогда, когда тебе необходимо работать с этой структурой - как в баше. А в поше тебе как раз эту структуру знать не надо, потому что файл, условно говоря, уже «распарсили» за тебя. Вся работа со структурой минует пользователя пош.

Он усложняет ввод-вывод данных в пользователя.

Это каким образом?

В ПШ структуры данных сложнее, потому так просто не отделаешься.

Тебе вообще не надо знать, что у данных в пош даже есть эта структура. Просто забудь про нее, считай, что данные абсолютно неструктурированы. Это не баш, где форма скритпа зависит от структуры данных, и ты ее знать _обязан_, чтобы правильно выбрать нужные данные.

читаем список из 30 методов

Зачем? Ты же знаешь часть имени метода, который тебе нужен. Начинаешь его набирать, и остается 2 метода из 30.

Вывод: автокомплит полезен, когда ты зачем-то назвал известные тебе сушности известными именами, которые трудно писать.

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

Перечитываем уже полный список из 100 методов и свойств. Находим, что наиболее вероятный кандидат на хранение информации почему-то называется «requestFolders».

Извиняюсь, а в башке ты как бы смог найти нужное свойство из сотни?

По-моему, там идиотский синтаксис.

Да что вы говорите... вот смотрю я стопку bash скриптов написанных мной в 2003 году и удивляюсь почему они без изменений продолжают работать и на современных дистрах...

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

Пользователь _обязан знать внутреннюю структуру файла

Вот это ложь. Обычно достаточно контекста. «то, что идёт после IPADDR=» - это не знание структуры.

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

Открою «большой секрет» часть из них как раз и занимается разворотом на новый хард из «базовой системы» т.е. разбить хард на разделы, развернуть систему... поменять настройки.... и все еще работает же...

Ты же знаешь часть имени метода

Не часть а именно начало, первые буквы. И опыт показал, что это ничем не гарантировано. Скажем, встроенные в ПШ объекты типа «правильно» названы. get- подсказывает страниц восемь типов объектов. И я никак не могу угадать, на что начинается следующее слово (например, к чему относится или не относится «child»).

а в башке ты как бы смог

Точно так же - полным перебором. Об этом и разговор - рулит не автокомплит а знание или грамотная документация, откуда петвое берётся.

Что? Где far? С руками бы оторвал после mc.

где объекты мешают работать

Это из общих соображений - ввести любые поддерживаемые данные в tcl или bash проще, чем в любом типизированном языке(минимум - кавычки нужны). Из того немногого, что я знаю про ПШ, со строками не хуже. Но там есть ещё объекты, которые уже менее красивые. Синтаксис это должен поддерживать, что его усложняет. В баше почти ничего кроме строк нет, синтаксис может быть проще. Это не проблема ПШ, это проблема цены доп. возможности.

Не обязательно. Несмотря на то, что шелл типизированный, он умеет приводить типы к строкам когда надо и кавычки для этого ставить не обязательно. Вот, например:

PS C:\Users\Demo> $f = ls .\Downloads\DOOM.mp4
PS C:\Users\Demo> $f.getType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     FileInfo                                 System.IO.FileSystemInfo


PS C:\Users\Demo> $f.fullName
C:\Users\Demo\Downloads\DOOM.mp4
PS C:\Users\Demo> echo $f


    Каталог: C:\Users\Demo\Downloads


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       15.05.2016     14:05       15743960 DOOM.mp4


PS C:\Users\Demo> vlc $f
PS C:\Users\Demo> ps vlc

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    573      39   242848     144180       1,44   9348   1 vlc


PS C:\Users\Demo> gwmi Win32_Process -filter processId=9348 | % commandLine
"C:\Program Files\VideoLAN\VLC\vlc.exe" C:\Users\Demo\Downloads\DOOM.mp4

Так я увижу хоть один пример, где объектность реально мешала бы?

Вот это ложь. Обычно достаточно контекста. «то, что идёт после IPADDR=» - это не знание структуры.

Это знание структуры. Конечно, не полное - но большее, чем требуется в поше. Кроме того надо знать не только ipaddr, надо знать все поля.

Открою «большой секрет» часть из них как раз и занимается разворотом на новый хард из «базовой системы» т.е. разбить хард на разделы\

То есть то, о чем я и говорил - вещи, не связанные с редактированием конфигов.

Не часть а именно начало, первые буквы.

Зачем первые буквы? Любую часть. Хоть последние буквы, хоть что-то из середины.

Скажем, встроенные в ПШ объекты типа «правильно» названы. get- подсказывает страниц восемь типов объектов. И я никак не могу угадать, на что начинается следующее слово (например, к чему относится или не относится «child»).

Команды, естественно, надо знать. Так же ты не можешь угадать, к чему относится ls или cp. Это очевидно. Магии нет.

Об этом и разговор - рулит не автокомплит а знание или грамотная документация, откуда петвое берётся.

Ты все сводишь к случаю когда «нишмогла не получилось». Разница между пошем и башем в том, что в баше у тебя всегда «нишмогла» и никаких других вариантов нет. В поше же в _большинстве_ случаев мы этого избегаем. Иногда (в меньшинстве случаев) - не избегаем, тогда выигрыша нет. Но в большинстве - есть.

Это из общих соображений - ввести любые поддерживаемые данные в tcl или bash проще, чем в любом типизированном языке(минимум - кавычки нужны).

Да ничем не проще. Конкретный пример ты можешь привести?

В баше почти ничего кроме строк нет, синтаксис может быть проще.

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

В баше почти ничего кроме строк нет, синтаксис может быть проще.

Это весьма спорный тезис.

Так я увижу хоть один пример, где объектность реально мешала бы?

Тебе придётся его сделать - я не знаю, как «правильно» ПШать, а сравнивать на некошерном коде не честно. Эксперимент такой:

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

mv * $dst/ -- ТЗ - начальная версия
for i in ... cp $i $dst/.$i && mv $dst/.$i $dst/$i && rm $i -- ТЗ - нужно прятать недокопированные файлы
do done && $ -- баш - синтаксис
shopt -s pipefail -- баш - детали реализации(или стандарт)
test -f "$i" || continue -- ТЗ - не трогать подкаталоги
"" вокруг всех $переменных -- баш - пробелы в значениях переменных
cat $i | tee $dst/.$i >$dst2/.$i || continue ; mv $dst2/.$i $dst2/$i && -- ТЗ - нужно в 2 места; cp - негодное
trap "" TERM INT -- ТЗ - не доставлять файлы повторно при ребутах

Может случиться, что ты не найдёшь, в чём винить объекты. Я бы посмотрел на эту версию - пока мне кажется, что это потребует перехода к «всё есть строка»(и т.о. устранение объектных неприятностей) на как можно более ранних этапах, что есть читинг.

Зачем первые буквы? Любую часть.

Спасибо, действительно работает. Авторам пирожок. Обсуждение становится эффективным, всего неделя ругани, а я уже новую фичу узнал:)

Где увидишь в списке виноватых слово «объект/аттрибут/метод» - там и усложнения.

Нигде не увидишь.

В твоём примере лишним уже выглядит "()" - пользователю нужно помнить что ".getType()" а не ".type"

Эмм... Зачем?

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

Не совсем понял, что надо сделать, если честно.

mv * $dst/ -- ТЗ - начальная версия
for i in ... cp $i $dst/.$i && mv $dst/.$i $dst/$i && rm $i -- ТЗ - нужно прятать недокопированные файлы
do done && $ -- баш - синтаксис
shopt -s pipefail -- баш - детали реализации(или стандарт)
test -f "$i" || continue -- ТЗ - не трогать подкаталоги

->

mv * $dst
ls -File | % { cp $_ $dst/.$_; mv $dst/.$_ $dst/$_; rm $_  }

cat $i | tee $dst/.$i >$dst2/.$i || continue ; mv $dst2/.$i $dst2/$i && -- ТЗ - нужно в 2 места; cp - негодное

ничем не проще. Конкретный пример

Номер телефона. В типизированных его нужно в кавычки засовывать(:небольшое усложнение, но есть же:). В структурированных - место в структуре придумывать. В автопреобразующих туда - сюда - осторожничать при выборе операции. В заранее декларирующих - декларации рисовать. Что-то типа хаскелесвкого автовывода типов, вероятно, сработало бы, но такого и в компилируемых языках не часто встречается, не говоря уже о «шелах». Удиви меня тоже - ПШ умеет догадываться, что я имел в виду, нажимая кнопку 5 — «5», 5.0 или 5?

что надо в 2 места

2ю копию в другой каталог. Но это не существенно, придумай что угодно другое «полезное».

Приведенное показывает, если я правильно понял, что ПШ умеет преобразовывать «файлы» в «строки» так, как этой задаче нужно, и если не хотеть «необычного», объекты не мешают.

А как ты узнаёшь, что есть «обычное»? Что в данном конкретном случае достаточно $_, а не $_.свойство, или $_.метод(параметры)? Что оно не превратится в fullName, как вот тут, сгенерировав совсем непотребный путь? Где почитать, как эта магия работает для других команд и объектов?

Открою «большой секрет» часть из них как раз и занимается разворотом на новый хард из «базовой системы» т.е. разбить хард на разделы\

То есть то, о чем я и говорил - вещи, не связанные с редактированием конфигов.

Не выдергивайте из контекста, далее я писал: «поменять настройки.... »