Old haguichi not detecting Terminal/FileManager etc. variables correctly

[Fincer]

Hi there,

the version of Haguichi I use is an old one, 1.0.26 clr 4.0. Why? Because I prefer GTK2 over GTK3.

I have compiled the program multiple times on my KDE5 environment in previous years without problems. I tested the program yesterday again after long time.

I noticed the program didn't correctly set neither variable Terminal (DetermineTerminalThread) nor FileManager (DetermineFileManagerThread) which both have been defined in /src/Command.cs. Terminal variable always returns "gnome-terminal" and FileManager returns "nautilus", though I don't have none of these installed. Instead, I use konsole and dolphin.

As far as I am aware, old haguichi config is stored at $HOME/.config/gconf folder. I tried deleting it, but the problem persisted. I have enabled debug flag for the program but it didn't give any helpful output either.

Before suggesting that I should update my Haguichi version, I'd like to update the source code so that the program gets those variable correctly set or at least I can see konsole & dolphin in CommandsEditor // Settings window as expected.

You have used CSharp Exists() method for detecting a Linux command in /src/Commands.cs. Is this method still valid or is there something else I am not aware of? My mono version is 5.0.0.100.

If this is a source code problem, which method should be used to detect a command? If it's not a source code problem, is there any other configuration files other than those in $HOME/.config/gconf folder?

Sincerely,
Fincer

[ztefn]

Hi Fincer,

You can find the Exists() method within Command.cs itself on line 235:
http://bazaar.launchpad.net/~ztefn/haguichi/1.0/view/head:/src/Command.cs#L235

As you can see it simply executes "command -v {program here}" in a bash shell. If this "command -v" doesn't find a path to the programs binary Haguichi assumes it doesn't exist.

The current Vala/GTK3 version is still using the same technique:
http://bazaar.launchpad.net/~ztefn/haguichi/1.3/view/head:/src/command.vala#L93

PS: You should update your Haguichi version! ;P

[Fincer]

Hey,

thanks for quick response @ztefn ! I'll check those lines soon.

P.S. I know. I'm just too stubborn to do that. :)

Fincer

[ztefn]

You know you can just shrink the window down and it'll look almost the same as the GTK2 version, right?

[Fincer]

I didn't know that. Thanks for info, though.

It's actually more that I prefer keeping my system without GTK3 packages. Qt5 is my choice, but since the program is not Qt-based, and I really like the idea of Haguichi, I use the old GTK2 version instead.

There is a Qt-based hamachi UI program known as Quamachi around, but it's just too ugly. Haguichi's interface is much better.

[ztefn]

Ah, I see... here I thought people rather kept their system without Mono packages... =)

Anyway. Please let me know if you find anything problematic with the command detection which could be relevant to the Vala code too.

[Fincer]

Yeah sure! Thanks again for responding!

[Fincer]

I manually tested the following commands (~line 235):

bash -c "command -v konsole"
which returns
/usr/bin/konsole

However, these ones return nothing (~meaning null or empty) on my system:

bash -c "command -v gnome-terminal"
bash -c "command -v nemo"_

which is the problem. Simply using uppercase -V parameter for command in line 238 fixes the problem.

Condition if ( output.Contains ( "command not found" ) ) in line 240 returns true because output with lowercase -v doesn't contain "command not found" string. It simply returns empty or null which therefore passes the check and causes strange bugs here.

Edit: not sure if any help but my bash version is bash 4.4.012

[ztefn]

I'm not so sure about this. Haguichi itself makes bash return "command not found" by appending &>/dev/null || echo 'command not found' to the command. This prints "command not found" if the "command -v" command returns any error code (because as you saw, it doesn't print any error output).

So these commands is what you should actually run on your system to get the same output as Haguichi:
command -v konsole &>/dev/null || echo 'command not found'
command -v gnome-terminal &>/dev/null || echo 'command not found'

And to make sure what Haguichi actually determines, please check the debug output:
haguichi -d | grep Determine

Because it could also be that Haguichi does determine the right commands, but the threads finish only after the CommandsEditor already has been initialized. I recently stripped out the separate detection threads in the Vala code for that same reason: c6e51bb

[Fincer]

Hmm okay. Actually, yeah...

Commands

command -v konsole &>/dev/null || echo 'command not found'
command -v gnome-terminal &>/dev/null || echo 'command not found'

work as expected.

This is the terminal output of haguichi -d | grep Determine without any patches to Commands.cs:

[02/10/2017 19:22:31 - fincer: ~ ]$ haguichi -d | grep Determine                                     
[19:23:25.4859760 ENVIRONMENT] [Command.DetermineSudoThread] [19:23:25.4859760 ENVIRONMENT] [Command.DetermineRemoteDesktopThread] Command for remote desktop: vinagre
[19:23:25.4859760 ENVIRONMENT] [Command.DetermineFileManagerThread] Command for file manager: nautilus
[19:23:25.4859760 ENVIRONMENT] [Command.DetermineTerminalThread] Command for terminal: gnome-terminal

I need to investigate this bit further, thanks for the hints!

[Fincer]

I found the solution. Adding p.WaitForExit (); to line 313 (Command.cs) solved the issue for me.

[ztefn]

Might be interesting to also log the output that Haguichi receives, right before the if/else statement:
Debug.Log ( Debug.Domain.Environment, "Command", "Output for command " + command + ": " + output );

[Fincer]

Yup. I added Debug.Logs here and there.

Exists never returned a correct boolean value (false in my case) for gnome-terminal command. For nautilus and dolphin...it returned true sometimes, sometimes false.

ReturnOutput (lines 297-338) never returned "command not found" for gnome-terminal. Instead, it returned a null/empty value for it.

All randomness and strange outputs stopped once I added p.WaitForExit ();. I didn't even need to delete private threads you mentioned before.

Sorry for having troubled you with this issue.

[ztefn]

No problem. I'm glad for you having apparently unraveled the C# shenanigans! :)

[Fincer]

Haha thanks! Learning & debugging takes time, though the solutions can be pretty simple after all. It was just too nasty problem to let it be unsolved, anyway.