This page is part of the web mail archives of SRFI 37 from before July 7th, 2015. The new archives for SRFI 37 contain all messages, not just those from before July 7th, 2015.
> Right -- I did see that there, and I posted on an internal PLT mailing > list where I met with opposition to requiring the extra quotes: > > -L"first-arg second-arg" > --long-name="first-arg second-arg" > > Oh well. I feel for you, I've heard private support for the opposite position off this list too. If anyone is passionate about this issue, speak up on this list please. I'm not up on the contents of the proposed SRFI, or the PLT library. I have written several argument crackers, in C and Scheme, and have an opinion about this, based on the syntax illustrated above. Sometimes, but not in general, an option argument is naturally a list of items whose syntax permits a delimiter (typically either space, comma, or user-chosen (similar to the sed `s' command)). Typically, argument crackers treat these exceptions as single arguments, and let the splitting happen in other code. In general, option _names_ come from a restricted character set, so it is ok to have syntaxes which combine them in a single argument with the option argument. ("-Xfoo" or "--long-X=foo"). (Even with such syntaxes, to avoid forcing callers to smash strings together, it is a good idea to permit two-argument forms for those ("-X foo" and "--long-X foo"). But, in general, the separation of multiple option arguments has no fixed syntax. Indeed, the separation of command line arguments in general has no fixed syntax. Introducing a fixed syntax usually makes some option arguments impossible to pass (one couldn't write "first arg" in the quoted example). Rather, separating arguments is an external issue, decided by whatever program builds the argv array. Therefore, in general, an argument cracking library should probably not define an internal syntax for combining multiple option arguments in a single argument. If it must define such a syntax, it ought to allow quite a bit of flexibility, and that will likely lead to bloat and complexity with little payoff. Conventionally, multiple option arguments are handled one of two ways. Either with multiple options, as in GCC: gcc -L <linker-option> -L <linker-option-argument> -L <...> or with a delimiter argument, similarly to how xinit handles optional arguments: xinit [[client] options] [-- [server] [display] options] Those cases are so rare that most argument crackers do not treat them specially and let programs combine the optional arguments and multiple option arguments themselves. There is a need, not _necessarily_ the purview of this SRFI, to more carefully design the standard for command line syntax. POSIX has its standard, which, for historic reasons, not all POSIX programs honor and which, for historic reasons, doesn't go very far. (Extended) Scheme has the advantage over many shell languages that it has an unambiguous, simple syntax for structured data built over an extensible set of primitive types. That syntax is simple enough to be managed by other languages: much as XML is, but with less work, less code, greater flexibility, greater generality, and improved readability. So, it might be worth trying to define a restricted set of command line grammars that would support, for example, multiple option arguments cleanly. But watch out for creating a syntax which is too restricted (e.g. using space as a delimiter for otherwise arbitrary strings), or one which is too complicated. I am mostly satisfied with the argument crackers in the Hackerlab C library and in Systas Scheme -- those might provide some ideas. As a sort of wildcard, and displaying my ignorance of the details of the SRFI, I'll point out that what those two crackers have in common is that they both have a low-level procedural interface (to read options and arguments one at a time, as if the command line were a stream of those) and a higher-level declarative interface (to invoke a small amount of automatic parsing of options and arguments). The Emacs "interactive declaration" pattern would seem to be relevent, too: that pattern is the one where you have a declaration that converts a user-interface-based input-gathering mechanism into a regular procedure call, perhaps with some automatic sanity checking of the input gathered. "Option arguments must not be optional" -t Old-Return-Path: <acarrico@xxxxxxxxxxxx> Date: Thu, 26 Sep 2002 10:08:24 -0400 (EDT) From: Anthony Carrico <acarrico@xxxxxxxxxxxx> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Anthony Carrico <acarrico@xxxxxxxxxxxx> Resent-From: srfi-37@xxxxxxxxxxxxxxxxx X-Mailing-List: <srfi-37@xxxxxxxxxxxxxxxxx> archive/latest/17 X-Loop: srfi-37@xxxxxxxxxxxxxxxxx List-Post: <mailto:srfi-37@xxxxxxxxxxxxxxxxx> List-Help: <mailto:srfi-37-request@xxxxxxxxxxxxxxxxx?subject=help> List-Subscribe: <mailto:srfi-37-request@xxxxxxxxxxxxxxxxx?subject=subscribe> List-Unsubscribe: <mailto:srfi-37-request@xxxxxxxxxxxxxxxxx?subject=unsubscribe> Precedence: list Resent-Sender: srfi-37-request@xxxxxxxxxxxxxxxxx X-UIDL: af0dd686628b39495aa32581c8cfaf5b On Thu, 26 Sep 2002, Robert Bruce Findler wrote: [....] -Anthony Carrico