-
Notifications
You must be signed in to change notification settings - Fork 340
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
Add some option alias #249
base: master
Are you sure you want to change the base?
Conversation
I've found some alias aren't listed when --help. Can I open a new pull-request adding them? In addition to these option alias I'm building a list of missing options. Some of them are already documented in TODO comments. Is it preferable to open a github issue with the complete list or adding them all to toys TODO comments and open a pull-request? Regards, |
as i understand rob's position, he doesn't like long options but admits that they exist. so they work (when someone actually has a script that needs them), but he doesn't add them until that user shows up, and he doesn't want them in the help text (unless they're long-only options that don't have a corresponding short option).
do you have specific use cases that require them? that's definitely valuable. but if it's just "here's the diff of --help against some other implementation", that doesn't really add anything. (especially given the overall policy -- as i've internalized it from the examples i've seen -- of "add it when there's a user for it".) |
OK
Suggested long options for this pull request are found in "real world" scripts:
I'm building a list of missing options the same way. I also have some notes about how frequent are used in this context. The good news are the existing options work pretty well 👌 |
It's not that I actively keep long options out of the help text: hwclock and nsenter have longopt synonyms at the end of lines, losetup has --show as an alias for ls, and when it's the ONLY way to do something it goes at the end ala ls. And for things like blkdev it just lists them. But it's a judgement call how much toybox help should say at the best of times. I want to briefly explain how to use the command. What does that mean exactly? All the shrugging. There IS a semi-policy of having undocumented options where we didn't actually implement something but we accept the option for compatibility reasons with a good enough NOP behavior. I just added the requested uname -p but didn't add it to the help text because it only ever says "unknown". There's a bunch of these: patch has --no-backup-if-mismatch but it doesn't create backups so the option is telling it to do what it's already always doing... Not mentioning a supported longopt as a synonym for a short opt isn't so much policy as "if they ask how to do X with this tool the answer is available" and calling it good enough, especially if adding the --longopt at the end would cause an 80 char line wrap when all the other option descriptions managed to fit in one line. "Is this clarifying or bloat? Does it let them do more than they could before?" It's aesthetic handwaving not a strongly held belief, and if somebody cares way more about it than I do... |
Try commit 19f16d9 |
Added some alias for existent options in various toys.
These alias are used by some building scripts for different tools considered "key-packages".