[systemd-devel] Antw: Re: Can I enable/disable a target?

[Ulrich Windl]

>>> Lennart Poettering <lennart at poettering.net> schrieb am 13.05.2019 um 09:35
in
Nachricht <20190513073539.GA9036 at gardel-login>:
> On Mo, 13.05.19 08:25, Ulrich Windl (Ulrich.Windl at rz.uni‑regensburg.de)
wrote:
> 
>> >> Whenever I try to enable or disable a target (that exists), I get
>> >> "Failed to execute operation: No such file or directory". What file
>> >> or directory, please? Or what is the command trying to say?
>> >
>> > Well, "systemctl enable" could not find the target unit file in the
>> > directories it searches for them. Where did you place the unit file?
>>
>> Meanwhile I know: My generator was using bash, and for more reliability I
>> dared to add "set ‑u". As it turned out my version of Bash has a bug that
>> causes false reports of unset variables with arrays, so the generator
failed
>> (the thread of handling exit codes of generators). As a consequence of
that,
>> the unit file wasn't created any more (which I hadn't realized at that 
> time).
>>
>> But still combining the concepts "operation" and "No such file or
directory"
>> is odd: An operation is neither a file nor a directory.
> 
> On unix, this is typically how errors are shown. It's built into basic
> ANSI C and POSIX concepts if you so will, as "perror()" will output
> error messages like this: a short app message string followed by a
> colon and a space character, followed by the system error string. The
> system error string is one of the "errno" strings listed on the
> errno(3) man page, i.e "No such file or directory" is ENOENT. The app
> error string usually says what was attempted when the system error was
> seen.
> 
> systemd matches these UNIX semantics closely: we output error messages
> exactly the same way as everything else on UNIX: a brief string
> explaining what was attempted, followed by a colon, followed by a
> space, followed by the system error string.
> 
> I mean, sure we can always tweak error messages more, but we generally
> start from how C and UNIX suggest these works, and then improve from
> there.

Thanks for the explanation. Actually I'm programming in C for about 30 years
now. The point I had tried to address was: I think it doesn't make sense to use
the low-level error code (or message) in a high level routine. Just imagine
some find(1) command would output "No such file or directory" when no file
matched the search criteria given. IMHO ERRNO-related messages should be used
in combination of the syscall or library routine returning that error only. In
practice any error message trying to interpret the cause of an error can be
quite wrong sometimes.

(Recently I was dealing with a "parse error" that actually meant the input was
truncated, because the programmer did not expect that the input would exceed
1kB...)

> 
> I mean, we are used to being blamed for everything by everyone, but if
> you want to criticise ANSI/POSIX "perror()" style error messages on
> principle, then please direct this towards the ANSI C and POSIX
> committees first.

I guess you have three buckets there for criticism: "Justified" ,
"Unjustified", and "Don't known"

Regards,
Ulrich