login
Search
I use ed in emergencies when /usr is inaccessible, but I'm a lot more comfortable with vi. Will a static vi ever live in /bin? Helping someone use ed remotely, who has never used ed, when I myself don't use it regularly is always an adventure. Brad
>>>>> "Brad" == Brad Tilley <brad@16systems.com> writes: Brad> I use ed in emergencies when /usr is inaccessible, but I'm a lot more Brad> comfortable with vi. Will a static vi ever live in /bin? Helping someone Brad> use ed remotely, who has never used ed, when I myself don't use it Brad> regularly is always an adventure. Solution: learn "ed" a bit more. It's really *not* that hard. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
On Thu, 17 Dec 2009 17:12 -0800, "Randal L. Schwartz" Good advice. Guess I'm looking for the easy way out. I'll make myself edit in ed every Friday or something. Brad
REAL men use butterflies // http://xkcd.com/378/ -- The best the little guy can do is what the little guy does right
You mean real *Internet* men. In person, these men (for lack of a better word) are easily de-assified and can be made to cry. However, they are fearless keyboard warriors while alone, in the dark, dusty corner of their mother's basement at night. I made one of these Internet Men cry once by scattering his nicely organized punch card program all over the floor. Your pal, IR _________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/soci al-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
Fail. Real men put sequence numbers in the comment columns so the card sorter can put them back in order. -N
Just out of curiosity, my "emergencies" usually involve having to edit /etc/fstab that has entries that no longer apply after moving disks around. I just export TERM=xterm, fsck /usr and / mount both rw and vi away Is there a common emergency that comes up where /usr is not available? ed is of course on my study list :) Did ed come out before or after those clickety-clack paper printing terminals? -- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein
On Fri, Dec 18, 2009 at 1:09 AM, Chris Bennett
All text editors came after teletypes. (Teletypes go back to
the 1920's).
Dave "fossil"
--
This email address is hosted by gmail.
Privacy is not an issue with gmail.
Sure, but ed was definitely used with teletypes back in the day. Consider the first story told by Dennis Ritchie here: http://cm.bell-labs.com/cm/cs/who/dmr/odd.html in which a side-effect of using ed with a teletype is involved. Philip Guenther
In the past, I've kept a basic fstab so that when my disks dont mount as they should for any reason, I can move /etc/fstab out the way, replace it with my simple one, and bingo - no editing required. paulm
When working on changed to the dynamic linker, vi was always the first test program (sanity testing). And yes, it broke quite a number of times. Dale Rahn drahn@dalerahn.com
You should also try a teleprinter. I'm not sure where you can get them these days, and don't know about the price either.
I just compiled mg statically and put it in /bin, which is rather simple: Add 'LDFLAGS+=-static' somewhere in the makefile with your favourite editor. And then run: $ make $ strip mg $ ldd mg $ ls -l mg $ sudo install mg /bin/mg 400kb! that barely larger than a dynamic vi :-) # Han
If using ed is an "adventure", then you don't really know how to use vi. ed, sed, and vi are three of the most important Unix utilities, and there's no excuse for not learning all three. That's because they all use the same commands and syntax. If you know how to use one of them, then you know how to use the other two. Each is useful in a slightly different situation. vi is for interactive editing. ed and sed are most useful for writing editing scripts. ed reads a file into a buffer for editing and can write those edits back to the file. sed works as a filter, reading a stream from standard input line-by-line and editing each line before writing it to standard output. Short, one-line sed scripts are useful in command line pipes for translating the output of one program into the input of another program. Although most of the basic commands are the same in ed, sed, and vi, there are subtle differences. After you have spent some time using ed and sed, I suggest that you ask yourself the follow questions to test your understanding of those differences: "When is the global command (that is, g) useful in ed and vi? Why is the global command missing from sed?"
I would like to learn to use sed, however, I did not find that the man page was sufficient as a tutorial. I was not able to find any sed tutorials that were consistent with OpenBSD's variation. Does anyone know of any sed tutorials that work with OpenBSD's version? -- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein
I've personally thus far never bumped into any particular behaviours that would differentiate OpenBSD's sed(1) command syntax from that of other implementations. (That could be because of my relative inexperience, or because there are no substantial differences.) With that said, this page --which was not authored specifically for OpenBSD sed(1)-- may be of use: http://www.grymoire.com/Unix/Sed.html#uh-0 --regards, ropers
Nope, I ran into many pages like these. OpenBSD doesn't support sed -i -- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein
On Fri, Dec 18, 2009 at 1:35 PM, Chris Bennett GNU sed's file-in-place editing is a convenience, but not having it won't hamper your ability to learn to use sed. This is particularly true here, as that tutorial makes no mention of 'sed -i' Cheers, Anders.
OpenBSD's sed technicaly supports command concatation with ";" on the command line but it breaks "branch" without label. Which correctly branch to the end of the script on GNU sed. On OpenBSD, to get the same behavior you would need to define a label as the last instruction and branch to it. That might be a bug though. (branch without label works as expected from inline scripts) -- Hugo Villeneuve <hugo@EINTR.net> http://EINTR.net/
Read the caveat at the end of the sed man page: "The use of semicolons to separate multiple commands is not permitted for the following commands: a, b, c, i, r, t, w, :, and #." Either use newlines instead of semicolons, or give each line of the script separately with the -e option. For example, instead of sed 's/a/b/ ; t ; s/c/d/' use sed -e 's/a/b/' -e 't' -e 's/c/d/'
I should have left more quoted text about tutorial from other sed implementation. I had been using gnu sed for a while and encountered this issue I should read better. Since it's documented, it's not a bug. Of course that sentence is false. ":" correctly interpret semicolon as next command. "b" and "t" has partial support (only when the label is not empty). It is true for the a c i r w #. Is this one of those few case where I should obey the man page It's a cute work around. My point is: if a label can't contain semicolons, why support "tlabel;" and not "t;"? I don't understand the logic of it. Don't trust this diff but it make my few test works: Index: compile.c =================================================================== RCS file: /cvs/src/usr.bin/sed/compile.c,v retrieving revision 1.28 diff -u -r1.28 compile.c --- compile.c 16 Oct 2008 16:34:32 -0000 1.28 +++ compile.c 25 Dec 2009 17:46:49 -0000 @@ -283,7 +283,7 @@ case BRANCH: /* b t */ p++; EATSPACE(); - if (*p == '\0') + if (*p == '\0' || *p == ';' ) cmd->t = NULL; else cmd->t = duptoeol(p, "branch", &p);
Keep in mind that GNU sed is not the standard version of sed, it contains many nonstandard features. The standard version of sed is specified by POSIX. The places where OpenBSD sed deviates from the POSIX standard are documented at http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/sed/POSIX?rev=1.2;content-type=text%... In particular, that document says that "Historic versions of sed permitted commands to be separated by semi-colons, e.g. 'sed -ne '1p;2p;3q' printed the first three lines of a file. This is not specified by POSIX. Note, the ; command separator is not allowed for the commands a, c, i, w, r, :, b, t, # and at the end of a w flag in the s command. This implementation follows historic practice and implements the ; separator." Basically, the semicolons are a nonstandard historic feature. If you want your sed scripts to be compatible with all Unix systems, then stick to the POSIX standard and use newlines or -e to separate commands.
I learned sed from the book Sed & Awk by Dougherty and Robbins. http://amazon.com/dp/1565922255 I highly recommend it. Of the three utilities ed, sed, and vi, sed is probably the most challenging because it doesn't have an interactive mode. With ed or vi you can always do something interactively if you don't know the relevant command, but sed forces you to understand the commands if you want to get anything done. Learning sed will make you a better user of ed and vi.
the man page is not a tutorial, but it does document everything. you can use google and SEE ALSO for other stuff. actually the man page is surprisingly complete, though i wouldn;t blame you for googling. everyone else has joked about it, but ed(1) is a braw wee editor... real mem tire of comparisons. jmc
I'm aftraid my English (Scottish?) idiom falls short here. But I guess "braw wee editor" means "small, but fine editor"? Because then you are right, of course. -Otto (who learned ed before any other editor)
yes, it really means "a great little editor". although putting "great" and "little" together sounds all wrong. anyway, i was drunk when i wrote that. otherwise i would have ignored this stupid thread. jmc
>>>>> "Matthew" == Matthew Szudzik <mszudzik@andrew.cmu.edu> writes: Matthew> ed, sed, and vi are three of the most important Unix utilities, and Matthew> there's no excuse for not learning all three. That's because they all Matthew> use the same commands and syntax. If you know how to use one of them, Matthew> then you know how to use the other two. Everything I used to know about sed, I've forgotten once learning Perl. There's really no excuse for not knowing Perl and Python these days. And if you need to learn Perl, I can recommend a good book (or two :). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
That's bad: sed is still needed, see /usr/src/distrib/miniroot/list for a striking example. That said, liking and using Perl a lot, the same happens to me, but i see that as deficiency, not a virtue.
any excuse to not know python is a good and valid one. any. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
It seems that every decade has its own fashionable Unix scripting language. The original scripting language, used in the 1970's was sed. But awk became the fashionable language in the 1980's, then perl in the 1990's, and now python in the 2000's. Who knows what will be next? If you have time to spare, it certainly could be useful to learn all of these languages. But if you're going to learn just one of them, then I vote for sed. You will still encounter environments where sed is the only one of these languages available (as Ingo pointed out, the OpenBSD installer is one such example). It isn't really necessary to keep up with fashion, you can just stick with the historical standards.
