cat ./file | grep -v "222" > ./file непонимаю

Demimurych · Сообщение **Demimurych** » 12.04.2005 13:18

имеем файл file
cat ./file
111
222
333

Далее Делаем
cat ./file | grep -v "222"
111
333

Далее
cat ./file | grep -v "222" > ./file
cat ./file

Ответ пусто в файле ничего нет
ежели опять создать файл с тем же содрежимым и сделать так
cat ./file | grep -v "222" > ./file2
cat ./file2
111
333

то есть вроде бы верно
Берем другую машину
Делаем
cat ./file | grep -v "222" > ./file
сat ./file
111
333

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

Не дайти поехать крышей обьсните - куда рыть

Сообщение **t.t** » 12.04.2005 13:25

(Demimurych @ Вторник, 12 Апреля 2005, 12:18) писал(а):Иначе говоря на одно машине операция привела к одному результату на другой совершенно к другому

Не дайти поехать крышей обьсните - куда рыть
↑

Для начала в строну grep -V

Demimurych · Сообщение **Demimurych** » 12.04.2005 13:33

(t.t @ Вторник, 12 Апреля 2005, 12:25) писал(а):
(Demimurych @ Вторник, 12 Апреля 2005, 12:18) писал(а):Иначе говоря на одно машине операция привела к одному результату на другой совершенно к другому

Не дайти поехать крышей обьсните - куда рыть
↑
Для начала в строну grep -V

↑

Не годитсья
потому как во первых одни и таже ОС
Во творых
перд всеми операциями делаю проверку
cat ./file | grep -v "222"

п после потовряю
cat ./file | grep -v "222" > ./file

На одной машине получю один результат на вторйо второй

Сообщение **t.t** » 12.04.2005 13:45

(Demimurych @ Вторник, 12 Апреля 2005, 12:33) писал(а):Не годитсья
потому как во первых одни и таже ОС
↑

Так вы уверены, что версии грепа совпадают?

bogus · Сообщение **bogus** » 12.04.2005 14:50

Греп тут более-менее непричем, по-моему.
cat file | sed > file тоже дает непредсказуемый результат.
Насколько я понял, даже cat file | grep > another_file может давать непредсказуемый результат в некоторых случаях...

Сообщение **sash-kan** » 12.04.2005 14:59

по логике, от grep никак не зависит. возможно, от shell'а? от используемой fs? ведь при команде
cat ./file | grep ... > ./file
shell сначала должен произвести "усекновение" file'а.
почему этого не происходит во втором случае - великая загадка есть :)

Сообщение **t.t** » 12.04.2005 15:03

(Sash Kan @ Вторник, 12 Апреля 2005, 13:59) писал(а):по логике, от grep никак не зависит.
↑

Хм.. Логично. Что-то я сегодня плохо соображаю. Вообще-то, конечно, конвейеризация на такие варианты не расчитана.

(bogus @ Вторник, 12 Апреля 2005, 13:50) писал(а):Насколько я понял, даже cat file | grep > another_file может давать непредсказуемый результат в некоторых случаях...
↑

А вот это почему?

JaGoTerr · Сообщение **JaGoTerr** » 12.04.2005 15:31

Да ну вы что, господа, при чём же тут grep. Смешно даже. Причина ВОЗМОЖНО в оболочке. Вплоть до её версии, а также режима запуска (возможно где-то она запущена как login-shell, следовательно в режиме совместимости с sh/csh, а где-то нет). От ФС... ну фиг знает... не исключено.

Я вот только что проверил на:

Линукс + reiserfs 3:
bash 3.00.15, tcsh 6.13.00, zsh 4.2.1 - результат нормальный (на выходе file1 непуст).

Соляра 9 + ufs ( а что же ещё

):
tcsh 6.10.00, bash 2.05.0 - результат хреновый (file1 пуст).

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

bogus · Сообщение **bogus** » 12.04.2005 15:36

(t.t @ Вторник, 12 Апреля 2005, 14:03) писал(а):
(bogus @ Вторник, 12 Апреля 2005, 13:50) писал(а):Насколько я понял, даже cat file | grep > another_file может давать непредсказуемый результат в некоторых случаях...
↑
А вот это почему?

↑

Точно не разбирался, т.к. у меня это работает нормально. могу лишь процитировать из bbs.archlinux.org:

I'd recommend changing your sed line in your PKGBUILD. I ran into a nasty race condition on a HT system with a PKGBUILD that did something like what you've got. Rather than 'cat | sed > output', just use sed with the -i argument and copy the file over

этот комментарий относился к строке

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

 cat $startdir/system.mk | sed "s#ROOT=DUMMY#ROOT=$startdir/pkg#" > $startdir/src/ion-3ds-$pkgver/system.mk

bogus добавил в 12.04.2005 15:36

правда, возможно это относится именно к sed'у...

Demimurych · Сообщение **Demimurych** » 12.04.2005 16:58

повторяю.
Две совершенно одинаковые системы.
Разница небольшая в железе

JaGoTerr · Сообщение **JaGoTerr** » 12.04.2005 17:06

(Demimurych @ Вторник, 12 Апреля 2005, 15:58) писал(а):повторяю.
Две совершенно одинаковые системы.
Разница небольшая в железе

↑

Если системы одинаковые, а ведут себя по-разному, значит они неодинаковые.
Значит ты не всё проверил или не всё о них знаешь (а всё о них никто не знает).

madskull · Сообщение **madskull** » 12.04.2005 17:09

А насколько "одинаковые" системы? Может, размер памяти разный, может, буфера забиты/сброшены. А может дождь за окном?
Короче, и на одной системе в разное время можно получить разные результаты. Почему? Не знаю.
Но зависимость размера файла от вероятности его потери - прямо пропорциональна.

В общем, не делайте так

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

rulix · Сообщение **rulix** » 12.04.2005 17:38

Команда ">" обнуляет файл, в который перенаправляется вывод. Если из file перенаправлять в file, то он будет пустой.

xorader · Сообщение **xorader** » 12.04.2005 17:59

:megalol: :megalol: :megalol: :megalol:
потестируй просто cat file > file
Совет: не используй такую реализацию никогда! Реализации оболочек разные: некторые сначала открывают новый file (соотв-о inode и данные старые удаляются - файл пустой), некоторые сначала старый файл открывают (в результате с данными всё впорядке, так как дескриптор открыт и данные сохраняются пока он существует).

P.S. знаете зачем бегемоту большие круглые ступни ?

Сообщение **sash-kan** » 12.04.2005 19:14

Для JaGoTerr: поведение, когда при записи через ">" файл не усекается _до_ начала работы конвейера - как раз _ненормальное_

Sash Kan добавил в 12.04.2005 19:09

(Demimurych @ Вторник, 12 Апреля 2005, 15:58) писал(а):повторяю.
Две совершенно одинаковые системы.
Разница небольшая в железе

↑

и cat одной версии?

Sash Kan добавил в 12.04.2005 19:14

только что проверил на трех _совершенно_ разных машин (разные ядра, shell-ы, версии cat).
везде поведение _нормальное_. file - пуст.
проверил еще на одной (freebsd 4.8, больше ничего узнать не удалось) - поведение _ненормальное_.

madskull · Сообщение **madskull** » 12.04.2005 22:09

(xorader @ Вторник, 12 Апреля 2005, 16:59) писал(а):P.S. знаете зачем бегемоту большие круглые ступни ?

↑

Ну, не томи...

nercus · Сообщение **nercus** » 13.04.2005 01:21

The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition

2. Shell Command Language
......
2.7.2 Redirecting Output
......
If the file does not exist, it shall be created; otherwise, it shall be truncated to be an empty file after being opened.

Стандарт аднака.

Сообщение **t.t** » 13.04.2005 12:59

(madskull @ Вторник, 12 Апреля 2005, 21:09) писал(а):
(xorader @ Вторник, 12 Апреля 2005, 16:59) писал(а):P.S. знаете зачем бегемоту большие круглые ступни ?
↑
Ну, не томи...
↑

Чтобы не проваливаться в маленькие квадратные ямы. Я ещё пару таких загадок знаю. Давать?

JaGoTerr · Сообщение **JaGoTerr** » 13.04.2005 13:23

(Sash Kan @ Вторник, 12 Апреля 2005, 18:14) писал(а):Для JaGoTerr: поведение, когда при записи через ">" файл не усекается _до_ начала работы конвейера - как раз _ненормальное_

↑

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

(Sash Kan @ Вторник, 12 Апреля 2005, 18:14) писал(а):только что проверил на трех _совершенно_ разных машин (разные ядра, shell-ы, версии cat).
везде поведение _нормальное_. file - пуст.
проверил еще на одной (freebsd 4.8, больше ничего узнать не удалось) - поведение _ненормальное_.

↑

Вот я проверил - так из моего поста сразу это видно. Ибо написано на чём, как и каковы результаты. А фраза "проверил, везде вот эдак", честно говоря, не внушает доверия. Хотелось бы фактов! :yes:

xorader · Сообщение **xorader** » 13.04.2005 13:58

(t.t @ Среда, 13 Апреля 2005, 11:59) писал(а):
(madskull @ Вторник, 12 Апреля 2005, 21:09) писал(а):
(xorader @ Вторник, 12 Апреля 2005, 16:59) писал(а):P.S. знаете зачем бегемоту большие круглые ступни ?
↑
Ну, не томи...
↑
Чтобы не проваливаться в маленькие квадратные ямы. Я ещё пару таких загадок знаю. Давать?

↑

Не угадал.. "что бы с кувшинки на кувшинку грациозно так *шлёп-шлёп*"

Сообщение **t.t** » 13.04.2005 14:45

(xorader @ Среда, 13 Апреля 2005, 12:58) писал(а):Не угадал.. "что бы с кувшинки на кувшинку грациозно так *шлёп-шлёп*"
↑

Тоже вариант

Сообщение **sash-kan** » 13.04.2005 16:07

(JaGoTerr @ Среда, 13 Апреля 2005, 12:23) писал(а):Под "нормальный" в данном случае понималось скорее "желаемый" или как-то так. В общем, не придирайся к словам ;)

больше не буду :)

(JaGoTerr @ Среда, 13 Апреля 2005, 12:23) писал(а):Вот я проверил - так из моего поста сразу это видно. Ибо написано на чём, как и каковы результаты. А фраза "проверил, везде вот эдак", честно говоря, не внушает доверия. Хотелось бы фактов! :yes:

↑

подробный сбор фактов открыл новые горизонты:

нормально себя ведут:
bash version 2.05b.0(1) под fc1 и debian sarge (каюсь - написал, что разные версии, на поверку оказалась одна)
zsh 4.0.7 под fc1 (вообще выдал ошибку zsh: file exists: file)
ash (неизвестной версии, на -v и --version не реагирует) из leaf bering uclibc

ненормально ведут себя:
tcsh 6.12.00 под fc1
tcsh 6.13.00 под debian sarge
zsh 4.2.1 под debian sarge

другие shell'ы тестировать было лень. думаю, и этого хватит с головой.
вот такие получаются пироги с котятами.
ау! стандарты! где вы!? молчат :))

nercus · Сообщение **nercus** » 13.04.2005 20:07

(Sash Kan @ Среда, 13 Апреля 2005, 15:07) писал(а):ау! стандарты! где вы!? молчат )

↑

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

Сообщение **sash-kan** » 13.04.2005 20:59

(nercus @ Среда, 13 Апреля 2005, 19:07) писал(а):
(Sash Kan @ Среда, 13 Апреля 2005, 15:07) писал(а):ау! стандарты! где вы!? молчат )

↑

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

↑

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

Сообщение **ddc** » 13.04.2005 21:03

Для Sash Kan:
Ну это как всегда, пока не на все стандарты клал - не мужчина.

Кстати, может кто в курсе, Linux собирается становиться UNIX2000-compatible?

Golden · Сообщение **Golden** » 14.04.2005 20:04

(czarker @ Среда, 13 Апреля 2005, 20:03) писал(а):Кстати, может кто в курсе, Linux собирается становиться UNIX2000-compatible?

↑

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

alphex_kaanoken · Сообщение **alphex_kaanoken** » 15.04.2005 00:30

по логике результат с один и тем же файлом не предсказуем
то есть когда
cat file | grep "foo" > file
ты открываешь поток - через pipe прогоняешь его и в тот же поток пихаешь, логикой думать надо - что будет если cat файл не закрыл а вывод уже сделан в файл - как там насчет позиционирования текущего в файле?
поэтому корректней - будет везде работать
cat file | grep "foo" > file_tmp && mv file_temp file
если тебе надо тоже имя сохранить.
От фс и железа в твоем случае ну никак не зависит.

alphex_kaanoken добавил в 15.04.2005 00:30

2rulix - это верно, но опять думаем - сделай >> что будет ?

и корректнее сказать не "обнуляет" а открывает файл только на запись.

Сообщение **ddc** » 15.04.2005 00:30

Для Golden:
Спецификация такая была, сейчас только AIX признана соответвующей ей. Подробней не знаю.

Сообщение **t.t** » 15.04.2005 13:28

(alphex_kaanoken @ Четверг, 14 Апреля 2005, 23:30) писал(а):и корректнее сказать не "обнуляет" а открывает файл только на запись.
↑

Да я посмотрю, вы (уж простите) -- придираст...

alphex_kaanoken · Сообщение **alphex_kaanoken** » 15.04.2005 19:11

нет я просто люблю когда все нзывают своими именами =)
и не придирка это а дотошность.

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

Могу завести дискуссию - по поводу различных реализаций и как и в каких случаях правлиьней делать.

Я не кричу кстати что умнее всех - в одном я меньше знаю в другом больше - понять думаю это не сложно ?

unixforum.org

cat ./file | grep -v "222" > ./file непонимаю

cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю

Re: cat ./file | grep -v "222" > ./file непонимаю