Re: Is there an officially Fedora supported replacement for,>,> the old rc.local? - still an issue
On Tue, 19 Jul 2022 07:37:12 -0400 Tom Horsleyhorsley1953@gmal.com wrote> On Mon, 18 Jul 2022 22:25:03 -0400
R. G. Newbury wrote:
This sleight-of-hand was posted by someone on an Arch distro forum/mailing list. I do not have his name, but kudos and thanks whoever you are. It works
Those are my exact notes (and even comments) from when systemd started killing off rc.local stuff that took "too long". Maybe someone copied them from the fedora list to an arch list :-).
Well thanks and kudos again. It's clean, understandable and it works!.
But I definitely didn't use vim, I used emacs :-).
Heretic! Unclean! Unclean!
Geoff
On 7/19/22 11:03, R. G. Newbury wrote:
But I definitely didn't use vim, I used emacs :-).
Heretic! Unclean! Unclean!
I've never understood why so many people worship vi. If I need to edit a file in a terminal, I use Mork's Editor.
On Tue, 2022-07-19 at 11:24 -0600, Joe Zeff wrote:
I've never understood why so many people worship vi.
It has a long history. It's a default install on many systems. It works on a command line, it also has a GUI. There's lots of extra features available. It loads in a flash.
I've been using it for years for writing web pages. There's useful add-ons to make writing HTML handy. It is "what you type is what you get," as opposed to some graphical thing that works in some peculiar and limiting way. It handles other things modifying the file while you're working on it rather well.
If I need to edit a file in a terminal, I use Mork's Editor
I've never even heard of that one. My quick internet search didn't find it, either.
Naanu naanu...
Think Mork's editor refers to nano.
Thou with Mork it seems to be spelled nanu nanu..
But that is just a guess..
On 20 Jul 2022 at 6:56, Tim via users wrote:
Subject: Re: Is there an officially Fedora supported replacement for,>,> the old rc.local? - still an issue To: users@lists.fedoraproject.org Date sent: Wed, 20 Jul 2022 06:56:12 +0930 Send reply to: Community support for Fedora users users@lists.fedoraproject.org From: Tim via users users@lists.fedoraproject.org Copies to: Tim ignored_mailbox@yahoo.com.au
On Tue, 2022-07-19 at 11:24 -0600, Joe Zeff wrote:
I've never understood why so many people worship vi.
It has a long history. It's a default install on many systems. It works on a command line, it also has a GUI. There's lots of extra features available. It loads in a flash.
I've been using it for years for writing web pages. There's useful add-ons to make writing HTML handy. It is "what you type is what you get," as opposed to some graphical thing that works in some peculiar and limiting way. It handles other things modifying the file while you're working on it rather well.
If I need to edit a file in a terminal, I use Mork's Editor
I've never even heard of that one. My quick internet search didn't find it, either.
Naanu naanu...
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On 7/19/22 15:26, Tim via users wrote:
If I need to edit a file in a terminal, I use Mork's Editor
I've never even heard of that one. My quick internet search didn't find it, either.
Naanu naanu...
You probably have, but don't realize it: nano.
On Tue, Jul 19, 2022 at 2:25 PM Joe Zeff joe@zeff.us wrote:
On 7/19/22 11:03, R. G. Newbury wrote:
But I definitely didn't use vim, I used emacs :-).
Heretic! Unclean! Unclean!
I've never understood why so many people worship vi. If I need to edit a file in a terminal, I use Mork's Editor.
On early unix systems, terminals were the only user interface. At that time, vi was a big improvement over ed. Many early unix users learned vi, and now still find it available by default on most linux systems as well as macOS. Some modern editors are overly helpful and will replace ASCII characters with look-alike glyphs from Unicode fonts (opening and closing quotes, different types of space characters). Recently I'm finding many "bugs" are caused by these look-alike characters in ASCII configuration files edited by users. In vi I trust.
On Wed, 2022-07-20 at 08:54 -0300, George N. White III wrote:
On Tue, Jul 19, 2022 at 2:25 PM Joe Zeff joe@zeff.us wrote:
On 7/19/22 11:03, R. G. Newbury wrote:
But I definitely didn't use vim, I used emacs :-).
Heretic! Unclean! Unclean!
I've never understood why so many people worship vi. If I need to edit a file in a terminal, I use Mork's Editor.
On early unix systems, terminals were the only user interface. At that time, vi was a big improvement over ed. Many early unix users learned vi, and now still find it available by default on most linux systems as well as macOS. Some modern editors are overly helpful and will replace ASCII characters with look-alike glyphs from Unicode fonts (opening and closing quotes, different types of space characters). Recently I'm finding many "bugs" are caused by these look-alike characters in ASCII configuration files edited by users. In vi I trust.
We couldn't even run vi at the time on our PDP-11/45 with 6th Edition UNIX. IIRC it was too big for the address space. I wrote my PhD thesis in Nroff using George Coulouris' em ('editor for mortals'), the precursor to ex, which eventually became vi. It had a single-line display but unlike ed you could see what you were doing.
poc
On 7/20/22 05:54, George N. White III wrote:
On early unix systems, terminals were the only user interface. At that time, vi was a big improvement over ed. Many early unix users learned vi, and now still find it available by default on most linux systems as well as macOS.
Yes. I remember that well. However, there are other editors available for a terminal now that are far easier to use and don't mung the output so that Linux newcomers don't have to learn the arcane syntax of vi, but so many of them think they have to. Maybe Linux would spread easier and faster if newcomers weren't forced to do things the hard way now that it's not needed, and that's what I was talking about.
On 7/20/22 07:45, Patrick O'Callaghan wrote:
We couldn't even run vi at the time on our PDP-11/45 with 6th Edition UNIX. IIRC it was too big for the address space. I wrote my PhD thesis in Nroff using George Coulouris' em ('editor for mortals'), the precursor to ex, which eventually became vi. It had a single-line display but unlike ed you could see what you were doing.
And because you had to do that decades ago new Linux users today should be using vi instead of all the more user friendly editors available for use in a terminal?
On Wed, 2022-07-20 at 09:16 -0600, Joe Zeff wrote:
On 7/20/22 07:45, Patrick O'Callaghan wrote:
We couldn't even run vi at the time on our PDP-11/45 with 6th Edition UNIX. IIRC it was too big for the address space. I wrote my PhD thesis in Nroff using George Coulouris' em ('editor for mortals'), the precursor to ex, which eventually became vi. It had a single-line display but unlike ed you could see what you were doing.
And because you had to do that decades ago new Linux users today should be using vi instead of all the more user friendly editors available for use in a terminal?
I don't know how you draw that conclusion from what is merely a reminiscence. I use vi because I'm familiar with it. I've also used emacs extensively and like it. There are plenty of alternatives and no- one is being forced to use any of them. I think the Fedora Workstation default is now nano, for what it's worth.
poc
On 7/20/2022 10:16 AM, Joe Zeff wrote:
On 7/20/22 07:45, Patrick O'Callaghan wrote:
We couldn't even run vi at the time on our PDP-11/45 with 6th Edition UNIX. IIRC it was too big for the address space. I wrote my PhD thesis in Nroff using George Coulouris' em ('editor for mortals'), the precursor to ex, which eventually became vi. It had a single-line display but unlike ed you could see what you were doing.
And because you had to do that decades ago new Linux users today should be using vi instead of all the more user friendly editors available for use in a terminal?
Careful there- even today, a very large number of new Linux devices don't run a GUI at all, so a text-based editor (and knowing how to drive it) is a necessity.
Also, I think you mean 'shell' instead of 'terminal'- a 'terminal' is an external piece of hardware that terminates a serial line, like an ADM-3A or TVI-912C, etc. We generally haven't used terminals since the 1980's.
;)
On 7/20/22 09:30, Patrick O'Callaghan wrote:
I don't know how you draw that conclusion from what is merely a reminiscence. I use vi because I'm familiar with it. I've also used emacs extensively and like it. There are plenty of alternatives and no- one is being forced to use any of them. I think the Fedora Workstation default is now nano, for what it's worth.
I draw that conclusion from reading many posts here and elsewhere from Linux newbies using vi because (and possibly only because) whatever walkthroughs they're trying to follow specify vi, instead of just a text editor.
On 7/20/22 09:38, Ron Flory via users wrote:
Careful there- even today, a very large number of new Linux devices don't run a GUI at all, so a text-based editor (and knowing how to drive it) is a necessity.
Yes, but it doesn't have to be vi. One of the reasons I like nano is that most of the commands are listed at the bottom of the screen, including the one to get the rest of the list. No memorizing needed.
On 2022-07-20 11:14 a.m., Joe Zeff wrote:
On 7/20/22 05:54, George N. White III wrote:
On early unix systems, terminals were the only user interface. At that time, vi was a big improvement over ed. Many early unix users learned vi, and now still find it available by default on most linux systems as well as macOS.
Yes. I remember that well. However, there are other editors available for a terminal now that are far easier to use and don't mung the output so that Linux newcomers don't have to learn the arcane syntax of vi, but so many of them think they have to. Maybe Linux would spread easier and faster if newcomers weren't forced to do things the hard way now that it's not needed, and that's what I was talking about.
Hmm, that line of thought opens a really rusted can of worms. Since 80-90% of "newcomers" use Windows and their fingers are programmed for Windows keystrokes and mouse actions, maybe the Linux desktop should be a look-alike instead of just being better. However, only 5% of "newcomers" use Macs, so we should not bother to cater to them. Sorry, but I just don't buy it. The "make it like Windows" line of thinking is why I'm not happy with Gnome and systemd and a few other critical package groups that are going down the wrong path.
There are a lot of reasons why people pick their favourite editor - mine is vi (not vim), because (a) my fingers are programmed for it after almost 50 years of using it, (b) there are noticeably less keystrokes to get the job done compared with emacs, code, etc, (c) unless you only use it in a trivial way, it is quite a bit more powerful than almost all GUI editors that I can think of, and (d) unlike most other editors, unless the filesystem damage is extreme, it works when your machine is in trouble.
However, if you like some particular editor, why do you not simply change the EDITOR env variable in your .bashrc or kshrc or whichever other preferred CLI shell, and then YOUR default editor overrides the system default. Do not ever set it systemwide in /etc, since (d) above will bite you when you least expect it.
Just my 3 cents...
--
John Mellor
On Wed, 20 Jul 2022 10:00:13 -0600 Joe Zeff joe@zeff.us wrote:
One of the reasons I like nano is that most of the commands are listed at the bottom of the screen, including the one to get the rest of the list. No memorizing needed.
+1
On 20 Jul 2022, at 18:09, Joe Zeff joe@zeff.us wrote:
On 7/19/22 11:03, R. G. Newbury wrote:
But I definitely didn't use vim, I used emacs :-).
Heretic! Unclean! Unclean!
I've never understood why so many people worship vi. If I need to edit a file in a terminal, I use Mork's Editor.
At Berkeley university they liked emacs but on the VAX 11/780 only one user could be supported on BSD. The problem was found to be the I/O rate from single char input and echoing.
In response to the need to support 30 students on the VAX they needed to drop the I/O rate. This resulted in VI and matching kernel terminal ioctl changes to allow lines of text to be input as a single I/O. There is a usenix paper that describes this in detail that came out a long long time ago.
Now you have an army of graduates that know VI and use it at work. The rest is history…
But when I worked at DEC we used Goslings emacs on VMS and had enough hardware to support emacs. I still maintain it as Barry’s Emacs.
Barry
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Jul 20, 2022 at 10:00:13AM -0600, Joe Zeff wrote:
On 7/20/22 09:38, Ron Flory via users wrote:
Careful there- even today, a very large number of new Linux devices don't run a GUI at all, so a text-based editor (and knowing how to drive it) is a necessity.
Yes, but it doesn't have to be vi. One of the reasons I like nano is that most of the commands are listed at the bottom of the screen, including the one to get the rest of the list. No memorizing needed.
You mean nano is so complex that you can't remember its basic commands?
:)
I can't remember looking up a vi command for decades (other than the too numerous vim set options).
On Wed, 2022-07-20 at 09:57 -0600, Joe Zeff wrote:
I draw that conclusion from reading many posts here and elsewhere from Linux newbies using vi because (and possibly only because) whatever walkthroughs they're trying to follow specify vi, instead of just a text editor.
There you're into the territory of a tutorial trying to provide one set of instructions for an editor that is on virtually every Linux system, and that those who know how to provide those instructions will probably use the thing they use all the time.
I have seen website instructions that used other editors. I've also seen instructions that have repeated how to do the same thing using several different editors. For an author that would be quite annoying.
Most of the time I use gvim. I got used to it, it's customised, the coloured context highlighting is very useful for looking for typing errors by eye. Other editors are actually too simple for most of what I do. But even for the very simple plain text editing tasks I do less often I'll still use gvim or vim, it makes little sense to use one editor for this, another for that.
But, in general, I tend to agree. I'd rather provide instructions that say edit the /etc/hosts file and put your hostname on a line with your IP address, instead of explicitly listing all the hotkeys to do so. I also prefer instructions that explain the task you're trying to do, not just list the steps involved. Being told do this, do that, without any reasoning behind it makes it harder to tailor something to your own needs.
Unfortunately, I find I can't even give people instructions to open the Firefox preferences and change the something-or-other setting from this to that. They don't have the nous to look through the menus inside Firefox and find "preferences" or "settings" or "config" by themselves. I have to tell them the third menu across, the exact name of the settings option on their distro, the exact name of the setting to adjust in their distro.
This is where the mindset of Gnome design gets in; make everything work one way and take away anything that can customise it differently, it's easier to learn and explain when there's less to explain. Some computer nerds spend more time customising their desktop than actually doing work on their computer. But the average user that I've come across don't do any customisations, some are afraid to in case they break something, they just fumble through using what they can see on screen by default. They often seem quite surprised how I can fix something, but it's not arcane knowledge. I merely look through the menus, see what options I have available to me, what they say about themselves, test some of the likely ones out. I don't randomly pick things to see if they might help.
After decades of doing this I find I'm surprised to find just how many people don't seem to be able to read and comprehend beyond a grade three level. Now it's a welcome surprise to find someone who doesn't need step by step guiding through an entire process. There are people who've used computers for 20 years and still are unaware of copy and paste, and drag & drop. I had one Mac user complain they didn't use Windows when I suggested the dragon-drop (pun intended) method to easily do what they were doing, unaware that Mac championed that method right from the start.
When I started out using personal computers, it was done by people who had an interest in it. We wrote programs, we didn't buy them. The computer came with virtually nothing. I'm baffled by people toying with computers who have zero interest in computing, or don't actually like them. And I have contempt for government services that try to push everyone onto doing things on-line.
On Wed, 2022-07-20 at 09:57 -0600, Joe Zeff wrote:
On 7/20/22 09:30, Patrick O'Callaghan wrote:
I don't know how you draw that conclusion from what is merely a reminiscence. I use vi because I'm familiar with it. I've also used emacs extensively and like it. There are plenty of alternatives and no- one is being forced to use any of them. I think the Fedora Workstation default is now nano, for what it's worth.
I draw that conclusion from reading many posts here and elsewhere from Linux newbies using vi because (and possibly only because) whatever walkthroughs they're trying to follow specify vi, instead of just a text editor.
None of that has anything to do with my comment.
poc
On Jul 20, 2022, at 11:38, Ron Flory via users users@lists.fedoraproject.org wrote:
Also, I think you mean 'shell' instead of 'terminal'- a 'terminal' is an external piece of hardware that terminates a serial line, like an ADM-3A or TVI-912C, etc. We generally haven't used terminals since the 1980's.
“Terminal” is still the right term. Sure, you’re using a pseudo-terminal when running vi or nano, but that’s the interface it was written for. Modern terminals are just really fancy kernel interfaces. (There are some other kinds of terminals still in use but that’s another story)
Shells are *also* written to interact with a terminal. You don’t necessarily need a shell to launch vi or nano, but most users use those editors with a terminal.
-- Jonathan Billings
On 7/20/22 10:16, John Mellor wrote:
Hmm, that line of thought opens a really rusted can of worms. Since 80-90% of "newcomers" use Windows and their fingers are programmed for Windows keystrokes and mouse actions, maybe the Linux desktop should be a look-alike instead of just being better. However, only 5% of "newcomers" use Macs, so we should not bother to cater to them. Sorry, but I just don't buy it. The "make it like Windows" line of thinking is why I'm not happy with Gnome and systemd and a few other critical package groups that are going down the wrong path.
And you won't ever see me suggesting that. I switched to Linux to get away from Windows, and I don't want to go back.
There are a lot of reasons why people pick their favourite editor - mine is vi (not vim)
And that's fine. If you like vi, use it; if you prefer something else, use that. I just think that HOWTOs and walkthroughs should be editor agnostic, instead of making newbies think that there's One True Editor for Linux, no matter which one it is.
However, if you like some particular editor, why do you not simply change the EDITOR env variable in your .bashrc
Did that long ago, so that I can use the editor I like.
On 7/20/22 11:47, Jon LaBadie wrote:
You mean nano is so complex that you can't remember its basic commands?
No, I mean that I don't use it often enough to need to memorize them. If I did, I'm sure that I'd know all of the commands that I used in day-to-day work and only needed to use ^G to get to the rest of them on fairly rare occasions.
On 7/20/22 11:48, Tim via users wrote:
Now it's a welcome surprise to find someone who doesn't need step by step guiding through an entire process.
I did telephone tech support for an ISP for about a decade and worked with large numbers of people who didn't know how to do anything with their computer except the basics and didn't want to. In general, the worst offenders were macUsers. With Windows users, if you tried something and it didn't quite work, you could tell them to go back to a certain screen, and they'd usually know what to do. With macUsers, if you tell them to repeat an action they took two minutes ago, they've already forgotten it because, of course, they'd never ever need to do it again.
I remember furiously inserting `g$' on my file until I remembered I'm using nano.
Anyway vi commands are easier to remember compared to Emacs, by a margin.
On 7/21/22 12:00 AM, Joe Zeff wrote:
On 7/20/22 09:38, Ron Flory via users wrote:
Careful there- even today, a very large number of new Linux devices don't run a GUI at all, so a text-based editor (and knowing how to drive it) is a necessity.
Yes, but it doesn't have to be vi. One of the reasons I like nano is that most of the commands are listed at the bottom of the screen, including the one to get the rest of the list. No memorizing needed. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, 20 Jul 2022 18:43:05 +0100 Barry barry@barrys-emacs.org wrote:
At Berkeley university they liked emacs but on the VAX 11/780 only one user could be supported on BSD. The problem was found to be the I/O rate from single char input and echoing.
In response to the need to support 30 students on the VAX they needed to drop the I/O rate. This resulted in VI and matching kernel terminal ioctl changes to allow lines of text to be input as a single I/O. There is a usenix paper that describes this in detail that came out a long long time ago.
Now you have an army of graduates that know VI and use it at work. The rest is history…
But when I worked at DEC we used Goslings emacs on VMS and had enough hardware to support emacs. I still maintain it as Barry’s Emacs.
I first encountered UNIX after years of using VMS, IBM mainframes, and a plethora of personal computers. They ALL had editors better than vi. Who writes an editor where the arrow keys don’t work!
I use emacs -nw or mg when I need a terminal editor.
Jim
On 7/22/22 13:34, James Szinger wrote:
I first encountered UNIX after years of using VMS, IBM mainframes, and a plethora of personal computers. They ALL had editors better than vi. Who writes an editor where the arrow keys don’t work!
To be fair, when vi was written, there were no arrow keys. Still, I my personal opinion is "Fi on vi!"
On 7/22/22 13:34, James Szinger wrote:
I first encountered UNIX after years of using VMS, IBM mainframes, and a plethora of personal computers. They ALL had editors better than vi. Who writes an editor where the arrow keys donât work!
To be fair, when vi was written, there were no arrow keys. Still, I my personal opinion is "Fi on vi!"
When vi was written it was called the number six.
--- Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25.
Am 22.07.2022 um 21:56 schrieb Joe Zeff joe@zeff.us:
To be fair, when vi was written, there were no arrow keys. Still, I my personal opinion is "Fi on vi!“
there is a reason why vi remains so popular and widespread among professional system administrators. And they have only a weary smile for this editor war. But it's nothing for the casual or wannabe administrator. That's why Fedora has switched to Nano as default, except for Fedora Server, where for those good reasons vi is the first choice.
So to each their own.
On 7/22/22 16:14, Peter Boy wrote:
there is a reason why vi remains so popular and widespread among professional system administrators.
And that reason is?
And they have only a weary smile for this editor war.
It's not an editor war, at least from my POV. I'm only trying to get some of the other people here understand that there isn't One True Editor, and that people writing walkthroughs/HOWTOs should do so in an editor-agnostic fashion.
On Fri, Jul 22, 2022 at 2:35 PM James Szinger jszinger@gmail.com wrote:
On Wed, 20 Jul 2022 18:43:05 +0100 Barry barry@barrys-emacs.org wrote:
At Berkeley university they liked emacs but on the VAX 11/780 only one user could be supported on BSD. The problem was found to be the I/O rate from single char input and echoing.
In response to the need to support 30 students on the VAX they needed to drop the I/O rate. This resulted in VI and matching kernel terminal ioctl changes to allow lines of text to be input as a single I/O. There is a usenix paper that describes this in detail that came out a long long time ago.
Now you have an army of graduates that know VI and use it at work. The rest is history…
But when I worked at DEC we used Goslings emacs on VMS and had enough hardware to support emacs. I still maintain it as Barry’s Emacs.
I first encountered UNIX after years of using VMS, IBM mainframes, and a plethora of personal computers. They ALL had editors better than vi. Who writes an editor where the arrow keys don’t work!
Someone with a serial terminal with no arrow keys, or arrow keys that did not work consistently between differing terminal types.
And the design intent was to allow one to hit esc and use hjkl as arrow keys without removing your hands from the home keys so one could continue touch typing.
Joe Zeff:
And if vi is number six, who is Number One?
I am not a number!!
On Fri, Jul 22, 2022 at 05:42:44PM -0500, Roger Heflin wrote:
On Fri, Jul 22, 2022 at 2:35 PM James Szinger jszinger@gmail.com wrote:
...
I first encountered UNIX after years of using VMS, IBM mainframes, and a plethora of personal computers. They ALL had editors better than vi. Who writes an editor where the arrow keys don’t work!
Someone with a serial terminal with no arrow keys, or arrow keys that did not work consistently between differing terminal types.
And the design intent was to allow one to hit esc and use hjkl as arrow keys without removing your hands from the home keys so one could continue touch typing.
There was another aspect of the hjkl pattern. The control equivalents of those keys ^H, ^J, ^K, ^L, were the codes that moved the cursor on the adm3a terminal Bill Joy was using when he first developed the visual mode of his ex editor.
jl
Am 23.07.2022 um 00:34 schrieb Joe Zeff joe@zeff.us:
On 7/22/22 16:14, Peter Boy wrote:
there is a reason why vi remains so popular and widespread among professional system administrators.
And that reason is?
The incredibly rich feature set provides an effective processing option for (nearly) every administration task, no matter how complex. This is unmatched by any other editor included in Fedora.
… and that people writing walkthroughs/HOWTOs should do so in an editor-agnostic fashion.
I like that idea. On the other hand, hardly any how-to writes with a specific editor in mind (e.g. "Press :wq to save and quit) and the mention of a specific program name is more of a placeholder that can/must be adapted just like other file- oder variable names in the sample code.
E.G. instead of
[…]# vi /etc/NetworkManager/system-connections/enp1s0.nmconnection
I would have to write
[…]# {YOUR_EDITOR} /etc/NetworkManager/system-connections/{IF_NAME}.nmconnection
It’s possible, but is it worth it? The lines are usually too short anyway, every letter counts, and it doesn't make it easier to read, and more effort with copy & paste.
On 7/23/22 00:10, Peter Boy wrote:
I like that idea. On the other hand, hardly any how-to writes with a specific editor in mind (e.g. "Press :wq to save and quit) and the mention of a specific program name is more of a placeholder that can/must be adapted just like other file- oder variable names in the sample code.
And how many Linux newcomers do you think realize that?
Am 23.07.2022 um 08:33 schrieb Joe Zeff joe@zeff.us:
and the mention of a specific program name is more of a placeholder that can/must be adapted just like other file- oder variable names in the sample code.
And how many Linux newcomers do you think realize that?
All the texts I’m aware of describe it at the beginning and/or repeat it in the text again and again.
Nevertheless, what’s your specific suggestion? How should we do it this specifically in Fedora documentation? How can we accomplish this under the condition of good readability?
I’m the author of Fedora docs style guide currently under development, see https://docs.fedoraproject.org/en-US/fedora-docs/contributing/style-guide/ and some discussion at https://discussion.fedoraproject.org/t/fedora-documentation-style-guide-1st-...
So, please cheer up and contribute.
On Sat, 2022-07-23 at 01:03 -0400, Jon LaBadie wrote:
On Fri, Jul 22, 2022 at 05:42:44PM -0500, Roger Heflin wrote:
On Fri, Jul 22, 2022 at 2:35 PM James Szinger jszinger@gmail.com wrote:
...
I first encountered UNIX after years of using VMS, IBM mainframes, and a plethora of personal computers. They ALL had editors better than vi. Who writes an editor where the arrow keys don’t work!
Someone with a serial terminal with no arrow keys, or arrow keys that did not work consistently between differing terminal types.
And the design intent was to allow one to hit esc and use hjkl as arrow keys without removing your hands from the home keys so one could continue touch typing.
There was another aspect of the hjkl pattern. The control equivalents of those keys ^H, ^J, ^K, ^L, were the codes that moved the cursor on the adm3a terminal Bill Joy was using when he first developed the visual mode of his ex editor.
IIRC this is also where the termcap database originated, in order to allow adapting to the multiple proprietary control schemes implemented by terminal manufacturers.
poc
On Sat, 2022-07-23 at 11:00 +0200, Peter Boy wrote:
Nevertheless, what’s your specific suggestion? How should we do it this specifically in Fedora documentation? How can we accomplish this under the condition of good readability?
My inclination is to go along the lines of, by way of mock example:
e.g. Edit the /etc/hosts file to put the following lines in it...
Close by the first example, you include a link or two to starter pages for using a few of the common editors (which show you how to edit, save, basic features, of the editor with a generic example that every page suggesting you edit a file can link to). Or a link to a single "editing text files" starter page, and *it* gives primers on two or three of the usual editors.
I know one-page solutions are often easier for people with problems to solve, but it does involve a lot of repeating the same info. The converse example is the pages about verifying your download before installing the new release of the OS. There's about three pages of badly cross-referenced info about verifying the thing you're going to use the verify the downloaded ISO. On my webserver, that's where I'd be writing a page on a specific problem, and that page would insert general instructions from other common sources, creating a one-page answer from several pages of instructions.
For a lot of people, they're familiar with using their usual text editor, the help pages they're looking up are about a specific problem they're trying to solve (like the first time you ever customise dhcpd.conf). All we need to know is which files to edit, and pointing in the right direction of what to put in them. Step by step recipes tend to not teach you enough, and may be too singled-minded to deal with your version of the problem.
The problem with users never touching something like vi is that one day they may have to use it, it may be the only thing preinstalled on a problematic system. And there are specific instances of vi, like visudo, which solves a particular problem that other editors do not (man visudo goes into what's special about it). So even if you don't use it day to day, it's good to have a rudimentary knowledge to do basic editing, at least.
On Sat, 2022-07-23 at 20:56 +0930, Tim via users wrote:
The problem with users never touching something like vi is that one day they may have to use it, it may be the only thing preinstalled on a problematic system. And there are specific instances of vi, like visudo, which solves a particular problem that other editors do not (man visudo goes into what's special about it). So even if you don't use it day to day, it's good to have a rudimentary knowledge to do basic editing, at least.
Despite the name, visudo can be used with any editor. The man page gives an example.
poc
On Fri, 22 Jul 2022 13:56:13 -0600 Joe Zeff joe@zeff.us wrote:
On 7/22/22 13:34, James Szinger wrote:
I first encountered UNIX after years of using VMS, IBM mainframes, and a plethora of personal computers. They ALL had editors better than vi. Who writes an editor where the arrow keys don’t work!
To be fair, when vi was written, there were no arrow keys. Still, I my personal opinion is "Fi on vi!"
The IBM 3277 was released in 1971 and had arrow keys. The DEC VT05, from 1970 and the VT52, released in 1975, had arrow keys. Later models, such as the VT100, VT220, and IBM PC had arrow keys. The ex editor is from 1976, but the vi name dates from 1979.
By the mid 1980s arrow keys were ubiquitous, but vi still couldn’t cope with them.
Jim
On Sat, 23 Jul 2022 08:29:09 -0600 James Szinger wrote:
The IBM 3277 was released in 1971 and had arrow keys.
If I'm recalling though, the IBM terminals were data entry things designed exclusively for form fill out. Entire screens had to be redrawn to change one character. (Or at least many of the models were like that - maybe not all of them).
For quite a while in the 70s I found it easier to edit programs on punched cards than any of the online "solutions" available at the time.
Heck, you could cut & paste by grabbing a chunk of cards and moving them in the deck. You could insert or delete characters by "duplicating" the card and holding down one of the cards really hard so it couldn't move when the keypunch tried to advance it.
Loads of fun :-).
(Have I officially killed this silly thread now?)
On Sat, Jul 23, 2022 at 08:29:09AM -0600, James Szinger wrote:
On Fri, 22 Jul 2022 13:56:13 -0600 Joe Zeff joe@zeff.us wrote:
On 7/22/22 13:34, James Szinger wrote:
I first encountered UNIX after years of using VMS, IBM mainframes, and a plethora of personal computers. They ALL had editors better than vi. Who writes an editor where the arrow keys don’t work!
To be fair, when vi was written, there were no arrow keys. Still, I my personal opinion is "Fi on vi!"
The IBM 3277 was released in 1971 and had arrow keys. The DEC VT05, from 1970 and the VT52, released in 1975, had arrow keys. Later models, such as the VT100, VT220, and IBM PC had arrow keys. The ex editor is from 1976, but the vi name dates from 1979.
By the mid 1980s arrow keys were ubiquitous, but vi still couldn’t cope with them.
Certainly vi would have problems with a 3277 as its cursor keys worked locally, sending nothing to the computer.
In a closed environment like DECs, it is not surprising that programs written for that environment, written for hardware developed by DEC, to be able to use cursor keys spec'ed by DEC.
In 1979/1980 I was using vi and cursor keys on adm3a+'s, vt100's, various Wyse terminals and on my Sol-20 S100 bus computer using a terminal driver I wrote to learn machine language programming.
On 7/23/22 03:00, Peter Boy wrote:
All the texts I’m aware of describe it at the beginning and/or repeat it in the text again and again.
Nevertheless, what’s your specific suggestion? How should we do it this specifically in Fedora documentation? How can we accomplish this under the condition of good readability?
"Use a text editor to..."
On 7/23/22 05:26, Tim via users wrote:
The problem with users never touching something like vi is that one day they may have to use it, it may be the only thing preinstalled on a problematic system. And there are specific instances of vi, like visudo, which solves a particular problem that other editors do not (man visudo goes into what's special about it). So even if you don't use it day to day, it's good to have a rudimentary knowledge to do basic editing, at least.
Guess what: visudo uses your VISUAL or EDITOR environment variable to use your preferred editor. On any system that I have to work with that will be set to nano, both for me and for root.
On Sat, 23 Jul 2022 20:56:18 +0930 Tim via users users@lists.fedoraproject.org wrote:
On Sat, 2022-07-23 at 11:00 +0200, Peter Boy wrote:
Nevertheless, what’s your specific suggestion? How should we do it this specifically in Fedora documentation? How can we accomplish this under the condition of good readability?
My inclination is to go along the lines of, by way of mock example:
e.g. Edit the /etc/hosts file to put the following lines in it...
...
The problem with users never touching something like vi is that one day they may have to use it, it may be the only thing preinstalled on a problematic system. And there are specific instances of vi, like visudo, which solves a particular problem that other editors do not (man visudo goes into what's special about it). So even if you don't use it day to day, it's good to have a rudimentary knowledge to do basic editing, at least.
export SUDO_EDITOR=${EDITOR}
Tim:
there are specific instances of vi, like visudo, which solves a particular problem that other editors do not (man visudo goes into what's special about it).
Patrick O'Callaghan:
Despite the name, visudo can be used with any editor. The man page gives an example.
Yes, you can use a different editor, but I think you lose the features it offered you.
On Sun, 2022-07-24 at 04:19 +0930, Tim via users wrote:
Tim:
there are specific instances of vi, like visudo, which solves a particular problem that other editors do not (man visudo goes into what's special about it).
Patrick O'Callaghan:
Despite the name, visudo can be used with any editor. The man page gives an example.
Yes, you can use a different editor, but I think you lose the features it offered you.
I haven't used it but I'm not sure that's true. It applies locking to the /etc/sudoers file, and does a syntax check before installing the edited version, but neither of those things would depend on the specific editor.
poc
On Fri, Jul 22, 2022 at 7:34 PM Joe Zeff joe@zeff.us wrote:
On 7/22/22 16:14, Peter Boy wrote:
there is a reason why vi remains so popular and widespread among
professional system administrators.
And that reason is?
And they have only a weary smile for this editor war.
It's not an editor war, at least from my POV. I'm only trying to get some of the other people here understand that there isn't One True Editor, and that people writing walkthroughs/HOWTOs should do so in an editor-agnostic fashion.
In user forums there has been an increase in the number of (often hard to analyze) problems that end up being caused by overly helpful editors that replace ASCII characters with unicode glyphs (different space characters, opening/closing quotes, different dash/minus) in configuration files. Some advice on the choice of editor and ways to detect non-ASCII characters could avoid this class of problems.
Am 23.07.2022 um 21:24 schrieb George N. White III gnwiii@gmail.com:
On Fri, Jul 22, 2022 at 7:34 PM Joe Zeff joe@zeff.us wrote:
It's not an editor war, at least from my POV. I'm only trying to get some of the other people here understand that there isn't One True Editor, and that people writing walkthroughs/HOWTOs should do so in an editor-agnostic fashion.
In user forums there has been an increase in the number of (often hard to analyze) problems that end up being caused by overly helpful editors that replace ASCII characters with unicode glyphs (different space characters, opening/closing quotes, different dash/minus) in configuration files. Some advice on the choice of editor and ways to detect non-ASCII characters could avoid this class of problems.
Yes, thanks. I hadn't even thought of that in terms of our documentation. It’s an important fact we should explain.
Until now I think it’s only GUI editors that do that. What about text console editors? I know, vim, nano, and (hopefully) emacs don’t do that. Is there a list of potential problematic editors?
On Sat, Jul 23, 2022 at 5:52 PM Peter Boy pboy@uni-bremen.de wrote:
Am 23.07.2022 um 21:24 schrieb George N. White III gnwiii@gmail.com:
On Fri, Jul 22, 2022 at 7:34 PM Joe Zeff joe@zeff.us wrote:
It's not an editor war, at least from my POV. I'm only trying to get some of the other people here understand that there isn't One True Editor, and that people writing walkthroughs/HOWTOs should do so in an editor-agnostic fashion.
In user forums there has been an increase in the number of (often hard
to
analyze) problems that end up being caused by overly helpful editors that replace ASCII characters with unicode glyphs (different space
characters,
opening/closing quotes, different dash/minus) in configuration files.
Some
advice on the choice of editor and ways to detect non-ASCII characters could avoid this class of problems.
Yes, thanks. I hadn't even thought of that in terms of our documentation. It’s an
important fact we should explain.
It could be useful to provide a "Know your editor" document explaining some of the issues and workarounds/solutions. Choice of fonts should be mentioned: use a font where 1 (one), l (lower case L), O (capital o), and 0 (zero) look different.
Until now I think it’s only GUI editors that do that. What about text console editors?
I know, vim, nano, and (hopefully) emacs don’t do that. Is there a list of
potential
problematic editors?
In my field there are many macOS users using linux for the heavy lifting on headless servers. Apple TextEdit is a big offender for mangling ASCII files. There are many similar editors used outside N. America and Western Europe whose names I never recognize (I assume because they do have good support for the user's native language). Many younger users started out on smart phones at an early age and will go to great lengths to avoid using a terminal. In my field, many users do linux hosted work in web browsers using Jupyter, Rstudio, and the like, and will transfer ASCII files to their desktop to edit them even if they are fixing a 1-letter typo.
Maybe users should be given choices depending on their familiarity with regular expressions, terminals, POSIX shells, etc.
It should also be noted that many editors are available on multiple platforms, so those who are required by enterprise policies to have Windows or macOS can find text editors they can use on both linux and the platform required to receive directives from on high..
On Sat, 2022-07-23 at 20:56 -0300, George N. White III wrote:
Choice of fonts should be mentioned: use a font where 1 (one), l (lower case L), O (capital o), and 0 (zero) look different.
And the | symbol!
That kind of thing had long been a bugbear of mine until I started using Linux and sensible font choices were already preselected on the terminal. I'd seen cases were Ill and 111 were near indistinguishable.
-
alan＠clueserver.org -
Barry -
Bob Marcan -
Dave Stevens -
George N. White III -
James Szinger -
Joe Zeff -
John Mellor -
Jon LaBadie -
Jonathan Billings -
Lily White -
Michael D. Setzer II -
Patrick O'Callaghan -
Peter Boy -
R. G. Newbury -
Roger Heflin -
Ron Flory -
Tim -
Tom Horsley