Ok, I think the -i option always writes to file, regardless of changes made or not.
Another point is, I think you do not 100% understand how your script works. Here is what happens:
The first line of the file is read into sed's pattern space. The command '1h' copies this line into the hold space. Since the conditions '1!' (not line 1) and '$' (last line) do not apply nothing else happens. Your hold space looks like this now:
line 1\n
Then sed reads the next line into pattern space.
Now since this is not line 1 and not the last line only the command '1! H' is executed, which appends the line to the hold space. Now your hold space looks like this:
line 1\nline 2\n
On the last line the conditions '1! H' and '$' are true; it is not line one, so append it to the hold space and since it is the last line execute the commands that follow in the block '$ {...}'. Your hold space now looks like this:
line 1\nline 2\n ... line 23\n
Now the 'g' command in '$ {g;...} simply copies the hold space into the pattern space. So now your pattern space looks like this:
line 1\nline 2\n ... line 23\n
And this is the line the 's' command operates on. As I said earlier, you loaded the complete file into one single line.

So when you say
that is not true, unless your file only consists of this three lines
title Mandriva
kernel blabla
initrd blabla

Your "block of one line" looks probably like this:
"title linux\nkernel blabla\ninitrd blabla\ntitle Mandriva\nkernel blabla\ninitrd blabla\ntitle SuSe\nkernel blabla\ninitrd blabla\n..."

So since sed works only on lines - and in the end you only edit one huge line - there is no way to optimize this, even if it were possible to somehow tell sed not to write unchanged lines.

Not. This is not whole file. This is just one item in array to search. There are next items to search. Total 23.

I we speak about file, we speak about much more longer file, which has about 23 blocks/item. But for me is not important what is in file but what is in array that keeps the items to find.


You described how sed reads line by line. I don't understand if does it read whole file to hold space or just the part to search.

The search part (search pattern) is only one line. But the block of lines in the file are one three lines or more.

My 2 cents here is that unless the file is thousands of lines long (which I am guessing menu.lst is not) then the conversation about
optimizing further is pretty much redundant.

Ultimately my question to you webhope is, does the sed script do what is required??

This question has no sense. Problem is that see this script separately. You don't see the script in global view as just one part in much more bigger script. When a programmer does a script he has two goals. 1. make it working 2. make is working well (that is effectively)

The effectivity here is very important because it is in a loop. And I really see as nonsense if man have to wait e.g. 5 seconds, even if I made just one little change on one block. This is strange. In real the time should be less then 1 second. If there would be more edited menu item, like 10 or 20 then it is ok, time should be about 5-8 second. The thing that unsettles me is the fact, that even if I made only 1 change in one menu item, then it will save 23 times. I think this means increment of unreliability also.

Is there some simple way how to solve the problem of nonsense/useless writing to file?

Could we use the w command for sed and :goto ?

Edit:
Original question at begining of this topic was related to problem of the ineffective behavior of sed write. Therefor even if the script you gave me works, it didn't solve my problem which is ineffectiveness of my original script. The ineffectiveness is caused by the fact, that in some occasions it is useless to save/write.

If you have loops performing tasks that take between 5-8 seconds to process a file of less than 200 lines, i think you have much bigger issues then
whether or not sed is being effective or not.

As I have worked with you on a number of the pieces of this project of yours I am well aware that it is to you a large project (where to me large would imply
somewhere in the order of 100,000+ lines of code). None of the solutions I have presented you with previously run for more than a portion of a second. So as
above, if you are seeing interactions in the order of 5 seconds, you really need to reconsider what you are doing as something else would need to
be the ineffective part knowing how small the original file is.

Nothing that you have put forward so far has indicated that sed is being ineffective.

Does it do the job the way YOU would like it done, maybe not, but this is far from making sed ineffective.
The fact that script does work, means that the ineffectiveness is your perception.

I believe your true question should no be around ineffectiveness, but more whether sed, or another program, can do the task you want.

The best solution I can probably provide is that you read your file in a line at a time in bash and then check if it meets some criteria and then perform
the necessary change to the original file with sed (or whatever tool). This will only then require a single read of the file by bash and one by sed.
This will however still have the same effect that every line is written to the file using sed but with the on line changed.

The only other suggestion would be to use your "-n" option and print to a new file only the lines you want.

Hi,

it is still not clear what I was trying to explain. When you make the substitution with the 's' command your complete file is in pattern space. When sed completes the command it writes the complete pattern space to the file. Do not confuse the pattern space with your search pattern. Think of the pattern space as an internal variable of sed. It has nothing to do with your search pattern. Sed has two of this 'variables'. One is the pattern space, which can be manipulated, the other one is the hold space. Hold space just 'holds' the content. You can not manipulate the hold space.

So the answer to your question is: No, you can not further optimize your script.

1 members found this post helpful.

Grail, sorry, but this discussion betweens is useless. I thought the 1st post of you was post of crts (I did not watched author).

Whole my script works perfectly, the only thing is the save command. I thing I described the problem enough and I described it more times. Here is my conclusion, and here is not space for making new surmises. That brings new confusion to this thread. I am pretty sure my script is 100% working nice. The last thing is to solve ineffecienty of the useless write. Let's stop gamble. If crts will come to anser my last question, I'd reather here his answer. Sorry again, I didn't see the name of author of post.

WELL, now I understand. It is good you said this.

OK. Thanx for answer.

Well maybe I know how to repair the problem with ineffectivity of my script. I have to create one complex pattern for sed. For example: if I have 4 changes to do, then I need only one sed command with 4 patterns. Do you know how would the syntax be?

E.g. - I have these variables:
search1="line 1"
search2="line 6"
search3="line 9"
search4="line 10"
replacement1="line 1 changed"
replacement2="line 6 changed"
replacement3="line 9 changed"
replacement4="line 10 changed"

Now I need to integrate all the patterns to change in one sed command but how to do it? Sed should find search1 and replace it to replacement1, then the same to make with strings 2,3,4 and write to file. Is this possible?

There is no way for so called 'write optimization' regarding redundant writes in sed. When you specify the -i option sed actually creates a temporary file which gets all output. Afterwards it copies this temporary file to the original file. You can test this by creating a file with a few words in it. Check the modifiation (ls -l file) of the file. Wait for a minute. Now run an empty sed script with your file+
Check again the modification time (ls -l file) and you will see that the modification time has indeed changed! Even though the content of the file is the same as before.
As for the inefficiency of your script, I have to agree with grail. The problem is probably not sed. To check the efficiency of sed I created a file which contained appr. one million lines. Every line had ~10 characters. So the overall size of the file was 12 Megabytes. Then I executed a script which would change every 20th and 21st line. It completed the task in under 3 seconds. So I would recommend that you prefix your sed script with the time command
and see how much time it takes for sed to complete its task. If the bottleneck is indeed sed, then you can think about an alternative approach for the sed part.
Hope this helps.

crts, the test of you was under different conditions. My file is under NTFS partition. My file is saved 23 times. I think that here can be the major factors of the delay.

Edit - times
time for one item

0.00user 0.00system 0:00.00elapsed 33%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+16outputs (0major+307minor)pagefaults 0swaps

or

0.00user 0.00system 0:00.03elapsed 33%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+16outputs (0major+307minor)pagefaults 0swaps

Total time of 23 times save is about 3 or 4 seconds.

The time for one execution of sed is 0.03 seconds. If you execute it 23 times this makes 0.69 seconds. So your 3-4 seconds are 'lost' somewhere else in your for loop. As I said, it is not sed that eats up all the time.

OK, I found the problem in my script and removed it. I did some job that is not necesary in save step.