2024年5月8日(水) 8:11 Matheus Afonso Martins Moreira <math...@matheusmoreira.com>: > Some builtins do support long options, even though it seems > to not be documented.
I didn't know the `type' builtin recognizes those forms. > Also, I do realize that there's a big all caps warning > in the file saying that "THIS SHOULD REALLY GO AWAY". > I get the message, but I'm honestly not sure what > that's referring to. The obsolescent options, > the long options, the hack to handle them? > All of this stuff? Not sure. > The builtins seem to be quite consistent > in their support for --help though. > So there's at least some precedent > for long option support. I've been accepting the `--help' option because it is somewhat special. When people do not know even whether the command supports a long form of the options, they still want to get a help text. Then, they typically attempt `<command name> --help'. > > If you consider the current form would be complete, you should provide > > the reason that the other builtins should not have the long form of > > the options, while only the source builtin should have a long option. > > I don't understand why they don't all have long options to begin with. > Is there a reason for it? I don't know the true reason, but at least it's tradition. It's been this way for a long time. > > I don't think those changes are allowed to slip in as a bonus > > of another change on the source builtin. > > Well I'm not really trying to "slip in" anything. > That implies I'm deceptively trying to get my way. > I'm not. I just thought it would be a nice feature to have. I wouldn't call it `deceptive', but by mixing the change in a larger patch, the change has more chance to go into the codebase without being focused by the reviewers and without being discussed sufficiently as they would have if they were in a separate suggestion. > If it's not acceptable, I can and will remove the long options. This is my opinion: You can just remove the support for the long option from the present patch set. If you are willing, you should create another discussion in the bug-bash list (not in the help-bash list), and then if accepted, complete the long options for all the builtins, and re-submit the patch after that. The current introduction of the long option is not in a complete form. > > I'm not sure about what Chet thinks, but I don't think those are > > really necessary, though it's a better design in general. > > I'll wait for his review. > > I also have thoughts on the way how this was implemented, but I > > wouldn't discuss it for now. > > Please do. If the implementation can be improved, I will do it. I'm not sure if the full support for the long options would be accepted by the community so wouldn't like to spend time to nicely explain them at present. If you are fine with random sentences, it doesn't work with `source -- --library' when one wants to source a file of the actual name `--library'. This is a hypothetical case, but still conflicts with the standard processing of the command-line arguments. The hidden options of the `type' builtin have the same issue. Next, there is already the `--help' option. If the long option would be officially supported, the processing of `--help' and the other long options should be consistent. We don't want to use two different mechanisms to handle the long options at the same time. Third, the `const char to;' should be `const int to;' to make it consistent with the return type of `internal_getopt'. In particular, this is not forward compatible when we want to add a long option that doesn't have a corresponding short form, in which case one should choose an integer that doesn't overlap with a char value (as seen in the negative values of GETOPT_EOF and GETOPT_HELP). However, I have to say there is also an issue in the existing choices of -1 and -99 because `char' is signed in typical C implementations and thus has the range -128..127. We don't usually use the negative range (i.e., C1 and GR in ASCII or the leading byte of a multibyte character) as an option letter, but it's better to avoid.
