Manpages placed incorrectly
pataquets opened this issue · comments
I've just started to use bin and found it awesome. Thanks for sharing!
As I was installing an updated gocryptfs with bin for the first time, if offered 4 matches:
Multiple matches found, please select one:
[1] gocryptfs
[2] gocryptfs-xray
[3] gocryptfs-xray.1
[4] gocryptfs.1
Select an option: I've installed the 2 binaries in ~/.local/bin/ just fine, but the manpages went also to the same dir with chmod +x, instead of ~/.local/share/man/man1/.
No big deal, I've fixed manually. But I guess checking the file type would be fairly reasonable. However, not sure if it's out of the scope of the tool and it's not a path you'll want to follow. Reporting it, just in case.
No big deal, I've fixed manually. But I guess checking the file type would be fairly reasonable. However, not sure if it's out of the scope of the tool and it's not a path you'll want to follow. Reporting it, just in case.
good observation, it'd be great if we could support manpages as well. Do you have any idea about how bin could potentially solve this? Is there a way to detect manpages files automatically? Do they have a mime-type? Is there a location that local users generally have access where this man pages can be moved into?
I can't tell about MIME types at download time, but I've done a quick test and they can be sorted out locally after downloading:
$ file ~/.local/bin/gocryptfs
~/.local/bin/gocryptfs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped
$ echo $?
0
$ file ~/.local/share/man/man1/gocryptfs.1
~/.local/share/man/man1/gocryptfs.1: troff or preprocessor input, ASCII text
$ echo $?
0
$ file --mime-type ~/.local/share/man/man1/gocryptfs.1
~/.local/share/man/man1/gocryptfs.1: text/troff
$ echo $?
0
$ file --brief --mime-type ~/.local/share/man/man1/gocryptfs.1
text/troff
$ echo $?
0file manpage has lots of options which might make it perfectly suitable for the task.
On my Ubuntu, home local manpages go to ~/.local/share/man/man{1,8} dirs, depending on their extension (1 or 8 as far as I've seen).
Checking on my other bug I stumbled on this -- this is a tricky one because there's technically no real standard for how these are included in a simple tarball. I'd suggest that if the goal is to avoid essentially becoming a package manager, it might be better to have a hook of some kind. Have a directory like ~/.config/bin/user_scripts/ and then whenever updating a package, if an executable file named exists in that path, then run that script, and provide things like the path to the downloaded package to it in the environment. Any custom post-install work can happen there, and your core tool doesn't have to worry about all the edge cases.
@mbainter what package did you come across with man packages? What I was thinking of doing initially is a very basic approach to check if tar files have a *.[0-9] file and then uncompress those to ~/.local/share/man.
Thoughts?
I have a few that have that and shell completion as well. It's just a question of how far down that road you want to go, for something originally intended to be for simple binary installs.
Systeroid is an example, but it has its man pages under a man8 subdir. I think there's another one I use that has them in the root, and one that I think has them all in man/ and one I think has them in man/man<n>/ -- I'll try to look through the list of tools I use and see if I can find examples of the variances.
There are obviously solutions to all of these -- it's just a question of if the implementation effort is worth it, and what kind of additional support load it might generate for edge-cases.
There are obviously solutions to all of these -- it's just a question of if the implementation effort is worth it, and what kind of additional support load it might generate for edge-cases.
That's ok. I wasn't thinking about the whole path but more about the filename particularly. My very naive approach was to look for any ASCII text file withing the package that as the *.[0-9] pattern and extract that to ~/.local/share/man. So far this very raw solution works for all the cases I've seen.
I think a simple mapping table of regex_expression=destination_dir would cover a lot of common cases, including all mentioned here such as manpages in root dir or some man[0-9] subdir. Walk down the regexps until one matches and, if no expression matched, default to bin as usual. It could keep the overwrite/-f behavior and most of the remaining.
It could be a built-in list or externally configurable, aka .conf file. Configuration being optional, anyway or, at least, not initially required. Just cover the most common use cases.
This would not exclude the hook idea, which I think is great. However, I guess it would require more effort from the user, imo.
Overall, I think regex provides a nice compromise between flexibility and ease of implementation and keeps the approach easy and naive enough, as opposed to use the libmagic approach I was suggesting previously.
There are obviously solutions to all of these -- it's just a question of if the implementation effort is worth it, and what kind of additional support load it might generate for edge-cases.
That's ok. I wasn't thinking about the whole path but more about the filename particularly. My very naive approach was to look for any ASCII text file withing the package that as the
*.[0-9]pattern and extract that to~/.local/share/man. So far this very raw solution works for all the cases I've seen.
I would love to see this feature implemented. I would like to help with it but I've never touched go lang before. Would you mind giving me some tips of where would you implement this feature?
A quick read through the code gives me the impression that bin is too centered about finding one specific file for each source