(old)Puppy Linux Discussion Forum

Hi there

I have had my head buried in sed man pages and tutorials today. I did have basic concept of sed but I was doing things parrot fashion, anyone can copy stuff and achieve a desired result. Today I decided to see what I could do with out copying the work of others.

Ok, I'm progressing nicely, actually wrote some sed code and knew what the result would be. Good, it's starting to sink in.

A query I have is of zigbert's work. If you read this ziggy maybe you could answer but if you don't it doesn't matter, I'm sure someone else will.

In a lot of zigbert's programs sed is used, mainly to replace text in config files or scripts on the fly, much of the time using "sed" with "-ie" option. Now as I understand it the "-i" option reads the target file, finds the match, makes a backup in memory, removes the old string or char if specified, and replaces or adds with the new string or chars, deleting the backup. But a suffix can be added to "-i" to keep the backup... this is where my brain is failing me.. I can't get a handle on the suffix bit.

Now in zigbert's code the suffix is usually "e"... "e" is another sed option but I am not sure of how this works. Until I do know how this works I am leaving the e out of my code.

Any body know about this one?

Cheers

Seems that -e is for specifying multiple commands:
http://www.grymoire.com/Unix/Sed.html#uh-13

Make backup of file before editing?

Hi Dejan,

That link you gave is the one in my current sig.

I don't think it's the same thing because if you see Sigmund's code where it is used it is only one command.
(from stardust-004 thread)

There are many examples in Pwidgets too.

Cheers

That's a good tutorial
I started learning sed from it myself, haven't gone far from basic options though, even it really has bunch of them. I also found another good blog post with practical example of manipulating text files with sed and sometimes in combination with other commands but lost link.

Not sure what could else -e be, maybe zigbert just got used to have it in script so he puts it there anyway Maybe he clarifies it for us.

Anyway, why not make backup of file before sed command with cp?

hi Dejan

Now, I must agree that the tutorial is good and it is well maintained, last update was only last year... sed has been around for over 20 years.

I think the "e" in zigbert's code is a suffix.. it is explained on the sed manpage.. http://www.gnu.org/software/sed/manual/sed.html

I don't know if it is a backup option, but if it is, where is the backup?

Backing up with cp is of course an option, but if you are running a script in conjunction with gtkdialog and you need a sed call, it would be better to use the internal commands than relying on an extra bash call, especially if running something on the fly. I am trying to code efficiently, as we all do. Also, if your code is bullet proof, then there is not the need for a backup in this instance.

Thanks for your ideas, anyone else know? Or at least got an idea?

Cheers

No, it means 'exec'. It lets you do stuff like this: To use a backup suffix, you'd do this:
sed -i .bkp ... (notice the space between -i and the suffix)
or:
sed --in-place=bkp ...

Using -ie all the time doesn't hurt anything, even if onyl one substitution is being specified.
For backups, you could always do things the old-fashioned way -like older sed versions had to be used:
cp file file.bkp
sed -ie 's%stuff%no-stuff%' file.bkp > file

Hi amigo

Thanks for that explanation.

That possibility had entered my mind, so now I know.

Cheers

EDIT: there will be more questions on sed... I would like to keep this discussion going.

Yes -e is for exec but it's not neccessary when having one task like Mick gave example I think.

http://linuxcommando.blogspot.com/2008/ ... -file.html
Thise one has interesting examples and some in reader comments too.

I avoid sed like the plague, except for the simplest replacements like you asked about. regex's make my head spin too much, so any fancy work with sed makes me go gaga...

If you read this ziggy maybe you could answer but if you don't it doesn't matter, I'm sure someone else will.

As always, I'm too late.

Using -ie all the time doesn't hurt anything, even if onyl one substitution is being specified.

I got many bad habbits, some much worse than this

I never could figure out how to easily replace an existing "new line" \n with a different character |,\t(tab) .... probably because it is a LINE editor and that would make it a lineS editor.

Fortunately the replace function in Geany easily does this as well as most of the stuff that is hard to do in sed and vice-versa. Probably not as good if you are developing a bash script to automate something, but passable if you are just data-mining the bits that you need.

For this I use geany for the parts that are exactly the same throughout and sed for the areas where I want just any non-specific string[a-zA-Z]*, number[0-9]* etc... and want to append, prepend, iterate or swap positions...

I usually do first without the -i to make sure I am not going to bork my file (, but I think there is a parameter that will do an automatic backup)

It is also pretty handy to use sed in combination with find -execI use it often to replace all of the builtin -O[0-3] with -Os in *akefile or *.mk

you could always leave the sed -ie in your code and later remove the e

amigo wrote:I avoid sed like the plague, except for the simplest replacements like you asked about. regex's make my head spin too much, so any fancy work with sed makes me go gaga...

I can tolerate regular expressions when they meet the definition of regular expressions in formal language theory. The addition of state dependence means you have to have a very good understanding of how the pattern matcher works, which defeats the idea of regular expressions as abstractions.

The main reason for using sed is that it has been around since the mid 1970s, so you find it in just about any descendant of Unix. When it works, it is compact and fast.
--------
"You may have understood the script perfectly when you wrote it. But six months from now it could look like modem noise." Bruce Barnett
--------
This is a real hazard for maintenance programmers. Always include a comment explaining what the script is supposed to do. Keep scripts short, and, please, don't use bizarre tricks that depend on details of the sed pattern matcher. Don't strive for the shortest script at the expense of clarity.

This is close to being a write-only language. But, then I feel the same way about Perl because I am

prehistoric

"You may have understood the script perfectly when you wrote it. But six months from now it could look like modem noise." Bruce Barnett

That's the real practical reason that I avoid fancy one-liners of al kinds -because I maintain a large collection of code, I don't want to be having to study what I myself wrote a few days/weeks/years ago to know what it is trying to do.

sed doesn't work for well for replacing end-of-line chars exactly beacuse it is a line editor. There are a couple of programs whcih may do better and make nice replacements for sed -as far as simple replacement goes -one is called 'replace' and the other is 'rpl'. they both have very straightforward usage:
replace old-word new-word file-name
Another problem with fancy usage of sed is compatibility between versions. What works 'here' may well not work 'elsewhere'.

As to remembering what a section of code does, that is why one should comment written code as to what it is to do.
If one examines some of Barry's code, you will see that he uses comments a lot.
And I for one, knowing nothing of using sed, went to the link concering sed and printed a pdf file of it for offline use in learning it.

8-bit wrote:As to remembering what a section of code does, that is why one should comment written code as to what it is to do...

One problem with comments is that they often don't get written because they aren't necessary to make the machine work. And, when they are written after the fact, they often turn out to be like this familiar howler: The trick is to make them an aid to development, and write them first. Write pseudo-code to be executed by the human who writes the detailed code, even if this is yourself.

A deliberate effort to describe the algorithm at a higher level of abstraction pays off. Do this well, and you can reuse the comments when you fix the code so it actually does what you intended. If you keep having to change descriptive comments every time you alter the code, you are operating at too low a level of abstraction.

Did you notice I said section and not line?
A section of code in a program would be commented as to what you expect it to do.
There is no advantage to commenting lines.
Also a line that tries to combine a lot is not my idea of fun.
Especially when it comes to debugging.
I try to keep from combining a bunch of actions on one line.

prehistoric wrote:The trick is to make them (comments) an aid to development, and write them first. Write pseudo-code to be executed by the human who writes the detailed code, even if this is yourself.

Lately that is how I have been planning a script. Write the comments into a logical order then write the code, specially if there is something new I've learned and may not revisit for awhile.

My current sig aroused some interest...

You may have understood the script perfectly when you wrote it. But six months from now it could look like modem noise.

Bruce Barnett (I put here for future ref, I will eventually change my sig again )

Good healthy discussion on comments and when/how to use them. Still learning, and it's not all about code.

eg Cheers

technosaurus wrote:I never could figure out how to easily replace an existing "new line" \n with a different character |,\t(tab) .... probably because it is a LINE editor and that would make it a lineS editor.

tr does a good job for this kind e.g.
aragon

Just my two cents but I see it like Prehistoric,and I think remarks are not only for the original programmer but for anyone whom you may share your work with.Isn't this what Puppy is all about ? I'm thinking also that remarks can help some kind soul who wishes to lend a hand on something you may not be able to get quite right.I know this is old school thinking and I certainly fit that category.(old) cheers

01micko wrote: Now in zigbert's code the suffix is usually "e"... "e" is another sed option but I am not sure of how this works. Until I do know how this works I am leaving the e out of my code.

Any body know about this one?

sed is the Unix "stream editor", intended to be used in scripts to make unattended edits on files.

By default, sed expects to be used in "one liners", where you issue the sed command, the editing commands, and the file(s) you want sed to process on the command line. This is fine for simple edits, but some things you want to do may be more extensive. and require multi-line sed scripts read from an external file.

That's what -e is for. After "sed -e", sed expects the name of an editing script, like "sed -e foobar.sed <input file>"

sed offers the full range of editing features of the ed line editor, including regular expressions and branching operations. When you run sed on a file, sed reads each line of the input file in turn and runs the editing script on it, then writes out the line and reads the next.

When it has processed all lines in the file, sed exits, and control passes to whatever called it.

.The canonical home for sed is on SourceForge, and much good information may be found there: http://sed.sourceforge.net/
______
Dennis