That very well may be a toxic trope in the Linux community, but in this specific case, I’d say it actually is the user’s fault.
Since you believe it is the operating system’s fault, I am curious how would you like the operating system to behave differently than this, when a user interacts with a file that they have read permissions but not write permissions? What should it do? The cool thing about Linux is that if you have a better idea, you are free to implement it and make it reality, and maybe even contribute it so that others can benefit too
Personally, I feel this behavior is already the best way to go, and why it works this way in all operating systems (at least that I am aware of). I understand that it makes it easy for the user to make this mistake, but I think it would be wrong to block the user from reading a file that they have permissions to read, obviously it would be wrong to allow them to write when they do not have permission, and at least (on Linux) they are given the option to save their changes to an alternative location that they have write permissions for, and warned when opening a readonly file for editing. Is there a better way?
That is a neat idea. You can implement this change in vim (or the editor of your choice), and open a pull request to contribute it if you wish! Another idea would be for the editor to automatically re-open itself with escalated privileges, maybe caching your changes to a temporary file so that you do not lose anything (could be dangerous if editing sensitive data that shouldn’t be written to a temporary location, or if you didn’t understand that you were opening a system file that you should be cautious in [but I can think of ways to mitigate that problem, too! Like just notifying the user that the editor needs to escalate the privilege]). I think it is important to realize that none of these solutions are the responsibility of the operating system itself, but instead the programs that you are choosing to use (Notepad/vim)
Modern versions of vim do warn the user up-front when they open a readonly file for editing, which I think is a nice solution, but sure, it doesn’t explicitly offer to save the file in your home directory for you. This is still always an option though (:w ~/myfile), and if you don’t know how to use your text editor to save a file and need that level of hand-holding, then maybe you shouldn’t have sudo access in the first place?
We can’t very well honestly call Linux ‘new user friendly’ with issues like this that many of us are familiar with. Another legit attitude to have is: “what do you expect for free?”.
That very well may be a toxic trope in the Linux community, but in this specific case, I’d say it actually is the user’s fault.
Since you believe it is the operating system’s fault, I am curious how would you like the operating system to behave differently than this, when a user interacts with a file that they have read permissions but not write permissions? What should it do? The cool thing about Linux is that if you have a better idea, you are free to implement it and make it reality, and maybe even contribute it so that others can benefit too
Personally, I feel this behavior is already the best way to go, and why it works this way in all operating systems (at least that I am aware of). I understand that it makes it easy for the user to make this mistake, but I think it would be wrong to block the user from reading a file that they have permissions to read, obviously it would be wrong to allow them to write when they do not have permission, and at least (on Linux) they are given the option to save their changes to an alternative location that they have write permissions for, and warned when opening a readonly file for editing. Is there a better way?
Suggest a practical solution like saving to another directory where it can later be moved. (Notepad in Windows will do this)
That is a neat idea. You can implement this change in vim (or the editor of your choice), and open a pull request to contribute it if you wish! Another idea would be for the editor to automatically re-open itself with escalated privileges, maybe caching your changes to a temporary file so that you do not lose anything (could be dangerous if editing sensitive data that shouldn’t be written to a temporary location, or if you didn’t understand that you were opening a system file that you should be cautious in [but I can think of ways to mitigate that problem, too! Like just notifying the user that the editor needs to escalate the privilege]). I think it is important to realize that none of these solutions are the responsibility of the operating system itself, but instead the programs that you are choosing to use (Notepad/vim)
Modern versions of vim do warn the user up-front when they open a readonly file for editing, which I think is a nice solution, but sure, it doesn’t explicitly offer to save the file in your home directory for you. This is still always an option though (
:w ~/myfile), and if you don’t know how to use your text editor to save a file and need that level of hand-holding, then maybe you shouldn’t have sudo access in the first place?TBH, I rarely noticed the warning from nvim. I did get in the habit of learning when to use sudoedit though.
Sometimes I overlook the warning too, to be completely honest. But when that happens, I think “oh, my bad” and not “this is Linux’s fault!”
I’m sure that you can restyle the warning in vim so that it is more eye catching, but I’ve never tried.
We can’t very well honestly call Linux ‘new user friendly’ with issues like this that many of us are familiar with. Another legit attitude to have is: “what do you expect for free?”.
I agree that editing system configuration files with a text editor is not ‘new user friendly’, but that is true for all operating systems, no?