Description of problem: Given that we seem to be evolving into to long names for admins/users to easily remember like "RestartNormalExitStatus" ( DoesThisReallyHaveToBeThisLong )we should start supporting acronyms as in "RestartNormalExitStatus=" would become "RNES=" etc thus reducing and simplify things a bit... Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: For fun read http://www.codinghorror.com/blog/2006/08/the-magical-number-seven-plus-or-minus-two.html
I don't think this is good idea, I would rather have hard-to-write easy-to-read unit files. I can't image something like TOS=5 RNES=6 DTRHTBTL=yes
RSEKNAAFNAB - Readable self-explanatory key names are a feature not a bug. :)
I agree with Lukáš and Kay.
Not so fast =) Then you need to fix either to make upper case and lower case irrelevant when used in units and or provide proper hints in error msg as in This "Unknown lvalue 'Environmentfile' in section 'Service'. Ignoring" Would become this... "Unknown lvalue 'Environmentfile' in section 'Service'. Try using EnvironmentFile in $UNIT instead" Or something similar..
Also, s/lvalue/key/ if you're talking about uservisible messages.
(In reply to comment #4) > "Unknown lvalue 'Environmentfile' in section 'Service'. Try using > EnvironmentFile in $UNIT instead" We should just parse the keys insensitively to case. [Changing bug title, because this is different from what was requested originally.] (In reply to comment #5) > Also, s/lvalue/key/ if you're talking about uservisible messages. Yes. "lvalue" is C jargon.
On Unix most things are case-sensitive, such as file names, environment variables, shell constructs, ... I think it would be a bad idea deviating from that rule for unit files, given that they don't exist in a vacuum really, and almost all other configuration files on Linux are case-sensitive, as well. We had a similar request for making journal fields case-insensitive, but decided not to in order to follow the scheme of Unix env vars which they are modelled after and which are case-sensitive as well. So, I think in order to follow the rule of least surprises we should do here what other Unix tools do, was well, and stick to case-sensitivity. Hence will close the bug now. Of course, I can be convinced otherwise, if you can show me that a non-trivial amount of other unix daemons support case-insensitive unit files. i.e. if you can find more than a handful of well established unix daemons such as apache, mysql, rsyslog, inetd, ... which can do insensitive config files please reopen the bug and we'll reinvestigate the situation. Thanks! Sorry!
Have we fixed the error msg handling?
(In reply to comment #7) > almost all other configuration files on Linux are case-sensitive, as well. Case (in)sensitivity might be correlated with the keyword naming style the config files use. Few users are tempted to type upper case characters in config files which have keys_using_underscores, so in these files case-sensitivity rarely surprises anyone. In config files with CamelCaseKeys the potential for the user to make a case typo is greater. It's not like we gain anything by being case-sensitive. Surely we aren't going to introduce two options with names differing only by case.