LINUX.ORG.RU
ФорумTalks

Про обратную совместимость, распространённость и прочее

 , ,


0

0

Я вот смотрю на убогость шелловых языков. Что sh/bash, что виндовый bat. У них нет вменяемой обработки ошибок по дефолту, эти скрипты несамостоятельны. bash/sh пытаются казаться таковыми, ведь в них есть функции, но вся эта псевдосерьёзность сходит на нет при подобных примерах:

foo = 'test   test1  test2'
echo $foo
# test test1 test2
echo "$foo"
# test   test1   test2

«НАДА БЫЛА УЧИТЬ ШЕЛЛ, ИТА ЖИ РАЗНЫЕ ВЕЩИ!!111». Но почему, если взять другую скриптуху (вроде питона), то таких приколов с выводом текста в ней нет?

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

Об отсутствии нормальных итераторов и массивов и говорить не приходится. «Зойчем нам массивы и итераторы, это же оверхед!!!11». А толку от такой скриптухи тогда?

«Но ведь оно везде, уже много лет, совместимость, пиши шелл-портянки, сидр».

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



Последнее исправление: hobbit (всего исправлений: 2)

Ответ на: комментарий от theNamelessOne

Почему, кстати? Языки скриптов разных оболочек — это вполне себе …

Вот давайте не будем путать язык скриптов общего назначения, код которого оформляется в виде соответствующих файликов, и язык работы в командной строке, причем, для вызова всяких сторонних программ. Совершенно разные требования к синтаксису и к функциональным возможностям. Или вы думаете, что админы на каждый чих должны заводить отдельный файл, запускать редактор текстов, забивать в файле несколько строчек, потом запускать этот файл … ???

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Совершенно разные требования к синтаксису и к функциональным возможностям

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

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

Или вы думаете, что админы на каждый чих должны заводить отдельный файл … в файле … файл … ???

А то пока ты только о файлах говоришь, а они на аргумент не очень тянут, если честно.

theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

Озвучь тогда эти требования, если так считаешь

Напиши код на любимом твоем языке, эквивалентный:

find <some_directory> | egrep '<some_regexp>' | xargs -I{} <some_command> {}
vinvlad ★★
()
Ответ на: комментарий от vinvlad

Ну вот в Haskell может выглядеть так, например:

find "<some_directory>" |> egrep "<some_regexp>" |> xargs "-I{}" "<some_command>" "{}" 

Тут вызываются внешние команды, но на практике часто вместо многих из них можно будет обойтись и стандартными средствами языка типа функций поиска по ФС и внутри строк.

Но мне очень нравится твой аргумент, т.е. ты считаешь, что язык shell-скриптов обязан быть убогим во всём остальном ради того, чтобы запись цепочки команд выглядела именно так? Как это оправдывает, к примеру, инопланетный синтаксис условных выражений, отсутствие именованных параметров у функций или другие сомнительные или явно устаревшие особенности?

Ведь если посмотреть на пример того же nushell, который я приводил, то внезапно окажется, что написать нормальный скриптовый язык для shell-а вполне возможно, просто надо сделать усилие и отойти от устаревшего дизайна 50-летней давности. И тут у тебя сразу появляются а) функции/команды с автоматической документацией, встроенным парсингом аргументов/опций, проверкой типов, встроенной поддержкой субкоманд, генерацией shell completions, b) нормальные конструкции языка, с) нормальные составные типы данных и средства работы с ними, d) десятки других плюшек.

И да, pipelines из команд там записывается точно так же, а многие другие конструкции можно выразить ещё более кратко (причём не в ущерб читаемости).


Напиши код на любимом твоем языке

Ок, это все требования, или ещё будут?

theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

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

abcq ★★
()
Последнее исправление: abcq (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

Ну вот в Haskell может выглядеть так …

Ну так в чем проблема-то?) Если так все компактно и замечательно, то просто пользуй, что тебе нравиться.

Но почему-то не видать такого Haskell shell-а в списке доступного - того, что можно указать при создании linux-пользователя. И дополнительного пакета не видать - чтобы установить. И сам разработчик не удосужился сделать такую простую вещь. Может «shell-scripting» и «login shell» - это немного разные вещи… Или нет?

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

Ясно-понятно) Ну не буду тогда просить ответить на вопросы, которые ты проигнорировал, смысла нет.

theNamelessOne ★★★★★
()
Ответ на: комментарий от theNamelessOne

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

Я различаю такие понятия, как «язык Shell» и «язык shell-скриптов» - для меня это разные понятия. «Язык Shell» - это язык интерактивного ввода команд. У многих, к сожалению, эти понятия перемешиваются - видимо наличие слова «shell» сбивает людей с толку )

vinvlad ★★
()
Ответ на: комментарий от vinvlad

А когда вы вводите в интерактивном режиме портянки это уже «язык шелл скриптов» или все еще «язык шелл», а когда определитесь расскажите чем собственно они друг от друга отличаются в вашем понимании. Все оказалось как я погляжу еще более запущенным, вы уже себе и терминологию выдумали. Лол конечно.

abcq ★★
()
Ответ на: комментарий от theNamelessOne

Как это оправдывает, к примеру, инопланетный синтаксис условных выражений,

Так ведь и условия из указанного списка весьма необычные - на самом деле это просто форма записи команды «test». Ну и кроме […] есть еще [[…]] и ((…)) :)

… отсутствие именованных параметров у функций?

А оно очень сильно надо в небольших функциях? А если функция большая, то ничто не мешает вставить в её начале MYVAR1="$1", MYVAR2="$2"… Кроме того, наличие очень удобной и нужной директивы shift как-то не очень сочетается с именованными параметрами. Ну и есть еще такие замечательные конструкции как "$@" и пр., которые в Shell-е, ориентированном на вызов внешних команд, гораздо важнее именованных параметров.

vinvlad ★★
()
Ответ на: комментарий от abcq

… А когда вы вводите в интерактивном режиме портянки …

«Портянка» в файле - это лишь довесок в базовому требованию быть удобным языком для выполнения действий в командной строке.

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

vinvlad ★★
()
Ответ на: комментарий от abcq

расскажите чем собственно они друг от друга

Очевидно же, в одном случае разделитель ентер, в другом точка с запятой :)

anc ★★★★★
()
Ответ на: комментарий от anc

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

abcq ★★
()
Ответ на: комментарий от vinvlad

А вы предлагаете вместо

Сами сочинили и побежали опровергать сочинённое. Я предложил вам ответить в чем различия между скриптами набранными в интерактивном режиме оболочки и скриптами набранными и исполненными из файла, но вы пока видимо не можете мне ответить, но при этом выдумали «язык шелла» и «язык скриптов шелла», все никак не поймете что это один продукт жизнедеятельности и он с запашком.

А если функция большая, то ничто не мешает вставить в её начале MYVAR1=«$1», MYVAR2=«$2»

мы это уже проходили, вы снова встаете на те же грабли неявного переопределение и пробрассывания через глобально видимые переменные, вы бы хоть для приличия local дописали, хотя это никак не аналог именованных аргументов, а просто дичь, тогда бы уж просто как в сишечке по старинке предлагали поясняющие комментарии вставлять в объявление какой по порядку аргумент для чего раз вы не можете сделать аналог именованного аргумента в портянках

Кроме того, наличие очень удобной и нужной директивы shift

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

как-то не очень сочетается с именованными параметрами.

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

Ну и есть еще такие замечательные конструкции как «$@»

Замечательная по сравнению с чем, или относительно чего, ну есть она, что дальше то? Какой-то беспредметный спам безотносительно вообще чего-либо.

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

abcq ★★
()
Ответ на: комментарий от abcq

как одно мешает другому, ну не сочетается допустим

Ну как «не сочетается»… shift в воплощении sh/bash просто не нужен при наличии в ЯП rest parameters (которые также не являются rocket science и присутствуют в куче других ЯП).

theNamelessOne ★★★★★
()
Ответ на: комментарий от theNamelessOne

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

abcq ★★
()
Ответ на: комментарий от abcq

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

Нет никакого текущего шелла - есть несколько разных шеллов, которые вы можете использовать и выбирать в настройках пользователя Unix/Linux. Можете еще один добавить - никто не мешает.

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

vinvlad ★★
()
Ответ на: комментарий от sergej

Баш — тьюринг-полный язык, в нём всё что угодно можно.

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

В павершеле конструкция

Get-Объект | where {$_.свойство -ОператорСравнения СЧемСравниваем} | select НужноеСвойство1,НужноеСвойство2

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

Поставил на Debian — работает.

muon ★★★★
()
Ответ на: комментарий от vinvlad

О, можно я, раз такая пьянка.

Get-ChildItem -Filter some_directory -Recurse | where {$_.Name -match 'some_regexp'} | some_command

Заметьте, нет ублюдочного xargs.

Я выиграл?

muon ★★★★
()
Ответ на: комментарий от anc

Нет. Это vinvlad не осилил man find.

))) Ленив - в командной строке вместо опций find-а предпочитаю egrep + xargs. Экономия места в оперативной памяти )

muon: О, можно я, раз такая пьянка … Заметьте, нет ублюдочного xargs. Я выиграл?

Нет - Вы не показали, как в аргументах произвольной команды можно использовать значения строчек входного потока. В Linux )

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 2)
Ответ на: комментарий от vinvlad

Экономия места в оперативной памяти )

Нет. И даже более чем Нет. Пайп сильно более ресурсоемкая хреновина, «Более» до невозможности/бессмысленности исполнить задуманное.
Но отчасти Вас понимаю, редко бывает нужно, без man find никак не обходиться, я последовательность символов для подстановки имени файла наверное никогда не запомню :)

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Нет. И даже более чем Нет. …

Вы не поняли - я имел в виду собственную оперативную память ) Мне приходится перепахивать постоянно такой объем новой информации, что память чистится очень сильно. Иногда смотришь на код, написанный год или два назад - а он совсем «чужой»! Перечитывать приходится «c нуля».

Если нужно машинные ресурсы поэкономить, то конечно в man залезаю )

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)
Ответ на: комментарий от vinvlad

Вы не поняли - я имел в виду собственную оперативную память )

Ну это лечиться, причем не таблетками, пара граблей и потом будете вспоминать даже если вас разбудить 1-го января в 15 ночи. :)

anc ★★★★★
()
Ответ на: комментарий от anc

… пара граблей и потом будете вспоминать …

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Не понял, что за «грабли» - но думаю, что не поможет )

Грабли граблям рознь. Запустишь так find.... | grep | sed | awk | ... и ждешь долго, потом понял что ошибся в запросе, запустил ещё, подождал, потом ещё... потом почитал ман... и через 5 часов «сначала» и 5 минут «в конце» получил результат :) Вот первые «пять часов» и есть те самые грабли :)

anc ★★★★★
()
Ответ на: комментарий от vinvlad

Часы складываются из минут. Каждое изменение в запросе требует для исполнения своих N минут, если ваша «труба» исполняется 10 минут и так получилось что 6 раз подправляли для получения нужного результата - это уже получился час.

anc ★★★★★
()
Ответ на: комментарий от vinvlad

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

Прекрасная бизнес-задача, да. Генеральный их так и ставит вице-призиденту по ИТ: поитерируйте в баше, используйте значения строчек входного потока, увеличьте количество вызовов find.

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

muon ★★★★
()
Ответ на: комментарий от muon

Чего сказать-то хотели? Что PowerShell приживется со временем в Unix-подобных системах? )) Да додуматься до такого - портировать PowerShell в Linux - могли только совсем уж с упоротыми мозгами виндовозники. Странно, что они еще Registry не попытались портировать в Unix/Linux - все еще впереди )

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

Пока только пустая болтовня про «можно использовать значения строчек входного потока».

muon ★★★★
()
Ответ на: комментарий от muon

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

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

Шеллу не требуется тьюринг-полнота - шеллу требуется простота и лаконичность языка - причем, языка, рассчитанного не только на программистов и IT-шников, но и на конечного пользователя.

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)
Ответ на: комментарий от vinvlad

надо что-то поискать в куче файлов исходного кода чисто в режиме терминала или как-то их преобразовать

Во, появляется разумное зерно, без «использования строчек».

Осталось только придумать, какое нужно преобразование. Сдаётся мне, что скромное <some_command> обозначает нечто монструозное на sed или awk.

muon ★★★★
()
Ответ на: комментарий от muon

я вот не пойму: лично вас Bash чем не устраивает? Не в плане скриптинга, где можно использовать что угодно, а именно по части шелла? Вот меня он вполне устраивает - хотя бы потому, что по сравнению c PowerShell это образец красоты и лаконичности мышления. У вашего PowerShell-а «под капотом» столько всего накручено…

P.S. Насчет «упоротых» это я не вас лично имел в виду, а представителей мелкомягкой компании )

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)
Ответ на: комментарий от vinvlad

лично вас Bash чем не устраивает?

Синтаксис нелогичный и не запоминаемый.

На каждый жизненный случай предлагается дёргать стороннюю прогу с самобытными принципами работы.

Текстовый пайп.

muon ★★★★
()
Ответ на: комментарий от muon

Синтаксис нелогичный и не запоминаемый.

Вполне логичный - просто в Bash-е нет, как таковых, выражений - есть только команды, которые возвращают числовой код возврата. 0 - успешное выполнение (true). Не 0 - неудачное завершение (false). Выражение типа if [ ... ]; then ... - это просто синтаксический сахар выражения if test ... ; then ... - ну, т.е. сокращенная форма вызова встроенной команды test.
Ну и любой новый язык - «не запоминаемый». Уж PowerShell - точно )

На каждый жизненный случай предлагается дёргать стороннюю прогу

Так это его назначение!) Мы же сейчас обсуждаем свойства шелла, а не шелл-скриптинга. В этом его гибкость и живучесть. По мере жизни системы в неё просто добавляются новые полезные утилиты - полезные именно для шелл-действий. И я бы не сказал, что прям на каждый жизненный случай… Ввод-вывод есть (в том числе чтение строк файла в массив), регулярные выражения и разбор строки есть, работа со строчками есть, целочисленная арифметика есть, массивы есть… Ну уж для шелла вполне достаточно вроде. Чего не хватает-то?

Текстовый пайп

Ну пайп не обязательно текстовый - может быть любым. На выходе в переменную - это да, только текст. Чисто с двоичными данными внутри кода не поработаешь - нолик обрывает значение переменной. Здесь действительно требуются внешние проги. А это особо надо в шелле? - с двоичными данными-то работать? Это уж точно к скриптингу и к отдельным утилитам, а не к шеллу.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Нет никакого текущего шелла

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

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

abcq ★★
()
Ответ на: комментарий от vinvlad

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

До вас никак блин не дойдет, что предложения по улучшению шелл никак не отнимут у вас шелл в том виде что он есть сейчас, вы и дальше сможете делать те действия что делаете сейчас. Зачем вы эти действия противопоставляете улучшениям и развитию?

abcq ★★
()
Последнее исправление: abcq (всего исправлений: 1)
Ответ на: комментарий от abcq

Подавляющее большинство скриптов написано либо в синтаксисе bourne shell либо с расширениями bourne again shell,

Это только говорит о том, что эти «недоязыки» вполне достаточны и популярны для решения определенного круга задач. Хотя этот ваш аргумент относится к скриптингу, а не к шеллу как таковому.

А то, что никто за столько лет не дополнил чем-то новым комплект имеющихся шеллов, говорит только о том, что они неплохо справляются со своим назначением. Более того, даже Bash имеется далеко не везде. Во многие базовые Docker-образы его не включают - есть только sh. Кому требуется что-то экзотическое, просто делают свои базовые образы и работают на этом в своей команде. Так что, требование повсеместности для чего-то нового не так уж и актуально, как вам кажется.

вы тоже не побежали засылать пулл реквесты

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

я вот не пойму: лично вас Bash чем не устраивает? Не в плане скриптинга, где можно использовать что угодно, а именно по части шелла?

Осознайте уже, что нет никакого деления на shell и shell scripting shell представляет из себя интерактивную оболочку срощенную с интерпретатором убогого языка поверх нее. По сути это REPL решение своего рода.

хотя бы потому, что по сравнению c PowerShell это образец красоты и лаконичности мышления.

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

У вашего PowerShell-а «под капотом» столько всего накручено…

Обоснуйте это заявление, исходные тексты в паблике.

abcq ★★
()
Ответ на: комментарий от vinvlad

Так это его назначение!) Мы же сейчас обсуждаем свойства шелла, а не шелл-скриптинга.

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

abcq ★★
()
Ответ на: комментарий от abcq

Зачем вы эти действия противопоставляете улучшениям и развитию?

А я не противопоставляю - я просто пытаюсь доходчиво объяснить, что «шелл» и то, что принято называть «шелл скриптингом» - это разные вещи. Вот вспомните, с чего начался наш диалог - вы предложили сделать новый шелл на базе Lua ) Lua вполне подходит для «скриптинга» - и вроде никто не мешает им пользоваться. Но для базового языка шелла это вообще не вариант - придется менять синтаксис вызова функций, а это пардон…

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Это только говорит о том, что эти «недоязыки» вполне достаточны и популярны для решения определенного круга задач.

Максимум о чем это говорит, о том что так исторически сложилось и что люди инертны. Это просто подтверждает поговорку «из двух зол выбирают меньшее», вот люди и выбрали из вороха shell те которые еще хоть как-то сносные.

А то, что никто за столько лет не дополнил чем-то новым комплект имеющихся шеллов, говорит только о том, что они неплохо справляются со своим назначением.

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

Во многие базовые Docker-образы его не включают - есть только sh. Кому требуется что-то экзотическое, просто делают свои базовые образы и работают на этом в своей команде. Так что, требование повсеместности для чего-то нового не так уж и актуально, как вам кажется.

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

А меня все устраивает

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

abcq ★★
()
Ответ на: комментарий от vinvlad

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

abcq ★★
()
Ответ на: комментарий от abcq

… просто никто этого не будет делать т.к. это бы означало пошатнуть веру в юниксвей как подход.

Да нет никакой веры ) Если у вас есть, что предложить миру, просто вместо общих фраз напишите спецификацию нового шелла и отдайте этот конкретный документ на рассмотрение-обсуждение общественности. Может кто загорится идеей и подключится в плане реализации… А так, все эти разговоры вообще ни о чем.

Ситуация точно такая же как и с С в общем-то.

Да вы поди еще и ярый поклонник Rust-а? ) У меня соверешенно другое отношение к C.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Да нет никакой веры )

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

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

abcq ★★
()
Ответ на: комментарий от vinvlad

Вполне логичный - просто в Bash-е нет, как таковых, выражений - есть только команды

А [[ … ]] — это такой же синтаксический сахар, как и [ … ] ?

А чем отличаются ( … ), (( … )), $( … ) и $( … )$ ?

А почему при определении переменной противопоказан $ в начале её имени ?

И откуда вообще взялось ;; ? Два переноса строки подряд? Какой в этом [всём] смысл?

Так это его назначение!) Мы же сейчас обсуждаем свойства шелла, а не шелл-скриптинга.

Да, а если обсуждаем машину, то давайте не вспоминать про отсутствие кондиционера, это же не её предназначение. Такие рассуждения хороши для философского клуба, но не для работы. На практике при использовании posh один набор принципов для всего, а с bash чёрт ногу сломит.

Ну пайп не обязательно текстовый

Обязательно. Да, текст может быть структурированным (в XML, JSON или что-то ещё), но с учётом предыдущего пункта — на практике это почти не применяется.

muon ★★★★
()
Ответ на: комментарий от abcq

… но учитывая ваш код и ваши предложения по шелл коду я уже понял что вы звезд с неба не хватаете и пишете хрупкую лапшу, …

Да можете думать что угодно ))))))))))))

Я вот, например, думаю, что вы просто болтун и фантазер, не способный ни на что-то конкретное. Общение с вами наводит именно на такие мысли )

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

abcq ★★
()
Ответ на: комментарий от muon

А [[ … ]] — это такой же синтаксический сахар, как и [ … ] ?

Ну, в общем-то да - просто встроенная команда другая. Вы можете, например, написать в отдельной строчке [[ ... ]] && <другая команда>

А чем отличаются ( … ), (( … )), $( … ) и $( … )$ ?

(( … )) - это еще одна «встроенная команда» для целочисленной арифметики.

( … ) - это выполнение в sub-шелле - для кода внутри скобочек делается внутренний форк, и этот код не влияет на значения тех же переменных в родительском шелле. Он только возвращает код возврата, потребляет входной поток и возвращает выходной поток. Обычный Си-шный fork.

$( <команды> ) - это просто способ получения выходного потока выполняемых внутри команд:

MYVAR="$( < /etc/passwd )"
echo -e "This is /etc/passwd:\n$( cat /etc/passwd )"

$( … )$ - это не пользовал. Не знаю.

А почему при определении переменной противопоказан $ в начале её имени

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

И откуда вообще взялось ;; ?

Это в case-конструкции - вместо break )) Почему так, не знаю )))

… Обязательно. Да, текст может быть структурированным

НЕТ - не обязательно. Вы заблуждаетесь:

MYRANDOM="$( head -c 100 /dev/urandom | sha256sum -b | head -c 20 )"

Ну ё-моё, я чего тут препом нанимался чтоль? )))

vinvlad ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.