Bug 39386

Summary:	RFE: systemctl should assume ".service" extension for units if no extension is provided
Product:	systemd	Reporter:	Denis Washington <denisw>
Component:	general	Assignee:	Lennart Poettering <lennart>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Denis Washington 2011-07-19 14:28:36 UTC

Every time I use systemctl to (re-)start services, I am extremely annoyed that I need to always type ".service" after the service name. Instead of, e.g.:

 systemctl restart httpd.service

I would love to just have to write:

 systemctl restart httpd

I know there are also other types unit files with different extensions, but given that services are the most common type of units one typically deals with, I think it would be reasonable for systemctl to automatically interpet a unit name without extension as if an ".service" extension was specified.

Comment 1 Zbigniew Jedrzejewski-Szmek 2012-07-21 06:33:07 UTC

I agree with the sentiment...

What about being a little smarter, and looking through a list of types appropriate to given command following rules similar to bash-completion? Similar in the sense that rules in systemctl could be slightly simplified, to err on the side of proposing to many units.

Comment 2 Lennart Poettering 2012-07-28 11:21:33 UTC

I think we should really try hard not to be too smart here. I.e. appending ".service" if no suffix is giving I think is a good idea, because it is very deterministic, and can be done offline, on other hosts (which is nice for systemctl -H) and always yields the same result. But if we'd complete the name based on the unit names currently loaded things would become much less deterministic (i.e. they might end up doing different things on different setups), and couldn't be done offline anymore.

Comment 3 Lennart Poettering 2012-07-28 11:21:58 UTC

Fixed in git.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.