--no-preserve-common-sense
-
At least it tells you the grammar of the configuration file you're supposed to hand-edit reasonably concisely. I've seen far worse documentation.
-
But since it's you who posted it, it's obviously
nottrue.FTFY. Blakey's always right, especially when he's wrong.
At least it tells you the grammar of the configuration file you're supposed to hand-edit reasonably concisely.
Tip: if your configuration file requires an EBNF description for people to configure your program, maybe just stick to XML or something.
-
Tip: if your configuration file requires an EBNF description for people to configure your program, maybe just stick to XML or something.
It didn't exist yet when
sudowas first made. Changing the format now would break the old stuff. Including the GUI tools that do exist to configuresudo.Besides, XML isn't all that good either. It's terribly verbose and also more complicated, and besides, you'd still need a description of how it works. EBNF can actually be fully explained to a novice in two paragraphs.
You can say that you can expect people to know XML already, but
- even most people who think they know XML still don't really know XML,
- most people will also know the basics of EBNF well enough already.
-
It didn't exist yet when sudo was first made.
Hence "or something". Were there absolutely no standards back then? INI files? Hell, even CONFIG.SYS could be edited by a fourth-grader.
Now it's a lost cause, obviously. But when picking standards for things like your config file, or anything the user is going to use really, if you can't explain them in a few paragraphs of simple English text, you need another standard.
Besides, XML isn't all that good either. It's terribly verbose and also more complicated, and besides, you'd still need a description of how it works. EBNF can actually be fully explained to a novice in two paragraphs.
But you can expect people to know XML already, yes. Or at least know enough of it to tweak a config file, you don't need to remember every single quirk of the spec for that.
And while you maybe can explain EBNF quickly, it's still hard to follow, and utterly pointless. Just tell the user how to perform tasks.
most people will also know the basics of EBNF well enough already.
Dunno what kind of crowd you're hanging around with, but my knowledge of EBNF is hazy at best, and I had it in college.
When you're writing software, you want to make it easy to use for the end-user. Slapping a formal grammar description of your config file is like starting your PC's instruction manual with a section on wiring and chip datashets. The user doesn't care. The user wants to boot the PC, not figure it out from the wiring diagram.
-
It didn't exist yet when sudo was first made.
But common sense did. [spoiler]...or did it?[/spoiler]Besides, XML isn't all that good either. It's terribly verbose and also more complicated, and besides, you'd still need a description of how it works.
The point is, something as bad as XML would still be better.
-
Haven't JSON and YAML become the new standards for config files?
-
When you're writing software, you want to make it easy to use for the end-user. Slapping a formal grammar description of your config file is like starting your PC's instruction manual with a section on wiring and chip datashets. The user doesn't care. The user wants to boot the PC, not figure it out from the wiring diagram.
It's not like putting wiring diagrams in a PC's manual, it's more like putting wiring diagrams in an Arduino's manual.
It was never meant for the end user. If you are a sysadmin, you ought to read the documentation of the tools you use. If you are not a sysadmin or power user, you should never need to touch this file.
If the machine in question is not serving multiple users, and/or you are not its administrator, you will not, ever, need to touch this file.
Really, end users shouldn't have to hand-edit any configuration files ever. But Linux was never really meant for the end user. It's like buying an ATV in kit form in order to drive your kids to school, that's simply not what it was made to do. It has its strengths, but this is not one of them.
That said, in Ubuntu you can do all the basic things now using the GUI tools.
-
-
Furthermore,
sudodoesn't necessarily elevate permissions, as weird as it seems to the Blakeys of the world.sudo -u nobody ls /path/to/samba/shareIt annoys me you can't recursively delete without force.
I'm pretty sure thatrm -rdoes what it says on the tin.
-
I'm pretty sure that rm -r does what it says on the tin.
Hm, then why do I always use -rf ponders
I'm certain I got annoyed by the default behavior of -r.
-
I think it prompts you a shitton.
-
When you're writing software, you want to make it easy to use for the end-user.
But if your user (back when sudo was written) is a full-time sysadmin? You don't expect a fourth-grader to write SQL queries.
-
That's
rm -ir?
-
But if your user (back when sudo was written) is a full-time sysadmin? You don't expect a fourth-grader to write SQL queries.
If something can be made simple, why not make it simple?
-
-iprompts for every single file.-fmentions it never prompts. ISTR without either, it prompts annoyingly often when in-rmode but not for every single file.
-
Hm, then why do I always use -rf ponders
Likewise.
It's eitherrmor, if folders are involved,rm -rfdespite knowing that thefis unrelated to folders.
-
ISTR without either, it prompts annoyingly often when in -r mode but not for every single file.
it'll prompt for readonly files without -i or -f.
if you have a lot of readonly files/directories (i'm looking at you
.svn/) that'll prompt an annoying large amount of time
-
(i'm looking at you .svn/)
Thaaaat's probably exactly what I'm remembering. I do a lot of deleting working copies in linux.
-
I've used
rm -fin scripts on occasion. Some of our shell scripts run in automatically-abort-on-exit mode (-e?) and usingrm -fthen basically means 'if the file doesn't exist that's OK' without having to write that down with an if.
-
$file = 'path/to/delete'; touch $file && rm $file; :-P
-
-
If you're scripting it, that's a different story.
Although I remember hearing about scripts in the past that assumed an environment variable would be present and trashed files in the root directory when it wasn't set...
-
Although I remember hearing about scripts in the past that assumed an environment variable would be present and trashed files in the root directory when it wasn't set...
-
Changing the format now would break the old stuff.
Why?
Oh right: because shitty open source developers use the CLI as an API.
-
What? No, they.. what?
Programs are allowed to edit files, you know...
And
/etc/sudoersis a file. Sure, you could say "support both formats!" but then you get systemd. Whether that is a bad thing is left as an exercise for the reader.
-
But if your user (back when sudo was written) is a full-time sysadmin? You don't expect a fourth-grader to write SQL queries.
You don't start a SQL for Dummies book with a formal grammar description of SQL, either.
-
It's not like putting wiring diagrams in a PC's manual, it's more like putting wiring diagrams in an Arduino's manual.
I don't care how the Arduino board is wired either. I care where my grumpy pins are and how to pull them up or down.
It was never meant for the end user. If you are a sysadmin, you ought to read the documentation of the tools you use. If you are not a sysadmin or power user, you should never need to touch this file.
A sysadmin is an end user. He's also a human that has to learn how to use the tool like any other human.
That a tool is designed for power users doesn't mean having a shitty documentation is a non-issue, since "they're sysadmins, they'll figure it out".
-
back when the sudoers file format was designed it was generally understood that sysadmins knew their ass from an atlas when it came to how computers work.
i'm still not sure if that was a good thing or not... but i for one am tired of cleaning up servers after the web teams "sysadmin" gets his mitts on them.
-
back when the sudoers file format was designed it was generally understood that sysadmins knew their ass from an atlas when it came to how computers work.
So? "Knowing how the computer works" and "enjoying wading through obtuse documentation" are totally different things.In fact, most people who fall into the first category don't fall into the second, and most people who fall into the second category are thinking themselves more clever than they are.
-
i find people who fall into the "it should just work why do i even have to read the documentation" are the most dangerous of all when they get any sort of admin rights. Mostly because they know better than the developers of the software.
Yes the developers of the software may have used a less than optimal way of doing things, yes it may very well suck, but if you don't read the documentation to find out why it does what it does and just go on "how it should work" you're just going to trash your server. and if you're lucky it's only one server and a non mission critical one at that.
there's a reason why the official policy (from before i even joined the company) at our place is:
"If you have local admin rights to your computer the only action Helpdesk will take when you report computer issues will be to reformat and reimage your computer. there will be no exceptions. Not even for board members."
-
"If you have local admin rights to your computer the only action Helpdesk will take when you report computer issues will be to reformat and reimage your computer. there will be no exceptions. Not even for board members."
Boy, that must suck if you report a problem that turns out not to be your fault. My office's exchange server is in another state, and every once in a while we lose connectivity. I'd hate to report that and have my computer wiped.
(Of course, that would probaby cost me three days to rebuild it.)
-
well, to be fair they're not that dogmatic about it. they deliberately wrote the policy that dogmatic to discourage you from even asking for local admin rights in the first place.
if you report an issue with the exchange server and have local admin they'll look at the exchange server, but if the server's good and it's still not working for you your options are: let them wipe and reimage or try to solve it yourself.
-
A good tool works exactly as it should work. If it doesn't, it's buggy and you need a better tool.
And I'm not sure how this relates to the discussion at hand, which is not "I don't wanna read the documentation", but "I read the documentation, and it sucks".
-
well, to deobfuscate my point:
you're choices at this point are:
- read the documentation and deal with it
- write better documentation and get it accepted by the package maintainers
- write better config file format and get it accepted by package maintainers
- write a replacement application and get it accepted by linux distributions as a replacement for sucky package
- start using a different operating system that doesn't need/use the sucky package
-
well, to be fair
successful! 
ETA: note absence of flagging for whoosh...as far as you know.
( hey, look, it's the #2 )
-
back when the sudoers file format was designed it was generally understood that sysadmins knew their ass from an atlas when it came to how computers work.
That doesn't mean they enjoy pain. I know how lawns work, I still don't enjoy mowing mine.
-
Fail on unset variables is -u
-
-
-
-
Why would I? They're not me.
-
I'm not sure why that's relevant.
-
Why would I? They're not me.
That seems kind of solipsistic, and implies a deep-seated masochism, the way you keep imagining up stupid people. Maybe you should imagine up smarter people to keep you occupied as you wend your way, alone, through the universe.
