Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can not-so-common commands be added? #1726

Closed
ibnesayeed opened this issue Dec 1, 2017 · 4 comments
Closed

Can not-so-common commands be added? #1726

ibnesayeed opened this issue Dec 1, 2017 · 4 comments

Comments

@ibnesayeed
Copy link

Are there some specific criteria to decide what commands can be added and what can't?

Let me put it this way, can we provide TL;DR examples for commands that are usually not available in machines by default, but distributed separately for a specific user community? If so, then how do you resolve possible naming conflicts?

@agnivade
Copy link
Member

agnivade commented Dec 1, 2017

The general rule of thumb is whatever command has a man page can and should have a tldr page. That obviously includes commands are not available in machines and needs to be installed - for eg - docker, tesseract, ffmpeg etc.

There has been exceptions however to the man page rule. Mainly tools that are installed by npm install -g. We have also come community specific tools related to working with genomics data.

Currently, our pages architecture does not support tools with the same name unfortunately 😢 . That would require some major rework. Because along with a different pages structure, all the clients need to update their code.

Does this answer your question ?

@ibnesayeed
Copy link
Author

Many CLI tools written in languages like Go, Python, Ruby, JS etc. these days utilize some sort of argument parser library that generates built-in help, so they don't bother creating man pages for them. These tools are often distributed using language-specific repositories such as npm, go get, bundle, pip and whatnot. So, I am not sure I understood the policy around such tools well.

One solution to the conflicting names would be to allow custom tldr pages. We have directories like common, linux, osx etc., but we can also add a custom directory say, custom or extras, that will not be updated by the tool itself, but the cli will look into it. Users can put their custom examples for quick reference there, or tools can have special install targets to place their tldr distribution in that directory, if it exists. Also, this custom directory should have higher precedence in a way that if a file exists in it, it should not be looked for in other folders. This would allow users to locally customize documentation (as per their taste) of the tools that are actually maintained by this repo.

@agnivade
Copy link
Member

agnivade commented Dec 1, 2017

These tools are often distributed using language-specific repositories such as npm, go get, bundle, pip and whatnot.

Tools like that are totally welcome.

Regarding your solution to conflicting names, simply adding a separate page in a new directory won't work. There is a pages lookup index which needs to be updated. And all the tldr clients need to be updated too to incorporate this logic. That is not a trivial task. I would suggest that you comment on this issue which tracks a new pages structure #190

@agnivade
Copy link
Member

agnivade commented Dec 5, 2017

Closing this now. Feel free to reopen if you have something else to discuss that is not under #190.

@agnivade agnivade closed this as completed Dec 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@ibnesayeed @agnivade and others