strange redirection or piping problem

[irt_1]

We have two different behaviors for two different HPUX servers:

on DEV:
--------
dev@/home/user123> ll a.txt
-rw-r--r-- 1 user123 users 16385 Jul 16 13:20 a.txt
dev@/home/user123>
dev@/home/user123> cat a.txt | sort > a.txt
sort: Warning: A newline character was added to the end of the input.
dev@/home/user123> ll a.txt
-rw-r--r-- 1 user123 users 16385 Jul 16 13:20 a.txt
dev@/home/user123>

on PROD:
--------
prod@/home/user123> ll a.txt
-rw-r--r-- 1 user123 users 16385 Jul 16 13:20 a.txt
prod@/home/user123>
prod@/home/user123> cat a.txt | sort > a.txt
sort: Warning: A newline character was added to the end of the input.
prod@/home/user123> ll a.txt
-rw-r--r-- 1 user123 users 0 Jul 16 13:20 a.txt
prod@/home/user123>


As you can see on PROD the file became zero after the piping and redirection but not on DEV.

Is that any shell parameter net to set? What is the normal/default behaviour?

Thank you,

Iwan Tamimi

[Dennis Handly]

>What is the normal/default behaviour?

What you are doing is illegal for this exact reason, you can't read and write to the same file.
The first thing I thought of is for you to remove that evil cat(1).

But the correct fix is to use:
$ sort -o a.txt a.txt

[irt_1]

Thanks for the reply.

I believe so, it is illegal, but why in the dev system, I could do it.

The problem is some developer using this syntax on the dev system (but not pipe to sort but pipe to sed) and the script running fine, then after he migrated to prod them the problem come.

Yes I thought it is illegal command that can zero the file, I asked the developer to change the script, but I am curious for the inconsistency.

[Dennis Handly]

>but why in the dev system, I could do it?

It's illegal because it is inconsistent. ;-)

>but I am curious for the inconsistency.

I'm pretty sure the pipe buffer size is the same on all HP-UX systems. I would have thought it related to the size that you are reading before writing back. It could be related to the OS version and any patches you have.

[Peter Nikitka]

Hi Iwan,

I would not call it an inconsistency - the behaviour is just undetermined:
May be, there is a higher probability, that a multi-CPU machine shows a NULL-sized file, but a slow an single CPU. May be the other way round ...

mfG Peter

[Steven E. Protter]

Shalom,

Try and read and write to the same file at the same time, with say two separate processes.

Have the write process put in legible english words.

Think that's what the output is going to look like? No.

The reason Unix shell does not permit read and write of the same file at the same time is to give you some chance of having a consistent, usable file at the end of the day.

Accept this rule as fact and move on.

SEP