perl

устанешь все искать и все собирать(та же sed идёт отдельно, и её надо специально собирать под оффтоп. При этом оно получается жирным и неповоротливым - разгадка простая, если в GNU/Linux gnu-sed юзает всё из glibc и прочего gnu, то в венде приходится все велосипеды тащить с собой. В итоге имеем Over9000 утилит, _каждая_ из которых тащит _свой_ велосипед)

msys?

$ which sed
/bin/sed.exe

$ ls -lA /bin/sed
-rwxr-xr-x 1 Slava Администраторы 134144 Apr 14  2010 /bin/sed

все параметры тоже gnu-специфичные, даже слеши не в ту сторону

обрабатываются практически одинаково. Бывают загвоздки - но это надо очень постараться. Я не думаю, что в своих скриптах ТС с этим столкнётся.

в gnu все файлы двоичные, но вот в Win бывают ещё и текстовые. Т.к. bash'скрипты почти всегда работают с текстовыми файлами, то в венде получается не тот режим

Что-то даже никакой test-case на ум не приходит, где бы это могло вылезти.

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

Я не думаю, что ТС свои скрипты будет править в «Блокноте», а WordPad нормально определяет и работает с обоими типами текстовых файлов.

В связке mingw/msys конечно есть затыки (например фактически нет локали и всего, что с этим связано, но если нужна только переменная окружения - то пожалуйста :)) - но это ТС-у решать: что проще - слегка новое окружение или новый язык.

134144 Apr 14 2010 /bin/sed

не все йогурты одинаково полезны. Рискну предположить, что это какая-то не совсем gnu sed. (gnu sed примерно на 3/4 состоит из gnu-расширений).

обрабатываются практически одинаково. Бывают загвоздки - но это надо очень постараться. Я не думаю, что в своих скриптах ТС с этим столкнётся.

полно где.

$ echo ${S}
/usr/bin/bash
$ echo ${S%/*}
/usr/bin

$ echo ${S}
\usr\bin\bash
$ echo ${S%\*}
\usr\bin\bash

Что-то даже никакой test-case на ум не приходит, где бы это могло вылезти.

любой, где ты работаешь со строчками. Как известно, в gnu строчки всегда заканчиваются \n, а вот в венде либо \r\n для бинарных файлов, либо вообще никак для текстовых.

Я не думаю, что ТС свои скрипты будет править в «Блокноте», а WordPad нормально определяет и работает с обоими типами текстовых файлов.

WordPad тоже не оканчивает тексты символом \n, как и линуксовые редакторы (кроме vim'а).

В связке mingw/msys конечно есть затыки (например фактически нет локали и всего, что с этим связано, но если нужна только переменная окружения - то пожалуйста :)) - но это ТС-у решать: что проще - слегка новое окружение или новый язык.

лучше нормальный ЯП, чем кастрированное окружение. Особенно это касается shell, которое само по себе не нужно, там самое важное - именно окружение, как в переменных, так и в командах.

Рискну предположить, что это какая-то не совсем gnu sed. (gnu sed примерно на 3/4 состоит из gnu-расширений).

$ sed --version
GNU sed version 4.2.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
to the extent permitted by law.

GNU sed home page: <http://www.gnu.org/software/sed/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
E-mail bug reports to: <bug-gnu-utils@gnu.org>.
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.

полно где.

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

Как известно, в gnu строчки всегда заканчиваются \n, а вот в венде либо \r\n для бинарных файлов, либо вообще никак для текстовых.

Ещё раз - если не вылазить за пределы msys - с этим столкнуться трудно. У WordPad-а есть тип файлов UNIX-text, переводы строк обрабатываются корректно. Про последний перевод строки в файле - хз, но об этом можно и помнить.

лучше нормальный ЯП, чем кастрированное окружение.

Это ТС-у решать - стоит ли его задача изучения ещё одного языка или нет.

[xpahos] [~] # ruby --version ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0]

как бы

Пакетный менеджер убьётся от установки руби? Не думаю :} Уж доставить софт для себя ТС, я думаю, сумеет.

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

Cygwin, и даже портировать ничего не придется.

Ты, недоносок, никогда msys и cygwin не видел, да?

И scsh недоумок тоже не видел, да?

Как-то так.

http://www.cliki.net/CLISP-Shell

http://lush.sourceforge.net/doc.html

http://www.scsh.net/

на каждой машинке доставлять

Жрёшь что дают? Даже нужный софт не поставишь, если из коробки нет? Странный ты.

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

О которых ТС не упомянул. А то если бы да кабы да во рту росли грибы.

Вот и я про это же.

GNU sed version 4.2.1

ну я про то, что в сырцах sed Over9000 #ifdef'ов, на тему, «есть-ли у нас glibc?»

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

вот я и предлагаю передать параметры _один_ раз, и всякие сортировки, резки строк, и прочее делать средствами ЯП, а не костылями bash, которые только в линуксе удобные (да и то...).

Ещё раз - если не вылазить за пределы msys - с этим столкнуться трудно.

смыслв скрипте, который не вылазит за msys? Может тогда и вообще венда не нужна?

У WordPad-а есть тип файлов UNIX-text, переводы строк обрабатываются корректно. Про последний перевод строки в файле - хз, но об этом можно и помнить.

большинство линуксоидов-то об этом не знает...

Это ТС-у решать - стоит ли его задача изучения ещё одного языка или нет.

боюсь, что ТСу придётся узнать _очень_ многое про bash. Я вот например и не знал(точнее не задумывался), что звёздочку в ${VAR%...} можно и нужно экранировать бэкслешем - я просто ещё не сошёл с ума, что-бы создавать файлы со звёздочками в именах.

ЗЫЖ да, решать ТСу. Но я, помнится, в похожей задаче попросту забил на венду.

Ты, недоносок, никогда msys и cygwin не видел, да?

видел... В гробу я твой цигвин видел - мне LFS собрать проще и быстрее.

Можно установить Ruby и из пакетного менеджера дистрибутива.

Жрёшь что дают? Даже нужный софт не поставишь, если из коробки нет? Странный ты.

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

cygwin, gnuwin32, reed kotler tools и т.п.

Как-то так.

вот как-то так задроты предлагают юзать CL. Кусочик для Ъ:

(set-dispatch-macro-character #\# #\[
  #'(lambda (stream char1 char2)
      (setf (readtable-case *readtable*) :preserve)
      (UNWIND-PROTECT
       (LET* ((OUTPUT-STREAM (MAKE-STRING-OUTPUT-STREAM 
                                     :ELEMENT-TYPE 'BASE-CHAR))
	      (STEP1 (FORMAT OUTPUT-STREAM "(RUN-PROGRAM "))
	      (COMMAND-LINE (READ-DELIMITED-LIST #\] STREAM T))
	      (COMMAND (FIRST COMMAND-LINE))
	      (STEP2 (FORMAT OUTPUT-STREAM "\"~A\" 
                                     :ARGUMENTS " COMMAND))
	      (PARAMETERS (REST COMMAND-LINE))
	      (STEP3 (FORMAT OUTPUT-STREAM "'(")))
	     (DOLIST (X PARAMETERS
			(PROGN (FORMAT OUTPUT-STREAM "))")
			       (LET ((CLEAN 
                                      (GET-OUTPUT-STREAM-STRING 
                                               OUTPUT-STREAM)))
				    (CLOSE OUTPUT-STREAM)
				    (VALUES 
                                     (READ-FROM-STRING CLEAN)))))
		     (FORMAT OUTPUT-STREAM "\"~A\" " X)))
      (SETF (READTABLE-CASE *READTABLE*) :UPCASE))))

cygwin

Ну, перепеши этот кусок кода на баш. Я посмотрю.

Ну, перепеши этот кусок кода на баш. Я посмотрю.

этот кусок нужен, что-бы из CL сделать bash(точнее sh). А из bash'а bash делать не нужно, он уже готов для использования.

он уже готов для использования.

Пользуйся, кто ж мешает:

#! /bin/sh
# -*- Scheme -*-

## Emilio C. Lopes <eclig@gmx.net>, 2005-10-10

exec scsh -e main -s "$0" "$@"

!#

(define (grep-port regexp port printer)
  (do ((line (read-line port) (read-line port))
       (line-number 1 (+ line-number 1)))
      ((eof-object? line) 'done)
    (if (regexp-search? regexp line)
        (printer line-number line))))

(define (grep regexp file)
  (call-with-input-file file
    (lambda (port)
      (grep-port regexp port (lambda (lineno line) (format #t "~a:~a:~a~%" file lineno line))))))

(define (main prog+args)
  (let ((nargs (length (cdr prog+args))))
    (cond  
     ((= nargs 0)
      (error (format #f "scsh-grep: expecting one or more arguments, got ~a" nargs)))
     ((= nargs 1)
      (grep-port (posix-string->regexp (cadr prog+args))
                 (current-input-port)
                 (lambda (lineno line) (format #t "~a:~a~%" lineno line))))
     (else
      (for-each (lambda (file) (grep (posix-string->regexp (cadr prog+args)) file))
                (cddr prog+args))))))

А в кишки компилятора тебе для скриптования лезть не надо. Нафиг смотреть всякие ужосы?

понимаешь в чём фишка? Мне проще на CL написать, благо есть реализация под венду. Чем извращаться с конвертацией.

exec scsh -e main

Сударь, а что вы предлагаете для x86-64, надеюсь не недопорты.. Или сия платформа для маргиналов?

понимаешь в чём фишка?

Нет.

Мне проще на CL написать

Проще написать что?

Чем извращаться с конвертацией.

Какой конвертацией?

А вот х.з. как оно в генте работает. Но нареканий пока нет.

Надо писать скрипты на C! Глупости не пиши.

СОММОИ ЛNСП!

Очень смешно :)

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

Также поддерживаю идею реализации системы с нуля на современном ООП-языке, причем, если система нетривиальна, то имеет смысл уделить время проектированию. Что касается языка, Python выглядит неплохо. Отсутствие JIT и мелочи вроде self с лихвой покрывается общей «ладностью» языка, а также ящиком термоядерных батареек. Насчет Ruby ничего советовать не буду, дела с ним практически не имел, но, судя по-всему, там больше чистого хипстерства, нежели реальных бенефитов.

Добавлю вот еще что. Благодаря GObjectIntrospection, «ящик термоядерных батареек» в виде GLib теперь доступен для многих хороших языков. Среди них Vala, JavaScript и, кстати, Lua. В GLib есть многое для задачи топикстартера, в частности, обработка строк, regexp'ы и даже lexical scanner. Про GTK+ для интерфейса и так понятно. Все это вместе выглядит очень вкусно. Однако, придется повозиться, чтобы собрать это дело под винду.

И да, призываю не воспринимать всерьез укурочную клоунаду паясничающего в треде Ловсанчега :) Кстати, привет, Дим.

руби - нет. у него внешние привязки на си. много чего не соберется. nodejs бери. я его имхо ненавижу но тебе подходит

Надо писать скрипты на C! Глупости не пиши.

глупо тянуть руби из-за нескольких скриптов :)

Странно, что ТС не начал с выбора между python и ruby. Python - попса и кхм солидный тренд. Советую его.

Странно, что ТС не начал с выбора между python и ruby. Python - попса и кхм солидный тренд. Советую его.

Powershell не кроссплатформенный.

http://pash.sourceforge.net/

Глупо это писать на языке, на котором не можешь или который терпеть не можешь. А всё остальное это так, семечки :}

это будет странно звучать, но!
лично я (да хоть из чистого интереса) попробовал бы vim-script

полностью удовлетворяет:
+ «кроссплатформенный» - более чем, единственный редактор который есть на большом кол-ве платформ
+ «сам в себе» на 200%, ничего внешнего не нужно
+ «легко читаемый и простой в изучении» - трудно сказать, лучше попробовать чтоб понять для себя
+ поиск и другие операции с файлами
+ обработка текста: есть готовые понятия «строка», «слово», ... да и вообще всё что связано с обработкой текста очень и очень упрощено

Глупо это писать на языке, на котором не можешь или который терпеть не можешь. А всё остальное это так, семечки :}

а зачем тогда пишут на руби, если не могут?

обоснуй.

Это решение будет самым быстрым по отношению к остальным. Быстрым как в смысле программирования, так и в смысле производительности полученного кода. Потому что Лисп мощнее всех существующих языков, а по производительности не уступает Си.

Заодно расскажи (с примерами) как переписать скрипт bash на CL.

Реализовать bash DSL на Лиспе. Что непонятно-то? За примерами - в On Lisp Грэма.

Пошла демагогия, всё понятно :}

Это решение будет самым быстрым по отношению к остальным.

довольно самонадеянно.

Быстрым как в смысле программирования

4.2

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

Так и в смысле производительности полученного кода. Потому что Лисп мощнее всех существующих языков, а по производительности не уступает Си.

даже упёртые фанатики признают, что сишечка быстрее как минимум в три раза.

Реализовать bash DSL на Лиспе. Что непонятно-то?

т.е. костыль будет быстрее самого bash'а?

да не ведись ты... Анон толсто троллит лиспофобов - сейчас должны набежать ;)

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

Очевидно же, что Python

довольно самонадеянно.

Как бы sbcl заруливает по скорости всякие перлопитоны в минуса. Это факт. А про bash я и вовсем молчу.

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

Согласен.

сишечка быстрее как минимум в три раза.

Верно. Если приложение 90% времени вычисляет какую-то жестокую математику следует выбрать С или FORTRAN.

костыль будет быстрее самого bash'а?

Очень сложно не быть быстрее баша.

Очень сложно не быть быстрее баша.

Вопрос не просто «быстрее баша», а быстрее баша в многократном вызове других программ и перенаправлении потоков I/O. Вот здесь может быть засада, ибо баш может быть оптимизирован в этом плане, а у того-же sbcl вызов внешней проги и манипуляция потоками - не самые дешёвые операции

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

Также следует учесть, что шелл, в силу своей убогости (только не подумайте, что я его ругаю, в своей области он великолепен) практически всё делает через вызов внешних программ. Лиспу же просто не нужно вызывать sed/grep/awk на каждый чих.

Tcl/Tk

Tcl/Tk же. Нет ничего более кроссплатформенного , а так же более мощного и гибкого языка + тулкита искаропки.

Он более производительный нежели руби, имеет массу биндингов для системного программировани, учится с полпинка (я начал писать после одной ночи (около 5 часов) чтения минимального мануала. Встроенные средства меттапрограммирвоания дадут возможность делать вообще что угодно. Есть в любых дистрибал *nix, в BSD, MacOS, Шиndows...

Также следует учесть, что шелл, в силу своей убогости (только не подумайте, что я его ругаю, в своей области он великолепен) практически всё делает через вызов внешних программ. Лиспу же просто не нужно вызывать sed/grep/awk на каждый чих.

а ты первый пост читал? ну почитай - у ТСа УЖЕ есть скрипты на bash, которые на каждый чих вызывают sed/grep/awk. А ещё есть убогая ОС, в которой нет ни bash, ни sed, ни даже CL. Конечно, всё это можно поставить. А можно поставить только CL, и написать на нём Over9000 DSL для баша, седа и и прочего говна. Ты хорошо подумал?

Хватить жрать вещества. Tcl лучше. Он легковеснее, проще в освоении, чем CL, более читаемый (синтаксис - не похож на обрезанные ногти). С текстом работает лучше. В Tcl все есть строка изначально. Не список, а строка. Строка может разбиваться на что угодно. Но работа с текстом в tcl самая удобная. А с версией 8.6 язык вообще все эти ваши лиспы заруливает.

pure C

Он более производительный нежели руби, имеет массу биндингов для системного программировани, учится с полпинка (я начал писать после одной ночи (около 5 часов) чтения минимального мануала. Встроенные средства меттапрограммирвоания дадут возможность делать вообще что угодно. Есть в любых дистрибал *nix, в BSD, MacOS, Шиndows...

Хватить жрать вещества. C++/STL лучше. Он легковеснее, проще в освоении, чем CL, более читаемый (синтаксис - не похож на обрезанные ногти). С текстом работает лучше. В C++/STL все есть строка изначально. Не список, а строка. Строка может разбиваться на что угодно. Но работа с текстом в C++/STL самая удобная. А с версией c++11 язык вообще все эти ваши лиспы заруливает.

//fixed