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

2019-05-14 Thread Lennart Poettering
On Di, 14.05.19 11:02, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > $ find /i/dont/exist
> > find: ‘/i/dont/exist’: No such file or directory
>
> I was talking about this:
> v04:~> find /var -name no-such-file 2>&1 | grep -v ': Permission denied'
>
> it outputs nothing if no file was found. And it's similar to systemd: It looks
> for a file in different places, but eventually did not find it. Also: In your
> example above the "No such file or directory" is specific to /i/dont/exist,
> while in systemd it's unspecific (which is confusing IMHO when no file name is
> associated dire4ctly with it).

We try a few places and then propagate the error we last saw. I'd
argue that is good behaviour actually.

I mean, I am not saying that our message output couldn't be improved,
but I must say the logic of "search but propagate original error on
failure" is a good strategy, not a bad one.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-14 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 14.05.2019 um 10:55
in
Nachricht <20190514085558.GD21579@gardel-login>:
> On Di, 14.05.19 08:01, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 
> wrote:
> 
>> > 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
> 
> I don't have to image that. It's exactly what find outputs:
> 
> $ find /i/dont/exist
> find: ‘/i/dont/exist’: No such file or directory

I was talking about this:
v04:~> find /var -name no-such-file 2>&1 | grep -v ': Permission denied'

it outputs nothing if no file was found. And it's similar to systemd: It looks
for a file in different places, but eventually did not find it. Also: In your
example above the "No such file or directory" is specific to /i/dont/exist,
while in systemd it's unspecific (which is confusing IMHO when no file name is
associated dire4ctly with it).

Regards,
Ulrich

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-14 Thread Lennart Poettering
On Di, 14.05.19 08:01, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > 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

I don't have to image that. It's exactly what find outputs:

$ find /i/dont/exist
find: ‘/i/dont/exist’: No such file or directory

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-14 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 13.05.2019 um 09:35
in
Nachricht <20190513073539.GA9036@gardel-login>:
> On Mo, 13.05.19 08:25, Ulrich Windl (ulrich.wi...@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



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-13 Thread Lennart Poettering
On Mo, 13.05.19 08:25, Ulrich Windl (ulrich.wi...@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.

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.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel