Ability to Print service file path

I'd be happy enough for dinitctl status to print the path. The underlying functionality is there, this would only require changes in dinitctl and not in dinit itself.

As per the contributing guidelines code changes must be done in consistent style and quality as existing code. I don't have time to mentor if your skills aren't up to the task, but if they are, this would be a suitable change to be included before the 1.0 release.

I'd be happy enough for dinitctl status to print the path. The underlying functionality is there, this would only require changes in dinitctl and not in dinit itself.

As per the contributing guidelines code changes must be done in consistent style and quality as existing code. I don't have time to mentor if your skills aren't up to the task, but if they are, this would be a suitable change to be included before the 1.0 release.

I'd be happy enough for dinitctl status to print the path. The underlying functionality is there, this would only require changes in dinitctl and not in dinit itself.

As per the contributing guidelines code changes must be done in consistent style and quality as existing code. I don't have time to mentor if your skills aren't up to the task, but if they are, this would be a suitable change to be included before the 1.0 release.

I made a simple program in the past.

https://git.sr.ht/~iacore/dinit-edit/tree/main/item/main.zig

dinit-edit lists all service files.

❯ dinit-edit 
boot              /home/user/.config/dinit.d/boot
...

dinit-edit <SERVICE> opens the service file in default editor.

Should dinitctl list show the file path as well?

Maybe dinit-edit could be included as a separate program with dinit. I found both functionality to be useful.

I made a simple program in the past.

https://git.sr.ht/~iacore/dinit-edit/tree/main/item/main.zig

dinit-edit lists all service files.

❯ dinit-edit 
boot              /home/user/.config/dinit.d/boot
...

dinit-edit <SERVICE> opens the service file in default editor.

Should dinitctl list show the file path as well?

Maybe dinit-edit could be included as a separate program with dinit. I found both functionality to be useful.

I made a simple program in the past.

https://git.sr.ht/~iacore/dinit-edit/tree/main/item/main.zig

dinit-edit lists all service files.

❯ dinit-edit 
boot              /home/user/.config/dinit.d/boot
...

dinit-edit <SERVICE> opens the service file in default editor.

Should dinitctl list show the file path as well?

Maybe dinit-edit could be included as a separate program with dinit. I found both functionality to be useful.

I made a simple program in the past.

https://git.sr.ht/~iacore/dinit-edit/tree/main/item/main.zig

dinit-edit lists all service files.

❯ dinit-edit 
boot              /home/user/.config/dinit.d/boot
...

dinit-edit <SERVICE> opens the service file in default editor.

Should dinitctl list show the file path as well?

Maybe dinit-edit could be included as a separate program with dinit. I found both functionality to be useful.

Should dinitctl list show the file path as well?

No, at least not by default.

Maybe dinit-edit could be included as a separate program

You can open a PR to include it under the contrib folder if you like.

Should dinitctl list show the file path as well?

No, at least not by default.

Maybe dinit-edit could be included as a separate program

You can open a PR to include it under the contrib folder if you like.

Should dinitctl list show the file path as well?

No, at least not by default.

Maybe dinit-edit could be included as a separate program

You can open a PR to include it under the contrib folder if you like.

Should dinitctl list show the file path as well?

No, at least not by default.

Maybe dinit-edit could be included as a separate program

You can open a PR to include it under the contrib folder if you like.

@davmac314 I don't think the current use of cout << represents good quality code... is there a better way to output strings?

I don't know how to get the service filename from dinit (daemon). If the list of directories dinit refers to are consistent, wouldn it be possible for dinitctl to find the service files on its own?

@davmac314 I don't think the current use of cout << represents good quality code... is there a better way to output strings?

I don't know how to get the service filename from dinit (daemon). If the list of directories dinit refers to are consistent, wouldn it be possible for dinitctl to find the service files on its own?

@davmac314 I don't think the current use of cout << represents good quality code... is there a better way to output strings?

I don't know how to get the service filename from dinit (daemon). If the list of directories dinit refers to are consistent, wouldn it be possible for dinitctl to find the service files on its own?

@davmac314 I don't think the current use of cout << represents good quality code... is there a better way to output strings?

I don't know how to get the service filename from dinit (daemon). If the list of directories dinit refers to are consistent, wouldn it be possible for dinitctl to find the service files on its own?

@davmac314 I don't think the current use of cout << represents good quality code... is there a better way to output strings?

As I mentioned above, contributed code must be consistent with existing code - which outputs via cout <<.

I don't know how to get the service filename from dinit (daemon). If the list of directories dinit refers to are consistent,

There is a request to get the service description directory for a service (by handle) and even a function in dinitctl already implemented (get_service_description_dir). You can append the name of the service to the directory to get the file.

wouldn it be possible for dinitctl to find the service files on its own?

That runs risks of being affected by changing system state. It would be better to show where the service was actually loaded from, not where it would be loaded from if it were to be reloaded now.

@davmac314 I don't think the current use of cout << represents good quality code... is there a better way to output strings?

As I mentioned above, contributed code must be consistent with existing code - which outputs via cout <<.

I don't know how to get the service filename from dinit (daemon). If the list of directories dinit refers to are consistent,

There is a request to get the service description directory for a service (by handle) and even a function in dinitctl already implemented (get_service_description_dir). You can append the name of the service to the directory to get the file.

wouldn it be possible for dinitctl to find the service files on its own?

That runs risks of being affected by changing system state. It would be better to show where the service was actually loaded from, not where it would be loaded from if it were to be reloaded now.

@davmac314 I don't think the current use of cout << represents good quality code... is there a better way to output strings?

As I mentioned above, contributed code must be consistent with existing code - which outputs via cout <<.

I don't know how to get the service filename from dinit (daemon). If the list of directories dinit refers to are consistent,

There is a request to get the service description directory for a service (by handle) and even a function in dinitctl already implemented (get_service_description_dir). You can append the name of the service to the directory to get the file.

wouldn it be possible for dinitctl to find the service files on its own?

That runs risks of being affected by changing system state. It would be better to show where the service was actually loaded from, not where it would be loaded from if it were to be reloaded now.

@davmac314 I don't think the current use of cout << represents good quality code... is there a better way to output strings?

As I mentioned above, contributed code must be consistent with existing code - which outputs via cout <<.

I don't know how to get the service filename from dinit (daemon). If the list of directories dinit refers to are consistent,

There is a request to get the service description directory for a service (by handle) and even a function in dinitctl already implemented (get_service_description_dir). You can append the name of the service to the directory to get the file.

wouldn it be possible for dinitctl to find the service files on its own?

That runs risks of being affected by changing system state. It would be better to show where the service was actually loaded from, not where it would be loaded from if it were to be reloaded now.