On Thu, Feb 01, 2018 at 10:31:55PM +0100, Rüdiger Meier wrote:
>
>
> On 02/01/18 21:22, Karel Zak wrote:
> > On Thu, Feb 01, 2018 at 05:01:19PM +0100, Ruediger Meier wrote:
> > > On Thursday 01 February 2018, Karel Zak wrote:
> > > > Now we use on many places where commands executing another command:
> > > >
> > > > execvp(argv[optind], argv + optind);
> > > > err(EXIT_FAILURE, _("failed to execute %s"), argv[optind]);
> > > >
> > > > the problem is that EXIT_FAILURE is too generic and it does not
> > > > provide any way how to detect failed exec()s.
> > >
> > > I think you did a bit too much. I assume that these exec codes are only
> > > useful for the programs which get a "command" from the user's command
> > > line. So that the user can expect the original exit code of his
> > > wanted "command" if and only if it's not 126 or 127.
> > >
> > > So for taskset(1) these exit codes are good but maybe not needed for
> > > swapon(1) or eject(1).
> >
> > I know, but it seems no problem and it's good way to consolidate the
> > error message and use the came code pattern.
>
> But isn't it just an implementation detail that we exec umount(1)? If we
> would replace that later by a library call, should we change the exit code
> again?
No, see the code. The exit code is used in our child and handled by
our waitpid(). It's not used as exit code for whole eject or swapon.
There is no visible change for users.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
