[systemd-devel] Antw: Re: Antw: Re: Unexpected behaviour not noticed by systemctl command

[Ulrich Windl]

>>> Mike Gilbert <floppym at gentoo.org> schrieb am 10.10.2019 um 21:09 in Nachricht
<CAJ0EP40swLG-tOPdBfXY3H=VK6SYjRkAHwrn_kcZ7DZ-x7MyLQ at mail.gmail.com>:
> On Thu, Oct 10, 2019 at 4:46 AM Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>
>> Andy Pieters wrote on 08/10/2019 11:41:
>> > forget about the stop.  that was the context into which I discovered it.
>> >
>> > I am not saying stop should disable I am saying stop should not accept
>> > now and silently ignore it
>>
>>
>> FWIW I'd tend to agree with you.
>>
>>
>> [colin at jimmy Channel (master)]$ sudo systemctl stop --fodslkjsf httpd
>>
>> systemctl: unrecognized option '--fodslkjsf'
> 
> I think this error checking happens automatically with getopt_long(3).

Actually the example was bad, because it mixed a syntax error with a semantic error. Well actually the semantic error could be mapped to a syntax error as well (but not via getopt alone), but nobody will actually go that way.

The issue was that a valid option (syntax) that has no effect with the combination of other options and parameters (semantic) was not flagged (warning, error, notice) in any way.

> 
>> [colin at jimmy Channel (master)]$ sudo systemctl stop --now httpd
>>
>> [colin at jimmy Channel (master)]$
>>
>>
>> If --now is irrelevant to the verb, then it should be the equiv of an
>> unrecognized option.
>>
>> Bonus points if it issued a git-style "did you mean systemctl disable
>> --now ..." error response.
> 
> This would not be caught by getopt_long(3) because it has no way of
> knowing about "verbs" or the options that are valid for them.
> 
> This kind of error checking would require special-case coding in the
> systemctl code. This is more likely to happen if someone submits a PR
> for it.
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel