From nobody Fri Feb 19 01:50:58 2021 Authentication-Results: mail-b.sr.ht; dkim=none Received: from mail.nullprogram.com (mail.nullprogram.com [192.241.191.137]) by mail-b.sr.ht (Postfix) with ESMTPS id 8A34011F0B1 for <~skeeto/public-inbox@lists.sr.ht>; Fri, 19 Feb 2021 01:50:58 +0000 (UTC) Received: from nullprogram.com (localhost [127.0.0.1]) by mail.nullprogram.com (Postfix) with ESMTPS id 0F68AC70FD; Thu, 18 Feb 2021 20:50:58 -0500 (EST) Date: Thu, 18 Feb 2021 20:50:56 -0500 From: Christopher Wellons To: Daniel Sockwell Cc: ~skeeto/public-inbox@lists.sr.ht Subject: Re: quick question re: Conventions for Command Line Options Message-ID: <20210219015056.ykehuy5vdz2ou3hl@nullprogram.com> References: <7df03fe8f8d0304f0ed2cd95d7a839ae@codesections.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7df03fe8f8d0304f0ed2cd95d7a839ae@codesections.com> User-Agent: NeoMutt/20170113 (1.7.2) > --input-files *.jpg This has no way to indicate where the arguments stop such that option processing can continue, so this option must go last. If it must go last, then these are really just positional arguments. If you do choose some sentinel to mark the end (perhaps "--") then there's the risk of an argument unintentionally matching as a sentinel, such as blog expansion. As you noted, stopping at the first option-like argument (a la argparse) is similarly unsound. You mentioned repeated arguments, probably the most conventional way to supply multiple arguments for a particular option. For instance, there's ffmpeg's -i option. Though as you also noticed, this isn't friendly to globbing. Another is to use a custom, non-space delimiter that the shell won't split, such as a comma, so that the application can do its own splitting on the argument. For instance, gcc's -Wl option. Though again, not friendly to globbing. Some programs that may need to accept more arguments than the operating system allows but cannot be run multiple times (e.g. via xargs) may accept a glob pattern as an argument and expand the pattern itself. In this case usage would look like: > --input-files '*.jpg' For instance, ImageMagick may potentially have very many inputs and so it optionally (though imperfectly) accepts glob patterns. > So do you just accept that there's no way to support that usage pattern > and maintain that the costs of supporting it outweigh any benefits? Yes, I think that accurately summarizes my position. Popular programs can get away with custom conventions (e.g. gcc) so long as they consistently stick to them, but less popular programs with unique, unusual conventions demand undue extra headspace as users code switch between conventions. For instance, Go's flag package still regularly trips me up until I remember I'm dealing with a Go program. Arbitrary argument lists should be positional arguments. If you need multiple such lists (e.g. multiple inputs and multiple outputs), all but one list should be relegated to a repeated arguments — preferably the ones least likely to be used with glob expansion.