3 ms·

What about programs with such simple CLIs that they don’t have help? How about non English speakers who might be inclined to type —ayuda or something? In 2025

What about programs with such simple CLIs that they don’t have help? How about non English speakers who might be inclined to type —ayuda or something? In 2025 I think it should be more obvious that the shell is just running a program and programs have a variety of entry points and the same program can be distributed in different forms and that they might not all be self documenting.

f1shy 2y ago
Personal opinion ahead, please don’t be offended: > What about programs with such simple CLIs that they don’t have help? It is crapware > about non English speakers who might be inclined to type —ayuda or something? Come on… really?! Most utilities use heavily english for option names. Even the names of the utilities. Should we have “buscar” instead of “find”, or “schneiden” for “cut”? What about iger instead of “grep”? That is just ridiculous! Please stop!
- benatkin 2y ago
  I'm not offended hehe. I like small processes, and am into language learning, so my bias is showing. I think how things are, with most supporting --help, but not all, makes sense. I think what some are going for perhaps is that all programs to be run in the shell support --help. I think it could be normalized further by having a shell function get help for a command. For most it could pass --help, but it could handle the exceptions. So instead of running "foo --help" you could run "help foo", and it would run "foo --help" or "foo -h" or whatever, and it would be like man except instead of meaning show a manual page it could mean ask a program to document itself.
  - Arnavion 2y ago
    >I think it could be normalized further by having a shell function get help for a command. See PowerShell commandlets for a related precedent: https://learn.microsoft.com/en-us/powershell/scripting/developer/help/examples-of-comment-based-help?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/scripting/devel... Commandlets (shell functions) can annotate themselves and their parameters in a standard way, and then the shell's builtin help command parses that and presents it in a standard way. Though unfortunately this kind of integration only works for the commandlets, not arbitrary executables, because there's no standard for executables to expose such metadata to the shell.
- Y_Y 2y ago
  I'm interested in how you've translated "grep". I would guess you chose something like mapping "Global Regular Expression Print" to "Imprimir Globalmente Expresión Regular". But of course "grep" isn't really an acronym, but a contraction of the ed (and ex) command "g/re/p". Surely you don't mean to alter the syntax along with the words!
  - f1shy 2y ago
    Interprete gobal de expresiones regulares, as to my Knowledge grep stand for global reg ex parser. My Knowledge come from some archaic Sun manual. I wanted to find it, and everywhere it says print… I had it wrong. Anyway the idea is to show that translating is always partial, ans a full translation would be a titanic and unproductive work. I’m a native speaker of a couple of languages, and learned some more. So i have used computers in many languages. I hate command line translations, all are bad.

f1shy 2y ago

Personal opinion ahead, please don’t be offended: > What about programs with such simple CLIs that they don’t have help? It is crapware > about non English speakers who might be inclined to type —ayuda or something? Come on… really?! Most utilities use heavily english for option names. Even the names of the utilities. Should we have “buscar” instead of “find”, or “schneiden” for “cut”? What about iger instead of “grep”? That is just ridiculous! Please stop!

benatkin 2y ago
I'm not offended hehe. I like small processes, and am into language learning, so my bias is showing. I think how things are, with most supporting --help, but not all, makes sense. I think what some are going for perhaps is that all programs to be run in the shell support --help. I think it could be normalized further by having a shell function get help for a command. For most it could pass --help, but it could handle the exceptions. So instead of running "foo --help" you could run "help foo", and it would run "foo --help" or "foo -h" or whatever, and it would be like man except instead of meaning show a manual page it could mean ask a program to document itself.
- Arnavion 2y ago
  >I think it could be normalized further by having a shell function get help for a command. See PowerShell commandlets for a related precedent: https://learn.microsoft.com/en-us/powershell/scripting/developer/help/examples-of-comment-based-help?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/scripting/devel... Commandlets (shell functions) can annotate themselves and their parameters in a standard way, and then the shell's builtin help command parses that and presents it in a standard way. Though unfortunately this kind of integration only works for the commandlets, not arbitrary executables, because there's no standard for executables to expose such metadata to the shell.
Y_Y 2y ago
I'm interested in how you've translated "grep". I would guess you chose something like mapping "Global Regular Expression Print" to "Imprimir Globalmente Expresión Regular". But of course "grep" isn't really an acronym, but a contraction of the ed (and ex) command "g/re/p". Surely you don't mean to alter the syntax along with the words!
- f1shy 2y ago
  Interprete gobal de expresiones regulares, as to my Knowledge grep stand for global reg ex parser. My Knowledge come from some archaic Sun manual. I wanted to find it, and everywhere it says print… I had it wrong. Anyway the idea is to show that translating is always partial, ans a full translation would be a titanic and unproductive work. I’m a native speaker of a couple of languages, and learned some more. So i have used computers in many languages. I hate command line translations, all are bad.