[Question] Why have separate binaries for ug and ugrep if they are the same?

[daniejstriata]

I was wondering why there are 2 binaries when I compile the source in the bin directory. Can ug be an alias of ugrep?

[genivia-inc]

The logic internally checks for ug program name, but that does not appear to work with some command shells unfortunately. I had symlinked ug to ugrep in earlier versions, but found out with feedback that is not working with some command shells installed on Linux/BSD OS.

It's not problem to symlink if symlink execution by a shell uses the symlinked name and not the target name that the symlink points to, which some shells appear to use.

Hard links might be an option, but the symlink experience has polluted my mind not to trust links.

I should add that the symlink target name is used by some shells when the utility is installed, i.e. when it executes from $PATH. The problem does not appear to occur when the utility is executed from the working dir like ./ug. That surprised me. I figured some shells must cache the locations of binaries on $PATH (which is fine) but use symlink targets instead (not what we want). I felt a bit defeated after spending time figuring this out and did not find a way to get around it, so copy it is!

[daniejstriata]

Thanks for taking your time in explaining this.

[daniejstriata]

@genivia-inc Would it not be more efficient if the TUI mode could be accessed with a command line switch instead of creating copies of the same binary? Then if you want to use the TUI you can call it and therefore setup an alias?

[genivia-inc]

Both ug and ugrep commands support the TUI and should be. But the ug command specifically enables --pretty. Making ug an alias is possible, but not something that can be done automatically when installed (without modifying one or more sh dot files) and not something that would work on Windows, for example.

[daniejstriata]

Thanks again!

[yg-i]

@genivia-inc I have installed ugrep via winget just now, and it seems that only (a symlink to) ugrep.exe can be found in C:\Users\{username}\AppData\Local\Microsoft\WinGet\Links. Does this mean that if I manually create three copies of ugrep.exe, named ug.exe, ug+.exe, ugrep+.exe, in the same folder, I will be able to take advantage of the full range of available commands?

This is the current contents of my Winget/Links folder (after I created 3 copies of the original ugrep.exe). Just want to make sure this is how it's supposed to be set up:

[genivia-inc]

No, because it should work with your installation. Try the ug -l -2 "" command and see if --pretty output is produced with a directory tree format --tree for option -l (ell, not 1) up to -2 directories deep.

Note: on my end, I cannot assume that symlinks work on all platforms and with all shells. It won't work with Linux+bash for example, which doesn't return ug for argv[0] as should be, but instead returns ugrep when ug is installed as a symlink to ugrep (see my previous comments).

[yg-i]

Thanks for the response. It does seem that ug -l -2 "" is producing exactly the format you described:

For what it's worth, changing ug to ug+, ugrep, or ugrep+ all produce the following output:

Note: on my end, I cannot assume that symlinks work on all platforms and with all shells. It won't work with Linux+bash for example, which doesn't return ug for argv[0] as should be, but instead returns ugrep when ug is installed as a symlink to ugrep (see my previous comments).

Understood. The symlink in my WinGet/Links folder appears to have been created by WinGet itself, and it's linking to C:\Users\{username}\AppData\Local\Microsoft\WinGet\Packages\Genivia.ugrep_Microsoft.Winget.Source_8wekyb3d8bbwe\ugrep.exe

[genivia-inc]

It looks like ug+ is implemented differently with the Winget installer. I have implemented ug+ as a script to execute ug so it loads the config file. But your ug+ output does not show a directory tree as expected (like ug).

Related to this is the #301 PR.