| Message ID | 20240627-fix-help-issue-v3-1-85318a3974e4@gmail.com (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Shuah Khan |
| Headers | show |
| Series | [v3] cpupower: Make help command available for custom install dir | expand |
On 6/27/24 01:49, Roman Storozhenko wrote: > When the 'cpupower' utility installed in the custom dir, it fails to > render appropriate help info for a particular subcommand: > $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor > with error message like 'No manual entry for cpupower-monitor.1' > The issue is that under the hood it calls 'exec' function with > the following args: 'man cpupower-monitor.1'. In turn, 'man' search > path is defined in '/etc/manpath.config'. Of course it contains only > standard system man paths. > Make subcommands help available for a user by setting up 'MANPATH' > environment variable to the custom installation man pages dir. That > variable value will be prepended to the man pages standard search paths > as described in 'SEARCH PATH' section of MANPATH(5). What I am asking you is what happens when you set the MANPATH before running the command? thanks, -- Shuah
On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > > On 6/27/24 01:49, Roman Storozhenko wrote: > > When the 'cpupower' utility installed in the custom dir, it fails to > > render appropriate help info for a particular subcommand: > > $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor > > with error message like 'No manual entry for cpupower-monitor.1' > > The issue is that under the hood it calls 'exec' function with > > the following args: 'man cpupower-monitor.1'. In turn, 'man' search > > path is defined in '/etc/manpath.config'. Of course it contains only > > standard system man paths. > > Make subcommands help available for a user by setting up 'MANPATH' > > environment variable to the custom installation man pages dir. That > > variable value will be prepended to the man pages standard search paths > > as described in 'SEARCH PATH' section of MANPATH(5). > > What I am asking you is what happens when you set the MANPATH before > running the command? It adds the custom search path to the beginning of the MANPATH variable. I tested this case. All works as expected. > > thanks, > -- Shuah
On 6/28/24 05:30, Roman Storozhenko wrote: > On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >> >> On 6/27/24 01:49, Roman Storozhenko wrote: >>> When the 'cpupower' utility installed in the custom dir, it fails to >>> render appropriate help info for a particular subcommand: >>> $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor >>> with error message like 'No manual entry for cpupower-monitor.1' >>> The issue is that under the hood it calls 'exec' function with >>> the following args: 'man cpupower-monitor.1'. In turn, 'man' search >>> path is defined in '/etc/manpath.config'. Of course it contains only >>> standard system man paths. >>> Make subcommands help available for a user by setting up 'MANPATH' >>> environment variable to the custom installation man pages dir. That >>> variable value will be prepended to the man pages standard search paths >>> as described in 'SEARCH PATH' section of MANPATH(5). >> >> What I am asking you is what happens when you set the MANPATH before >> running the command? > > It adds the custom search path to the beginning of the MANPATH variable. > I tested this case. All works as expected. > Let's try again. What happens if you run the command with MANPATH set and exported and then run the command. Can you send the output? thanks, -- Shuah
On Fri, Jun 28, 2024 at 9:45 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > > On 6/28/24 05:30, Roman Storozhenko wrote: > > On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > >> > >> On 6/27/24 01:49, Roman Storozhenko wrote: > >>> When the 'cpupower' utility installed in the custom dir, it fails to > >>> render appropriate help info for a particular subcommand: > >>> $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor > >>> with error message like 'No manual entry for cpupower-monitor.1' > >>> The issue is that under the hood it calls 'exec' function with > >>> the following args: 'man cpupower-monitor.1'. In turn, 'man' search > >>> path is defined in '/etc/manpath.config'. Of course it contains only > >>> standard system man paths. > >>> Make subcommands help available for a user by setting up 'MANPATH' > >>> environment variable to the custom installation man pages dir. That > >>> variable value will be prepended to the man pages standard search paths > >>> as described in 'SEARCH PATH' section of MANPATH(5). > >> > >> What I am asking you is what happens when you set the MANPATH before > >> running the command? > > > > It adds the custom search path to the beginning of the MANPATH variable. > > I tested this case. All works as expected. > > > > Let's try again. What happens if you run the command with MANPATH set and > exported and then run the command. Can you send the output? hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH /tmp/ hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor ................... man output ................... hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH /tmp/ hedin@laptop:~/prj/cpupower/install/usr$ Just in case, the following is the output of the debugging session showing how the 'MANPATH' looks like just before calling 'exec': Breakpoint 2, print_man_page (subpage=0x7fffffffe1cb "monitor") at utils/cpupower.c:84 84 { (gdb) n 89 if (!subpage) (gdb) n 93 subpage_len += strlen(subpage); (gdb) n 95 page = malloc(subpage_len); (gdb) n 96 if (!page) (gdb) n 99 sprintf(page, "cpupower"); (gdb) n 100 if ((subpage != NULL) && strcmp(subpage, "help")) { (gdb) n 101 strcat(page, "-"); (gdb) n 102 strcat(page, subpage); (gdb) n 106 if (readlink("/proc/self/exe", exec_path, PATH_MAX) > 0) { (gdb) n 107 exec_dir = strdup(exec_path); (gdb) n 108 if (!exec_dir) { (gdb) n 117 man_env = getenv("MANPATH"); (gdb) n 118 if (asprintf(&man_path, "%s/../man:%s", (gdb) n 120 setenv("MANPATH", man_path, 1); (gdb) n 121 free(exec_dir); (gdb) p man_path $1 = 0x55555556db20 "/home/hedin/prj/cpupower/install/usr/bin/../man:/tmp/" (gdb) c Continuing. process 26122 is executing new program: /usr/bin/man > > thanks, > -- Shuah > > >
On 6/29/24 04:48, Roman Storozhenko wrote: > On Fri, Jun 28, 2024 at 9:45 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >> >> On 6/28/24 05:30, Roman Storozhenko wrote: >>> On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >>>> >>>> On 6/27/24 01:49, Roman Storozhenko wrote: >>>>> When the 'cpupower' utility installed in the custom dir, it fails to >>>>> render appropriate help info for a particular subcommand: >>>>> $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor >>>>> with error message like 'No manual entry for cpupower-monitor.1' >>>>> The issue is that under the hood it calls 'exec' function with >>>>> the following args: 'man cpupower-monitor.1'. In turn, 'man' search >>>>> path is defined in '/etc/manpath.config'. Of course it contains only >>>>> standard system man paths. >>>>> Make subcommands help available for a user by setting up 'MANPATH' >>>>> environment variable to the custom installation man pages dir. That >>>>> variable value will be prepended to the man pages standard search paths >>>>> as described in 'SEARCH PATH' section of MANPATH(5). >>>> >>>> What I am asking you is what happens when you set the MANPATH before >>>> running the command? >>> >>> It adds the custom search path to the beginning of the MANPATH variable. >>> I tested this case. All works as expected. >>> >> >> Let's try again. What happens if you run the command with MANPATH set and >> exported and then run the command. Can you send the output? > > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > /tmp/ > hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ > bin/cpupower help monitor > ................... > man output > ................... > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > /tmp/ > hedin@laptop:~/prj/cpupower/install/usr$ > Is this with your patch or mainline? Can you give cut and paste the man output here for the mainline coupower without your patch? thanks, -- Shuah
On Mon, Jul 1, 2024 at 9:40 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > > On 6/29/24 04:48, Roman Storozhenko wrote: > > On Fri, Jun 28, 2024 at 9:45 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > >> > >> On 6/28/24 05:30, Roman Storozhenko wrote: > >>> On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > >>>> > >>>> On 6/27/24 01:49, Roman Storozhenko wrote: > >>>>> When the 'cpupower' utility installed in the custom dir, it fails to > >>>>> render appropriate help info for a particular subcommand: > >>>>> $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor > >>>>> with error message like 'No manual entry for cpupower-monitor.1' > >>>>> The issue is that under the hood it calls 'exec' function with > >>>>> the following args: 'man cpupower-monitor.1'. In turn, 'man' search > >>>>> path is defined in '/etc/manpath.config'. Of course it contains only > >>>>> standard system man paths. > >>>>> Make subcommands help available for a user by setting up 'MANPATH' > >>>>> environment variable to the custom installation man pages dir. That > >>>>> variable value will be prepended to the man pages standard search paths > >>>>> as described in 'SEARCH PATH' section of MANPATH(5). > >>>> > >>>> What I am asking you is what happens when you set the MANPATH before > >>>> running the command? > >>> > >>> It adds the custom search path to the beginning of the MANPATH variable. > >>> I tested this case. All works as expected. > >>> > >> > >> Let's try again. What happens if you run the command with MANPATH set and > >> exported and then run the command. Can you send the output? > > > > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > > /tmp/ > > hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ > > bin/cpupower help monitor > > ................... > > man output > > ................... > > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > > /tmp/ > > hedin@laptop:~/prj/cpupower/install/usr$ > > > > Is this with your patch or mainline? Can you give cut and paste > the man output here for the mainline coupower without your patch? The above output is from my patch. This is the output from the mainline: hedin@laptop:~/prj/cpupower/install/usr$ sudo LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor [sudo] password for hedin: No manual entry for cpupower-monitor hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH /tmp/ hedin@laptop:~/prj/cpupower/install/usr$ > > thanks, > -- Shuah >
On 7/2/24 01:40, Roman Storozhenko wrote: > On Mon, Jul 1, 2024 at 9:40 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >> >> On 6/29/24 04:48, Roman Storozhenko wrote: >>> On Fri, Jun 28, 2024 at 9:45 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >>>> >>>> On 6/28/24 05:30, Roman Storozhenko wrote: >>>>> On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >>>>>> >>>>>> On 6/27/24 01:49, Roman Storozhenko wrote: >>>>>>> When the 'cpupower' utility installed in the custom dir, it fails to >>>>>>> render appropriate help info for a particular subcommand: >>>>>>> $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor >>>>>>> with error message like 'No manual entry for cpupower-monitor.1' >>>>>>> The issue is that under the hood it calls 'exec' function with >>>>>>> the following args: 'man cpupower-monitor.1'. In turn, 'man' search >>>>>>> path is defined in '/etc/manpath.config'. Of course it contains only >>>>>>> standard system man paths. >>>>>>> Make subcommands help available for a user by setting up 'MANPATH' >>>>>>> environment variable to the custom installation man pages dir. That >>>>>>> variable value will be prepended to the man pages standard search paths >>>>>>> as described in 'SEARCH PATH' section of MANPATH(5). >>>>>> >>>>>> What I am asking you is what happens when you set the MANPATH before >>>>>> running the command? >>>>> >>>>> It adds the custom search path to the beginning of the MANPATH variable. >>>>> I tested this case. All works as expected. >>>>> >>>> >>>> Let's try again. What happens if you run the command with MANPATH set and >>>> exported and then run the command. Can you send the output? >>> >>> hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH >>> /tmp/ >>> hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ >>> bin/cpupower help monitor >>> ................... >>> man output >>> ................... >>> hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH >>> /tmp/ >>> hedin@laptop:~/prj/cpupower/install/usr$ >>> >> >> Is this with your patch or mainline? Can you give cut and paste >> the man output here for the mainline coupower without your patch? > > The above output is from my patch. > This is the output from the mainline: > hedin@laptop:~/prj/cpupower/install/usr$ sudo LD_LIBRARY_PATH=lib64/ > bin/cpupower help monitor > [sudo] password for hedin: > No manual entry for cpupower-monitor > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > /tmp/ Why is MANPATH set to /tmp? > hedin@laptop:~/prj/cpupower/install/usr$ > Okay. If you run the command as follows and get the man page for it, then I don't see a reason to add code to make it happen. sudo MANPATH=$MANPATH:path_to_custom_install_man_dir LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor thanks, -- Shuah
On Tue, Jul 2, 2024 at 9:40 AM Roman Storozhenko <romeusmeister@gmail.com> wrote: > > On Mon, Jul 1, 2024 at 9:40 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > > > > On 6/29/24 04:48, Roman Storozhenko wrote: > > > On Fri, Jun 28, 2024 at 9:45 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > > >> > > >> On 6/28/24 05:30, Roman Storozhenko wrote: > > >>> On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > > >>>> > > >>>> On 6/27/24 01:49, Roman Storozhenko wrote: > > >>>>> When the 'cpupower' utility installed in the custom dir, it fails to > > >>>>> render appropriate help info for a particular subcommand: > > >>>>> $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor > > >>>>> with error message like 'No manual entry for cpupower-monitor.1' > > >>>>> The issue is that under the hood it calls 'exec' function with > > >>>>> the following args: 'man cpupower-monitor.1'. In turn, 'man' search > > >>>>> path is defined in '/etc/manpath.config'. Of course it contains only > > >>>>> standard system man paths. > > >>>>> Make subcommands help available for a user by setting up 'MANPATH' > > >>>>> environment variable to the custom installation man pages dir. That > > >>>>> variable value will be prepended to the man pages standard search paths > > >>>>> as described in 'SEARCH PATH' section of MANPATH(5). > > >>>> > > >>>> What I am asking you is what happens when you set the MANPATH before > > >>>> running the command? > > >>> > > >>> It adds the custom search path to the beginning of the MANPATH variable. > > >>> I tested this case. All works as expected. > > >>> > > >> > > >> Let's try again. What happens if you run the command with MANPATH set and > > >> exported and then run the command. Can you send the output? > > > > > > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > > > /tmp/ > > > hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ > > > bin/cpupower help monitor > > > ................... > > > man output > > > ................... > > > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > > > /tmp/ > > > hedin@laptop:~/prj/cpupower/install/usr$ > > > > > > > Is this with your patch or mainline? Can you give cut and paste > > the man output here for the mainline coupower without your patch? > > The above output is from my patch. > This is the output from the mainline: > hedin@laptop:~/prj/cpupower/install/usr$ sudo LD_LIBRARY_PATH=lib64/ > bin/cpupower help monitor > [sudo] password for hedin: > No manual entry for cpupower-monitor > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > /tmp/ > hedin@laptop:~/prj/cpupower/install/usr$ > Based on our today's conversation the following is the output for the mainline: hedin@laptop:~/prj/cpupower/install/usr$ MANPATH="/home/hedin/prj/cpupower/install/usr/man:" LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH ............. man output ............. hedin@laptop:~/prj/cpupower/install/usr$ export MANPATH="/home/hedin/prj/cpupower/install/usr/man:" hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH /home/hedin/prj/cpupower/install/usr/man: hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor ............. man output ............. hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ sudo bin/cpupower help monitor [sudo] password for hedin: bin/cpupower: error while loading shared libraries: libcpupower.so.1: cannot open shared object file: No such file or directory As you can see we can use MANPATH for correct help invocation, unless we call it with 'sudo'. I can guess that it simply inherits the environment variables from the root shell that contains no 'MANPATH' variable set with an ordinary user. Worth mentioning this in an appropriate manpage? > > > > > thanks, > > -- Shuah > > > > > -- > Kind regards, > Roman Storozhenko
On 7/2/24 12:52, Roman Storozhenko wrote: > On Tue, Jul 2, 2024 at 9:40 AM Roman Storozhenko > <romeusmeister@gmail.com> wrote: >> >> On Mon, Jul 1, 2024 at 9:40 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >>> >>> On 6/29/24 04:48, Roman Storozhenko wrote: >>>> On Fri, Jun 28, 2024 at 9:45 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >>>>> >>>>> On 6/28/24 05:30, Roman Storozhenko wrote: >>>>>> On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@linuxfoundation.org> wrote: >>>>>>> >>>>>>> On 6/27/24 01:49, Roman Storozhenko wrote: >>>>>>>> When the 'cpupower' utility installed in the custom dir, it fails to >>>>>>>> render appropriate help info for a particular subcommand: >>>>>>>> $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor >>>>>>>> with error message like 'No manual entry for cpupower-monitor.1' >>>>>>>> The issue is that under the hood it calls 'exec' function with >>>>>>>> the following args: 'man cpupower-monitor.1'. In turn, 'man' search >>>>>>>> path is defined in '/etc/manpath.config'. Of course it contains only >>>>>>>> standard system man paths. >>>>>>>> Make subcommands help available for a user by setting up 'MANPATH' >>>>>>>> environment variable to the custom installation man pages dir. That >>>>>>>> variable value will be prepended to the man pages standard search paths >>>>>>>> as described in 'SEARCH PATH' section of MANPATH(5). >>>>>>> >>>>>>> What I am asking you is what happens when you set the MANPATH before >>>>>>> running the command? >>>>>> >>>>>> It adds the custom search path to the beginning of the MANPATH variable. >>>>>> I tested this case. All works as expected. >>>>>> >>>>> >>>>> Let's try again. What happens if you run the command with MANPATH set and >>>>> exported and then run the command. Can you send the output? >>>> >>>> hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH >>>> /tmp/ >>>> hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ >>>> bin/cpupower help monitor >>>> ................... >>>> man output >>>> ................... >>>> hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH >>>> /tmp/ >>>> hedin@laptop:~/prj/cpupower/install/usr$ >>>> >>> >>> Is this with your patch or mainline? Can you give cut and paste >>> the man output here for the mainline coupower without your patch? >> >> The above output is from my patch. >> This is the output from the mainline: >> hedin@laptop:~/prj/cpupower/install/usr$ sudo LD_LIBRARY_PATH=lib64/ >> bin/cpupower help monitor >> [sudo] password for hedin: >> No manual entry for cpupower-monitor >> hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH >> /tmp/ >> hedin@laptop:~/prj/cpupower/install/usr$ >> > Based on our today's conversation the following is the output for the mainline: > > hedin@laptop:~/prj/cpupower/install/usr$ > MANPATH="/home/hedin/prj/cpupower/install/usr/man:" > LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > > ............. > man output > ............. > > hedin@laptop:~/prj/cpupower/install/usr$ export > MANPATH="/home/hedin/prj/cpupower/install/usr/man:" > hedin@laptop:~/prj/cpupower/install/usr$ echo $MANPATH > /home/hedin/prj/cpupower/install/usr/man: > hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ > bin/cpupower help monitor > > ............. > man output > ............. > > hedin@laptop:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ sudo > bin/cpupower help monitor > [sudo] password for hedin: > bin/cpupower: error while loading shared libraries: libcpupower.so.1: > cannot open shared object file: No such file or directory > > As you can see we can use MANPATH for correct help invocation, unless > we call it with 'sudo'. I can guess that it simply > inherits the environment variables from the root shell that contains > no 'MANPATH' variable set with an ordinary user. > sudo -s will inherit the environment. Check sudo man page. > Worth mentioning this in an appropriate manpage? I don't think so. thanks, -- Shuah
diff --git a/tools/power/cpupower/utils/cpupower.c b/tools/power/cpupower/utils/cpupower.c index 9ec973165af1..a7777e693fa7 100644 --- a/tools/power/cpupower/utils/cpupower.c +++ b/tools/power/cpupower/utils/cpupower.c @@ -12,6 +12,8 @@ #include <unistd.h> #include <errno.h> #include <sched.h> +#include <libgen.h> +#include <limits.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/utsname.h> @@ -80,14 +82,17 @@ static void print_help(void) static int print_man_page(const char *subpage) { - int len; - char *page; + char *page, *man_path, *exec_dir, *man_env; + char exec_path[PATH_MAX]; + int subpage_len; - len = 10; /* enough for "cpupower-" */ - if (subpage != NULL) - len += strlen(subpage); + if (!subpage) + return -EINVAL; - page = malloc(len); + subpage_len = 10; /* enough for "cpupower-" */ + subpage_len += strlen(subpage); + + page = malloc(subpage_len); if (!page) return -ENOMEM; @@ -97,6 +102,32 @@ static int print_man_page(const char *subpage) strcat(page, subpage); } + /* Get current process image name full path */ + if (readlink("/proc/self/exe", exec_path, PATH_MAX) > 0) { + exec_dir = strdup(exec_path); + if (!exec_dir) { + free(page); + free(man_path); + return -ENOMEM; + } + + /* Prepend standard search path for man pages with relative path + * to custom install man directory + */ + man_env = getenv("MANPATH"); + if (asprintf(&man_path, "%s/../man:%s", + dirname(exec_dir), (man_env ? man_env : "")) > 0) { + setenv("MANPATH", man_path, 1); + free(exec_dir); + free(man_path); + } else { + free(page); + free(exec_dir); + free(man_path); + return -ENOMEM; + } + } + execlp("man", "man", page, NULL); /* should not be reached */
When the 'cpupower' utility installed in the custom dir, it fails to render appropriate help info for a particular subcommand: $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor with error message like 'No manual entry for cpupower-monitor.1' The issue is that under the hood it calls 'exec' function with the following args: 'man cpupower-monitor.1'. In turn, 'man' search path is defined in '/etc/manpath.config'. Of course it contains only standard system man paths. Make subcommands help available for a user by setting up 'MANPATH' environment variable to the custom installation man pages dir. That variable value will be prepended to the man pages standard search paths as described in 'SEARCH PATH' section of MANPATH(5). Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com> --- Changes in v3: - fix: append the previous value of "MANPATH" to a new one instead of its replacement - Link to v2: https://lore.kernel.org/r/20240622-fix-help-issue-v2-1-6c19e28a4ec1@gmail.com Changes in v2: - Fixed spelling errors - Simplified man pages search approach by the 'MANPATH' variable usage - Link to v1: https://lore.kernel.org/r/20240621-fix-help-issue-v1-1-7906998d46eb@gmail.com --- tools/power/cpupower/utils/cpupower.c | 43 ++++++++++++++++++++++++++++++----- 1 file changed, 37 insertions(+), 6 deletions(-) --- base-commit: 2102cb0d050d34d50b9642a3a50861787527e922 change-id: 20240619-fix-help-issue-573c40bb6427 Best regards,