[python] Чудеса с os.system

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

А не лучше ли воспользоваться:
http://docs.python.org/library/tarfile.html
http://docs.python.org/library/hashlib.html
?

По поводу os.system, не могу сказать почему так.

os.system вообще-то deprecated, советуют юзать subprocess.

> PS Ошибка в интерпретаторе воспроизводится не всегда, но при запуске рабочей программы всегда;-(

У меня не воспроизводится (Python 2.7.1).

Это опять не понимание юниксов, о котором я уже устал тебе говорить.

Учись: $ python test.py 09bd5fe152cafcfecef418cd9ab56244 .sources.tar.gz

> непонимание

Почему бы тебе не сказать мне из-за не работает у ТС?

tar -Pczf .sources.tar.gz examples/osc2.py &> /dev/null; sleep .1; md5sum .sources.tar.gz

очевидный фикс. и да, это фича

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

это фича

Что ещё за фича? Файлы сразу появляются и видны для всех процессов.

> очевидный фикс.

sleep .1;

Это не «очевидный фикс», а очевидная бессмысленность и тормоза.

Вот и я о том же...

Не соблаговолит ли всемогущий и всезнающий Ктулху снизойти до жалкого червя вроде меня и объяснить с чем же это связано? Рассечь сиящум лучом своих глубочайших познаний беспросветную тьму моего невежества так сказать? С трепетом внимаю...

зачем перенаправлять в stdout/stderr в /dev/null? такое поведение связано именно с этим.

при перенаправлении ввода/вывода пистону сразу возвращается exit code и он считает что пора делать md5sum. ну это так ~кривое объяснение, гугли@узнавай

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

Объяснение сомнительное мягко говоря, питон про перенаправление вообще ничего не знает, он не парсит аргументы system. И все равно, когда все идет одной командой, решение что и когда делать принимает баш, а баш с такими конструкциями работает корректно. Кроме того, system должен вернуть КОД ЗАВЕРШЕНИЯ, т.е. вне зависимости от перенаправления он ждет завершения дочернего процесса.

Ну разбей на два вызова, дла tar и md5, проверь код выполнения tar, и между вызовами выполни os.stat('.sources.tar.gz') чтобы проверить что файл реально создаётся.

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

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

ЗЫ Если убрать &> /dev/null то работает.

вызывает дефолтный шелл

/bin/sh

Я думал на счёт багов шелла, но отмёл эту версию как нереальную. Оказалось нет :)

почему оно там не работает

Потому что для dash конструкция &>/dev/null означает запуск в фоне(в отличие от bash), замени на 2>/dev/null, а лучше доку почитай, вдруг и этот вариант неправильный :).

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

Я правильно понимаю что в bash оно «не всегда» означает «никогда»?

В чистом баше никогда. В интерпретаторе (питона, я может не точно выразился? я про интерактивный режим) через system - зависит от, напр. если один интерпретатор в фоне валяется то во втором как правило работает.

Потому что для dash конструкция &>/dev/null означает запуск в фоне(в отличие от bash), замени на 2>/dev/null, а лучше доку почитай, вдруг и этот вариант неправильный :).

Да, > /dev/null 2> /dev/null? т.е. ?> это башизЪм? Епрст, век живи, век учись, дуриком помрешь;-)

Спасибо большое!

только не ?> а &> ес-но, акела промахнулся

> т.е. &> это башизЪм

Да. Также как и |& и /dev/tcp/host/port и ряд других.

Да, > /dev/null 2> /dev/null?

Чаще используют идиому «>/dev/null 2>&1», которая корректна с точки зрения POSIX и не будет открывать файл дважды.