Кто идет на Unix-way (или пользователь Linux - кто он)

[Goodvin]

Если текстовый файл — не аргумент, то почему ls в командной строке — не программа, а тот же ls, записанный в файле — программа?

Потому, что:
- атрибут eXecute у такого файла стоит
- потому, что вашему ls ПРЕДШЕСТВУЕТ указание имени интерпретатора. Например, им вполне может быть python или любой другой интерпретатор!

У меня в домашнем каталоге вообще запрещены исполняемые файлы (в частности, из запуск) по ряду причин.
И в моих скриптах нет ни указания имени интерпретатора, ни исполняемого атрибута у файла.
И, тем не менее, они прекрасно работают.

Не уж то это не понятно?

Купите уже учебник русского языка и/или включите в браузере проверку орфографии.
Постоянно коробит от прочтения Ваших безграмотных сентенций.
Даже безотносительно обсуждаемого вопроса про unix-way.

[Boboms]

<b>4.</b> GUI - это GUI. Это просто библиотека для отображения информации по-пиксельно. А не по-символьно. Только и всего.

Пропустил
http://en.wikipedia.org/wiki/Graphical_user_interface

[t.t]

Кстати. Не могу понять, что уважаемый t.t хочет доказать, требуя от меня код на Pascal/Basic, аналогичный приведенному господином diesel?

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

[Goodvin]

Господи, какая же оголтелая демагогия.

Можно немного подробнее? С чем вы не согласны?

Я не согласен с демагогией, с применением демагогических методов ведения "разговора".
Как именно - это ясно видно почти в каждом предложении "гражданина соврамши" (назову его так с позволения t.t, если он не против).

[drBatty]

У меня в домашнем каталоге вообще запрещены исполняемые файлы (в частности, из запуск) по ряду причин.
И в моих скриптах нет ни указания имени интерпретатора, ни исполняемого атрибута у файла.
И, тем не менее, они прекрасно работают.

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

Я не согласен с демагогией, с применением демагогических методов ведения "разговора".
Как именно - это ясно видно почти в каждом предложении "гражданина соврамши" (назову его так с позволения t.t).

угу. понял. ИМХО вы слишком категоричны, хотя в целом - правы

[YUKLA]

Дык - я то пытался и пытаюсь доказать, что на шелле именно программируют! И что шелл-скрипт - инструмент программиста.

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

Вот и славно. Никаких возражений не имею.

Давайте этот вывод зафиксируем и дальше будем отталкиваться от него.

Кстати. Не могу понять, что уважаемый t.t хочет доказать, требуя от меня код на Pascal/Basic, аналогичный приведенному господином diesel?

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

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

Как-то так.

[Boboms]

2 Yukla 

А вы, для разнообразия, постарайтесь всё-таки писнуть по существу вопроса, а не только, что ГУЙ - это попиксельная библиотека.

[t.t]

Кстати. Не могу понять, что уважаемый t.t хочет доказать, требуя от меня код на Pascal/Basic, аналогичный приведенному господином diesel?

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

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

Как-то так.

Я Вас экзамены сдавать и не заставляю. Давайте уберём последнюю фразу, раз она Вам так не понравилась, и оставим основное:

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

[sash-kan]

вот, кстати, прекрасная иллюстрация того, насколько (сравнительно) неоптимально задачу можно решить, если не применять unix-way: http://takeworld.blogspot.com/2009/11/vkontakte-500.html

почувствуйте разницу:

Shell

$ LANG=C sed 's/.*remixpass=\([^;]\{32\}\).*$/\1/;ta;d;:a' 500k.txt | sort \ | tee pass_sorted | uniq -c | tee pass_uniq | sort -rn | head -n 10 $ wc -l pass_sorted pass_uniq

эти две команды функционально эквивалетны всему тому коду, который можно найти на приведённой страничке.
да, sed медленнее вытаскивает пароли. соотношение времени «только sed» против «только extract.py» — ~минута против ~7сек. но ввиду «одноразовости» задачи у unix-way явное подавляющее преимущество по времени, требующемуся на написание кода. просто сравните количество знаков (улыбка).

p.s. к слову: видимо, из-за программисткой ошибки, примерно 2.5% записей автор блога на первом этапе «потерял». это просто к слову.

p.p.s. к слову-2: время, затрачиваемое sed-ом, кстати, вполне можно сократить (в идеале — до того же десятка секунд).
например, замена sed на awk (с его дка) или perl (с его ленивыми квантификаторами), — явно должна помочь. потому что проблема именно в жадных sed-овских квантификаторах.
но это уж совершенно другая история, к обсуждаемым вопросам не относящаяся.

[Voral]

Долго не отвечал - времени не было.

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

Примеры можно? С указанием области задач, конечно.

По скорости. в моем случае. Любой пример. Т.к. я в написании скриптов на шелле не очень силен. Например
Нужно выполнить некую последовательность действий. (Да хоть резервное копирование). Но в поределенный день недели все тоже самое с определенным отличием... Прочие равные команды оставляем в покое. Только обработку отличия. Для примера вывод разного сообщения.
шелл

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

if [ `date "+%w"` = 4 ]; then echo "Yes"; else echo "No"; fi;

php

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

 if (date('w')==4) echo "Yes"; else echo "No";

или так

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

 echo (date('w')==4) ? "Yes" : "No";

Написание скрипта(ов) на php (его писал сразу в чистовую сюда) заняло меньше минуты, на шелловском полчаса разбирался (в основном не сразу осознал как засунуть вытаскивание дня недели в условие)..... Естественно при одинаковом уровне знание время потребуется одинаково.
Но чем отличается перый код от второго?
Ну, а третий код вообще красавец (правда к исходной задаче менее всего применим).... Ну место echo можно было поставить удаление файла

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

rm /home/file.log

и

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

unlink('/home/file.log');

ну а примеры языков....
Тот же в 1Ске, RSBank (вообще практически Си только с фишками примерно как в 1C [кстати, в качестве прикола, можно и на русском писать ])
А всевозможные контроллеры?

В чем особо отличие написания:

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

Command1 > Command2 > Command3

И

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

Command3(Command2(Command1()));

И еще немного из сишного.

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

cin >>y;
cin >>x;
cout << "The average of the two numbers is: " << (x + y)/2.0 << endl;

qDebug() << "Hello";

[drBatty]

sash-kan

UPD: Исправлен косяк, спасибо sash-kan

фигасе...

[diesel]

Voral Вы все правильно говорите. Я там где-то выше писал: пример который Вы привели с датой - это пример который может быть написан и на shell, и на php, и никакой особенной разницы не будет - логика одна и та же, немного другой синтаксис, но who cares, если синтаксис знаком.

Command3(Command2(Command1())) - это хороший стиль. Не везде так умеют. Он предполагает, что:
1. На вход CommandХ() подаются данные в том виде, в котором CommandХ их ожидает
2. CommandХ() может: или выплюнуть результат обработки, или выплюнуть ошибку
3. В идеале CommandХ не зависит от своих предыдущих состояний

Тогда это легко транслируется в Command1() | Command2 | Command3(), потому как эти три пункта де-факто можно найти и в описаниях unix-way.

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

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

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

Синтаксис Command3(Command2(Command1))) может быть удобен для текстового редактора, но для ввода в терминале лучше чтобы первым набиралась та часть которая будет исполняться первой. Ну то есть как раз Command1 | .....

И мы получаем простенький shell. Далее нужны соответствующие CommandX, куда же без них, которые следуют соглашениям, и удобства ввода команд(история, редактирование и так далее).

[Voral]

Ибо разница между C/C++ и маш. кодами куда незначительней, чем между sh и C/C++.

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

Разница между Си И sh:
- На sh наиболее часто используемые алгоритмы (в среде задач в которых используется sh) уже реализованы и предоставляются в виде команд

Естественно все 3 отличаются синтаксисом, системами взаимодействия между отдельными командами....

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

[Voral]

Синтаксис Command3(Command2(Command1))) может быть удобен для текстового редактора, но для ввода в терминале лучше чтобы первым набиралась та часть которая будет исполняться первой. Ну то есть как раз Command1 | .....

Как я уже показывал в Си можно написать так cout << "Some text". В данной строке << это всего лишь последовательность символов действие которой можно переопределить. Точно так же как и стандартными средствами компилятроа можно извратитсья и назначить "|", ">" определенный смысл..... И тогда вполне нормальной будет запись Command1 > Command2.....

Далее. Про ожидаемый тип данных..... В sh это тип текст. И точка. Что мешает сделать функцию (только это лишнее) которая будет принимать и выдавать текст?

И мы получаем простенький shell. Далее нужны соответствующие CommandX, куда же без них, которые следуют соглашениям, и удобства ввода команд(история, редактирование и так далее).

Именно так. Т.е. максимально автоматизируются наиболее типичные действия пользователя.

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

С этим я полностью согласен.

[drBatty]

p.p.s. к слову-2: время, затрачиваемое sed-ом, кстати, вполне можно сократить (в идеале — до того же десятка секунд).

да. причём код этот НЕ на sed. а на sed+...

например, замена sed на awk (с его дка) или perl (с его ленивыми квантификаторами), — явно должна помочь. потому что проблема именно в жадных sed-овских квантификаторах.

нет. жадные квантификаторы экономят кучу времени.

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

разбор полётов продолжить в другой теме?

$ LANG=C sed 's/.*remixpass=\([^;]\{32\}\).*$/\1/;ta;d;:a' 500k.txt | sort \
| tee pass_sorted | uniq -c | tee pass_uniq | sort -rn | head -n 10
$ wc -l pass_sorted pass_uniq

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

[watashiwa_daredeska]

В чем особо отличие написания:

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

Command1 > Command2 > Command3

И

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

Command3(Command2(Command1()));

Для этого частного случая — ни в чем, кроме нелогичности, для непрограммиста, записи действий в обратном порядке (об этом уже diesel сказал).

Однако, шелл далеко не ограничивается этим простым случаем. Перенаправлять можно не только стандарный вывод, но и стандартный поток ошибок. Их можно не только перенаправлять, но и объединять в один. stdout и stderr — результат работы, но есть еще exit code, который показывает успешность завершения. Аргументом «функции» является не только stdin, но аргументы командной строки.

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

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

find $(cat dirs.txt) -type f | xargs grep -F "$(tr x y <patterns.txt)"

Кроме того, в самом пайплайне можно задействовать дескрипторы за пределами std{in,out,err}:

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

# Функция-пример, производит строки вида:
# 1-out
# 1-err
# 2-out
# 2-err
# ...
# Строки -out -- на stdout, строки -err -- на stderr
sample1() { for i in $(seq ${1:-4}); do echo ${i}-out; echo ${i}-err >&2; done }

# Берём строки с нечетными номерами с stdout, строки с четными номерами с stderr.
# Относительный порядок строк сохраняется.
(sample1 20 > >(egrep '[13579]-' >&3) 2> >(egrep '[02468]-' >&3)) 3>&1

[Voral]

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

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


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

[diesel]

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

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

Тут вопрос не столько в том "можно или нельзя" - bash на C написан, большая часть утилит написана на С, те которые не написаны на С имеют интерпретаторы, написанные на С, конечно же в конце-концов этот функционал можно реализовать на С, так или иначе. А поскольку речь идет о конкретной задаче, то интерпретатор awk на макросах переписывать не нужно . Вопрос в том "а зачем это делать"? Есть готовый инструмент, который позволяет решить задачу быстрее. Будете пытаться превратить C в такой инструмент - ну получите еще один shell, или еще один скриптовый язык, с очередным ворохом, удобных, по Вашему мнению(как создателя) умолчаний и соглашений.

Вот тут вы уже пытаетесь эти умолчания и соглашения придумывать:

Синтаксис Command3(Command2(Command1))) может быть удобен для текстового редактора, но для ввода в терминале лучше чтобы первым набиралась та часть которая будет исполняться первой. Ну то есть как раз Command1 | .....

Как я уже показывал в Си можно написать так cout << "Some text". В данной строке << это всего лишь последовательность символов действие которой можно переопределить. Точно так же как и стандартными средствами компилятроа можно извратитсья и назначить "|", ">" определенный смысл..... И тогда вполне нормальной будет запись Command1 > Command2.....

Далее. Про ожидаемый тип данных..... В sh это тип текст. И точка. Что мешает сделать функцию (только это лишнее) которая будет принимать и выдавать текст?

[Voral]

Вот тут вы уже пытаетесь эти умолчания и соглашения придумывать:

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

А поскольку речь идет о конкретной задаче, то интерпретатор awk на макросах переписывать не нужно smile.gif. Вопрос в том "а зачем это делать"? Есть готовый инструмент, который позволяет решить задачу быстрее

Поставьте на место awk любую команду любого языка программирования и она будет абсолютно верно. Согласитесь даже x + y в машинных кодах выглядит не так "красиво" (да даже на asm'e) для человеческого глаза..... Ведь вам потребуется кроме сложения еще и с памятью поработать.....

[diesel]

Вот тут вы уже пытаетесь эти умолчания и соглашения придумывать:

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

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

[Voral]

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

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

Я думаю это всего лишь уровень упрощения....

[watashiwa_daredeska]

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

Не такая уж она и огромная. Логика у них абсолютно одинаковая. Фактически, C->маш. код можно переводить практически с помощью элементарных подстановок aka макросов, надо только словарик при переводе держать для маппинга имен в адреса. Итого, логически, C == маш. код с точностью до замены. С C++ да, погорячился: у него тьюринг-полные template'ы, хотя и появились они в таком виде далеко не сразу.

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

И что с того?

Т.е. если сравнивать си и асм. То си это не программирование получается.....

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

Вы это пытаетесь нам доказать?

[Ali1]

2 ALL
Да что вы все sell c Си или asm`ом сравниваете?
Сравните bash и jcl .

[Boboms]

2 All
А, главное, зачем?

[Voral]

С C++ да, погорячился: у него тьюринг-полные template'ы, хотя и появились они в таком виде далеко не сразу.

Ну так разница большая?

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

printf("My text %s","tt");

Это на Си (кстати не плюсы)...........
Я не уверен в "просототе" машкода.

И что с того?
....
Вы это пытаетесь нам доказать?

я всего лишь пытаюсь выяснить по какому признаку (или признакам) написание скриптов на sh не является программированием. Все приводимые обоснования можно применить и к другим "парам" языков. А пока что строка

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

find $(cat dirs.txt) -type f | xargs grep -F "$(tr x y <patterns.txt)"

является вполне закоженым алгоритмом. Если, честно, пока не разбирался, что она делает. Но не сомнено здесь задан алгоритм получения нужного результата. Это не одна команда. Как я уже говорил я, если не придерживатся четких определений и понятий, думаю что одна команда это не "программирование" при чем на любом языке, т.к. вы конкретно говорите/указываете что хотите получить.
Здесь же вы именно объясняете, задаете план действий (прошу прощения если я не правильно трактую строку):
1. Прочитать из файла
2. Найти для каждой строки
......
....

А что это такое если не программирование действий?

[diesel]

Я думаю это всего лишь уровень упрощения....

А вот это разве не упрощение:

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

ЗЫ: Если в фразе "программирование без программирования" вас смущает третье слово... "программирование без лишнего кодинга" - так будет понятнее?

[Portnov]

Да всё просто. Имеется ввиду "программирование, доступное не-программисту". Учёный там или сисадмин не станет на C писать (без крайней необходимости, по крайней мере). А на shell - вполне вероятно.

[Voral]

ЗЫ: Если в фразе "программирование без программирования" вас смущает третье слово... "программирование без лишнего кодинга" - так будет понятнее?

Именно так я это и понимаю. И позволю вернуться к машу коду и c. По сравнению с машкодом Си это "программирование без лишнего кодинга", а Си++ еще больше "программирование без лишнего кодинга"...... А если я заранее заготовлю свою библиотеку..... еще больше "программирование без лишнего кодинга"

Но как ни крути "программирование"

Да всё просто. Имеется ввиду "программирование, доступное не-программисту". Учёный там или сисадмин не станет на C писать (без крайней необходимости, по крайней мере). А на shell - вполне вероятно.

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

[Boboms]

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

Если он освоил турбо бейсик, то с шелом у него тоже проблем не будет. Если с 0, то нужна книжка, а не справочник.

[Voral]

Если он освоил турбо бейсик, то с шелом у него тоже проблем не будет.

Равно как и в обратную сторону. Согласитесь зная шел, но не имея ни какой справочной информации про бейсик ни чего не получится (и наоборот).....