Re: vi in ramdisk?
Arch Linux uses nano in its boot drive. Pretty simple, gets the job done. (They also include vi.) Dave Raymond On 11/16/19, Roderick wrote: > > On Sat, 16 Nov 2019, U'll Be King of the Stars wrote: > >> I assumed that the canonical reference for ed was K, "The Unix >> Programming > > Reference = man page. Under /usr/share/doc/usd/ in an old BSD System > you may find Brian W. Kernighan ed Tutorial. Just google for it. > >> Sam looks very interesting too, > > Yes. It is a perfectionated ed, not anymore line oriented, and with gui. > I am tired of emacs bloating and I am thinking on sam as an alternative, > but the background colour is annoying. > >> What is sos? Is it something like open mode in Vi? > > Editor in DEC 10 with TOPS-10, I think standard there. > > Rod. > > -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
Re: teco, and Re: vi in ramdisk?
On 2019-11-15, gwes wrote: > Still not huge. I don't know what the current upper limit for > programs in the install medium is. As this is a totally irrelevant > thread, I suspect that squashing teco into the single install > executable would only raise it 250K because it uses only very > vanilla libraries. It varies per-arch / ramdisk type, but we have deleted drivers to save significantly less than 250K. Some are quite tight, others less so.
Re: vi in ramdisk?
On Sat, 16 Nov 2019, U'll Be King of the Stars wrote: I assumed that the canonical reference for ed was K, "The Unix Programming Reference = man page. Under /usr/share/doc/usd/ in an old BSD System you may find Brian W. Kernighan ed Tutorial. Just google for it. Sam looks very interesting too, Yes. It is a perfectionated ed, not anymore line oriented, and with gui. I am tired of emacs bloating and I am thinking on sam as an alternative, but the background colour is annoying. What is sos? Is it something like open mode in Vi? Editor in DEC 10 with TOPS-10, I think standard there. Rod.
Re: vi in ramdisk?
U'll Be King of the Stars writes: > This has gotten me thinking about whether line-based editing is really > the best abstraction for simple editors. Yes. Yes it is. You can prise ed out of my cold dead hands. I don't get where the desire for an editor in the installer comes from. If you have even the barest scraps of a system you can boot a full kernel and get a much richer environment to work in. The installer kernel itself contains much of what's necessary to run the installed binaries. boot -s. It's a thing. If any tools should be added to the installer it's something for network interrogation because that gives you more scope for dealing with odd scenarios *before* you have an installed system, but what's already there was apparently enough to get over whatever that problem was I encountered. > > The power of ed is in the regular expressions, search and substitution. The power of ed comes from the power of unix that it runs within not any particular string matching technique. It is a simple tool which does one thing, does it well, operates as a pipeline on text streams, etc. It would still have that power with any other string matching technology or even some other obscure addressing mode. > I assumed that the canonical reference for ed was K, "The Unix > Programming Environment". But since then I have discovered this book: > > https://mwl.io/nonfiction/tools#ed > > When I return home I will buy it. (I'm overseas at the moment.) > > What are some other good books for learning ed? How about online > resources, e.g., FTP sites with collections of interesting scripts. I assumed the canonical reference for ed was ed(1). Well I guess the canonical reference would be the contents of /usr/src/bin/ed but I'm not about to go trawling through that when there's some stellar documentation sitting right there. > I'm particularly interested in its history, usage idioms, different > implementations, multilingual capabilities, and using it as a vehicle > for mastering regular expressions to the point that they are second nature. I would recommend perl for this, not ed. ed it a text editor. Perl is a pattern matching engine with a turing complete programming environment hanging off the back of it. It's adapted (some might say warped) the language that represents regular expressions in strange ways but the machinery that's been built around it is fantastically easy to use in a "get out of the way" sense, leaving you to concentrate on the arcana of regular expressions. Deciding why one would want to do that is left as an exercise for the reader. But absolutely do keep on top of the differences between perl's regexes and regular regular expressions as described in re_format(7). Matthew
Re: teco, and Re: vi in ramdisk?
On 11/15/19 1:59 PM, gwes wrote: TECOC from github... For general amusement: without video (curses) UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 29775 86827 0 28 0 540 1296 - T p2 0:00.00 ./tecoc $ size tecoc text data bss dec hex 102449 13096 13424 128969 1f7c9 with video (curses) $ size tecoc text data bss dec hex 114772 13456 12432 140660 22574 UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 82440 86827 0 28 0 808 2296 - T p2 0:00.01 ./tecoc for comparison: $ size /bin/ed text data bss dec hex 207704 10800 24264 242768 3b450 UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 75971 86827 0 3 0 256 196 - Tp p2 0:00.00 ed Interesting to note that the text size of ed(1) is almost twice that of vi. RSS is larger for teco. 1.3MB isn't too bad, though. On disk: 12412$ ls -l tecoc -rwxr-xr-x 1 xxx 256920 Nov 15 13:48 tecoc* 12494$ ls -l /bin/ed -r-xr-xr-x 1 root bin 229928 Apr 13 2019 /bin/ed* As Mr. Davis kindly points out, everything in /bin is statically linked. With -Bstatic $ ls -l tecoc -rwxr-xr-x 1 1472504 Nov 15 15:47 tecoc* Still not huge. I don't know what the current upper limit for programs in the install medium is. As this is a totally irrelevant thread, I suspect that squashing teco into the single install executable would only raise it 250K because it uses only very vanilla libraries. Geoff Steckel
Re: vi in ramdisk?
On 16/11/2019 06:55, Roderick wrote: On Thu, 22 Jan 1970, Chris Bennett wrote: Yes, but ed also allows one to easily work with only 1-3 lines of screen. I think with every line editor is so? I don't know of any line editors aside from ed, Vi's open mode, Sam, Edlin, and QED and its deriviatives. This has gotten me thinking about whether line-based editing is really the best abstraction for simple editors. If I understand right then this is what structural regular expressions are supposed to expand on. The power of ed is in the regular expressions, search and substitution. I assumed that the canonical reference for ed was K, "The Unix Programming Environment". But since then I have discovered this book: https://mwl.io/nonfiction/tools#ed When I return home I will buy it. (I'm overseas at the moment.) What are some other good books for learning ed? How about online resources, e.g., FTP sites with collections of interesting scripts. I'm particularly interested in its history, usage idioms, different implementations, multilingual capabilities, and using it as a vehicle for mastering regular expressions to the point that they are second nature. Sam looks very interesting too, and twenty years after writing my first text editor I've returned to my favorite type of personal side project, and looking for the kindest mix of functionality and simplicity. The key was understanding not to make something "no simpler" than the simplest useful design. The only thing that I find more comfortable in sos and miss in ed is the line alter mode that allows to interactively delete and insert characters in a line. What is sos? Is it something like open mode in Vi? That is also what one wants to carefully do in configuration files. Normaly no big editing. Indeed. Sometimes my blood runs cold when I'm writing and deploying a hotfix of this nature in a production system. The example that somebody gave earlier in this(?) thread about fixing a `/etc/fstab` is one that I have experience with. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: vi in ramdisk?
On Thu, 22 Jan 1970, Chris Bennett wrote: Yes, but ed also allows one to easily work with only 1-3 lines of screen. I think with every line editor is so? The power of ed is in the regular expressions, search and substitution. The only thing that I find more comfortable in sos and miss in ed is the line alter mode that allows to interactively delete and insert characters in a line. That is also what one wants to carefully do in configuration files. Normaly no big editing. Rod.
Re: vi in ramdisk?
On Fri, Nov 15, 2019 at 06:02:16PM +, Roderick wrote: > > On Fri, 15 Nov 2019, Theo de Raadt wrote: > > > Christian Weisgerber wrote: > > > > How large is a C implementation of TECO? > > > > he probably means cat plus the shell's redirection capability. > > I think, TECO is much more powerfull that ed and vi. > > But perhaps DEC 10s SOS? > > I do not know if it runs in unix or if there is a C implementation. > But I remember it as much simpler than ed, but more comfortable, > and for manually editing enough. > > Isn't really in unix nothing simpler than ed? > > Well, the advantage of ed is, that it is the standard unix editor. > > Rod. > Yes, but ed also allows one to easily work with only 1-3 lines of screen. Screen size can matter. I have always fallen back to using ed when running single user. If I'm running off of my phone in landscape, one line is all I can see. With ed, that is enough. With vi plus making a mistake, it's harder to see. Vi is more powerful than ed, but I'm used to using vim, so I keep hitting keys that don't work in vi (which is my problem, not vi's). I have never used teco or sos. I'm neutral overall on this, but the number of screen lines used does matter to me. Forgive me if the date is wrong, I can't find the cause. Going to do a new snapshot right now. Chris Bennett
teco, and Re: vi in ramdisk?
TECOC from github... For general amusement: without video (curses) UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 29775 86827 0 28 0 540 1296 - T p2 0:00.00 ./tecoc $ size tecoc text data bss dec hex 102449 13096 13424 128969 1f7c9 with video (curses) $ size tecoc text data bss dec hex 114772 13456 12432 140660 22574 UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 82440 86827 0 28 0 808 2296 - T p2 0:00.01 ./tecoc for comparison: $ size /bin/ed text data bss dec hex 207704 10800 24264 242768 3b450 UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 75971 86827 0 3 0 256 196 - Tp p2 0:00.00 ed Interesting to note that the text size of ed(1) is almost twice that of vi. RSS is larger for teco. 1.3MB isn't too bad, though. On disk: 12412$ ls -l tecoc -rwxr-xr-x 1 xxx 256920 Nov 15 13:48 tecoc* 12494$ ls -l /bin/ed -r-xr-xr-x 1 root bin 229928 Apr 13 2019 /bin/ed*
Re: vi in ramdisk?
On Fri, Nov 15, 2019 at 1:17 PM Roderick wrote: > On Fri, 15 Nov 2019, Ian Darwin wrote: > > Who needs cat when you have echo? > > Echo? Necessary?! Terrible waste of paper in a teletype terminal! > I remember editing with sos in TOPS 10 after giving the command: > tty noecho. This is starting to smell like premature optimization. Contrast, for example: $ (echo this; echo is; echo test) >file vs $ cat >file this is a test And tell me: which uses more paper? (Answer: neither, in my case, since I am not using a teletype machine.) Thanks, -- Raul
Re: vi in ramdisk?
On Fri, 15 Nov 2019, Ian Darwin wrote: Who needs cat when you have echo? Echo? Necessary?! Terrible waste of paper in a teletype terminal! I remember editing with sos in TOPS 10 after giving the command: tty noecho. Rod.
Re: vi in ramdisk?
On Fri, 15 Nov 2019, Theo de Raadt wrote: Christian Weisgerber wrote: How large is a C implementation of TECO? he probably means cat plus the shell's redirection capability. I think, TECO is much more powerfull that ed and vi. But perhaps DEC 10s SOS? I do not know if it runs in unix or if there is a C implementation. But I remember it as much simpler than ed, but more comfortable, and for manually editing enough. Isn't really in unix nothing simpler than ed? Well, the advantage of ed is, that it is the standard unix editor. Rod.
Re: vi in ramdisk?
On Fri, Nov 15, 2019 at 10:08:26AM -0700, Theo de Raadt wrote: > Christian Weisgerber wrote: > > > > I think, for editing config files, there are sure editors that > > > are simpler, smaller, not so powerful, but easier to use than ed. > > > > By all means, do not keep us in suspense and tell us the names of > > these editors. > > > > How large is a C implementation of TECO? > > he probably means cat plus the shell's redirection capability. > Who needs cat when you have echo?
Re: vi in ramdisk?
Christian Weisgerber wrote: > > I think, for editing config files, there are sure editors that > > are simpler, smaller, not so powerful, but easier to use than ed. > > By all means, do not keep us in suspense and tell us the names of > these editors. > > How large is a C implementation of TECO? he probably means cat plus the shell's redirection capability.
Re: vi in ramdisk?
On 2019-11-15, Roderick wrote: >> ed is included in the ramdisk, but if your use case is using vi to fix a > > I imagine, it is there for using it in scripts. Interestingly enough, the installer itself does not use ed, as far as I can tell. * I pretty regularly use ed to perform some configuration tweaks before rebooting a freshly installed system. * I have, rarely, used ed to recover a system from errors in /etc/fstab. * Since the installer itself is just a script, it can be modified with ed in the install environment and then re-run. From time to time I do this when debugging the installer or working on some feature there. If you have some passing familiarity with sed, then ed will feel very familiar. It's just an interactive sed. (Historically, it's the other way around, of course.) > I think, for editing config files, there are sure editors that > are simpler, smaller, not so powerful, but easier to use than ed. By all means, do not keep us in suspense and tell us the names of these editors. How large is a C implementation of TECO? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: vi in ramdisk?
On Fri, 15 Nov 2019, Noth wrote: ed is included in the ramdisk, but if your use case is using vi to fix a I imagine, it is there for using it in scripts. I think, for editing config files, there are sure editors that are simpler, smaller, not so powerful, but easier to use than ed. Rod.
Re: vi in ramdisk?
On 08/11/2019 07:06, Philip Guenther wrote: On Thu, Nov 7, 2019 at 9:57 PM Brennan Vincent wrote: I am asking this out of pure curiosity, not to criticize or start a debate. Why does the ramdisk not include /usr/bin/vi by default? To date, it is the only UNIX-like environment I have ever seen without some form of vi. The ramdisk space is extremely tight. We include what we feel is necessary, PUSHING OUT other stuff as priorities shift. If you have watch the commits closely, you would have seen drivers vanish from the ramdisks on tight archs as new functionality was added. Given what we want people to use the ramdisks for (installing, reinstalling, upgrading, fixing boot and set issues), vi is not necessary, while other functionality and drivers extend their applicability. We will keep the latter and not include the former. Philip Guenther ed is included in the ramdisk, but if your use case is using vi to fix a config file on an existing installation, just do this (assuming you mounted everything into /mnt): chroot /mnt /bin/ksh export TERM=vt100 vi /etc/yourfile Cheers, Noth
Re: vi in ramdisk?
On Thu, Nov 7, 2019 at 9:57 PM Brennan Vincent wrote: > I am asking this out of pure curiosity, not to criticize or start a debate. > > Why does the ramdisk not include /usr/bin/vi by default? To date, > it is the only UNIX-like environment I have ever seen without some form > of vi. > The ramdisk space is extremely tight. We include what we feel is necessary, PUSHING OUT other stuff as priorities shift. If you have watch the commits closely, you would have seen drivers vanish from the ramdisks on tight archs as new functionality was added. Given what we want people to use the ramdisks for (installing, reinstalling, upgrading, fixing boot and set issues), vi is not necessary, while other functionality and drivers extend their applicability. We will keep the latter and not include the former. Philip Guenther
Re: vi in ramdisk?
Brennan Vincent wrote: > Hello, > > I am asking this out of pure curiosity, not to criticize or start a debate. > > Why does the ramdisk not include /usr/bin/vi by default? To date, > it is the only UNIX-like environment I have ever seen without some > form of vi. For the same reasons it doesn't contain a web browser: Not required, and besides that far too large.
vi in ramdisk?
Hello, I am asking this out of pure curiosity, not to criticize or start a debate. Why does the ramdisk not include /usr/bin/vi by default? To date, it is the only UNIX-like environment I have ever seen without some form of vi.
