Unclear error if accidental trailing space in paths on external tools (Ubuntu/ Mac)

[owenBeresford]

First, as always thanks for providing this (large) tool.

Describe the bug For later readers:: Make sure you have no trailing spaces on tool names, or it breaks confusingly If documented, low priority change

A clear and concise description of what the bug is. Include any related error messages output on the command line. To show the error, when bookloupe has a space after its name in the external tools menu

To Reproduce Steps to reproduce the behaviour To queue up the failure in version 1.6.1:

1. Open Guiguts
2. Use "Preferences", "Filepaths", "set filepaths"
3. See a big list of external tools
4. Paste values into the text inputs. Paste is needed, rather than the "find tool" button
5. You can't see any spaces (but they are there)
6. hit save

To cause the failure:

1. Open Guiguts
2. Open the Tools menu ...
3. Scroll down to 'bookloupe'
4. See below error in a message window

21:38:38: Guiguts 1.6.1: If you have any problems, please include any error messages that appear here with your bug report. 21:44:56: Executable $HOME/guiguts/tools/bookloupe/bookloupe not found nor is it on the path at $HOME/guiguts/src/lib/Guiguts/Utilities.pm line 448.

if i open $HOME/guiguts/src/lib/Guiguts/Utilities.pm at 446 it reads if ( File::Which::which( $args[0] ) ) { system { $args[0] } @args; } else { warn "Executable $args[0] not found nor is it on the path"; } the file shown in the error message is a) a file, b) executable, c) not crashing when run separately

Expected behavior Perl Which shouldn't say that file doesn't exist.

Environment

• Guiguts version: 1.61
• OS and version: Ubuntu 22, but unless this point affects version of Which, ALL NIX OS (so Mac OSX) will fail in the same fashion
• Perl version: Perl 5.34, 64bit with thread multi system standard
• Perl distribution: Ubuntu basic?

Screenshots I copied the text of the error, which is more accessible (see above)

Additional context If documented, low priority change

[owenBeresford]

I hope I have raised this in the correct guiguts project...

[srjfoo]

I hope I have raised this in the correct guiguts project...

For guiguts 1.6.1, yes. (btw, gg 1.6.2 was just announced)

First question -- you mention Ubuntu + Mac. Are you using Ubuntu on a Mac, or just two different computers, one Mac and one Linux?

Either way, did you follow the installation instructions, down to the end of the macOS section where it gives instructions for installing the helper apps using homebrew. I didn't see specific instructions on installing the helper apps for Linux, though.

Once you have the applications installed, check Preferences->File Paths->Set File Paths...` and you'll see a list of file paths. What's there is a list of the defaults -- i.e. where Guiguts would expect to find them if a default install process was used.

Because I'm running from an M1 Mac, homebrew installed bookloupe in /opt/homebrew/bin/bookloupe, and I have no problem accessing it that way.

What it boils down to, I think, is that regardless of where it's installed, you have to have te file path set correctly. Anything in those file paths that has a .exe extension won't work on a Mac (I noticed that the default location for jeebies is still a .exe in my copy of 1.6.1).

I can't say what the right locations are for Ubuntu, because I've never done an install on Ubuntu.

[owenBeresford]

The reason I said both nix type OS is I read the source code. The branching is 'win32' or 'other'. The 'other' branch uses Perl library Which, that is behaving differently to which that I have installed as a standalone LOCALLY.
If you think that putting the binaries in a tools dir and putting that dir on the $PATH makes the issue go away, i will do that.

[owenBeresford]

Yes the jeebies path was wrong for me too.

[srjfoo]

The reason I said both nix type OS is I read the source code. The branching is 'win32' or 'other'. The 'other' branch uses Perl library Which, that is behaving differently to which that I have installed as a standalone LOCALLY. If you think that putting the binaries in a tools dir and putting that dir on the $PATH makes the issue go away, i will do that.

I'm not entirely sure that I'm understanding what you're trying to say, but my initial reading was that when you tried to bring up tools, they weren't working. If the tool location is incorrect in the preferences, it won't be found. The logic for setting the defaults assumes certain default locations, and if that's not where they are, and not the correct name, then they won't work. (Something I have a fair amount of experience with, because in certain areas, Macs are a bit of a snowflake. 😁 )

I can't give any advice on ebookmaker installation and invocation from Linux, because I haven't bothered yet to set it up on my Macs.

[windymilla]

If you use the Set File Paths... button in the File Paths submenu of Preferences, you can explicitly tell Guiguts where to find the tools - I would recommend giving the full path name, and not using environment variables such as $HOME. There is a Locate Bookloupe button which should allow you to navigate the file system to find and select where you installed bookloupe. Those folders get saved in your settings file, so should be remembered once you've set them up.

Thanks for the bug report though - if you set the file path correctly using the above Preferences setting, but it still fails to run, please let us know, and I'll investigate a bit further.

[owenBeresford]

I now precisely understand the failure. This tool is very sensitive to trailing spaces. I suspect my initial fault would have been a trailing space as well.

[owenBeresford]

@windymilla if people use the find tool button, no code change needed suggest a small note in the docs warning about trailing spaces, for people - like me - who copy and paste the config file in

[windymilla]

@owenBeresford - thanks for investigating and reporting back. I have updated the manual page to say:

Note: If you copy/paste or type file paths directly into the text boxes, rather than using the Locate buttons, ensure you do not accidentally add leading or trailing spaces, as this will stop Guiguts finding the tool correctly.

Let's leave this issue open though, so that if/when the next release is developed, a simple fix can be added to trim leading/trailing spaces from file paths.

[windymilla]

@owenBeresford - not sure if this is helpful (or if I've misunderstood). Perhaps what you are describing is the process you go through when you install a new version? It sounds like you perhaps open the setting.rc file in an editor, and copy/paste the settings from it into the Set Paths dialog. If that's the case, then to simplify upgrading, I would suggest you switch to using the "GGprefs" location for the settings file instead. More details are in the release notes:

Users who have already utilized the Copy Settings From A Release and header_user.txt features should not need to manually copy across files or settings when upgrading to 1.6.2. If upgrading from a pre-1.5 release and you want to take advantage of these features to ease future upgrades, see the 1.5.0 release notes, the manual, or this forum post for more details.

[owenBeresford]

Updated notes at top.
As this project has custom fonts, does the custom font show spaces?, as this would make this a null issue

[windymilla]

Updated notes at top. As this project has custom fonts, does the custom font show spaces?, as this would make this a null issue

No - even with the DP font, spaces are just empty spaces.

[windymilla]

After looking at the code, there would be quite a lot of edits required, as each file path is handled individually with its own textvariable linked to the Entry field. The user doesn't need to click the OK button to accept any new paths entered. So, there's not an obvious single place to put a check. It would either require checks on each file path when they are changed, or when the Prefs file is loaded, but again, it would be individual checks. So, on balance, and with the manual having the warning now, I've decided to close this.