Alyssa Ross <hi@alyssa.is> writes:

> Valentin Gagarin <valentin@gagarin.work> writes:
>
>> The reasons I wrote it out is that it's more obvious what it does 
>> without looking up the documentation.  As a project grows larger and so 
>> does the number of tools or options in use, the amount of rare things 
>> one needs to "just know" tends to become unmanageable, and the time to 
>> decompress a highly compressed representation goes up.
>>
>> This is, what I consider to be by now classic, advice, which I have 
>> assumed to be tacit knowledge:
>> https://changelog.com/posts/use-long-flags-when-scripting
>>
>> Discussion:
>> - https://news.ycombinator.com/item?id=5164354 (2013)
>> - https://news.ycombinator.com/item?id=24518682 (2020)
>>
>> In this particular case, nothing would tell me off the cuff what `-I` is 
>> supposed to mean for `grep`.  It seems reasonable to be explicit here 
>> and avoid the extra round of distraction for readers.  This has even 
>> more impact on people with less experience (overall or just with the 
>> particular tools).
>>
>> No action required now, the change is merged and does its thing.  But I 
>> suggest considering whether a note on the issue should be added to a 
>> document about coding conventions.
>
> I think you're probably right and I'd be happy for the convention to be
> changed and documented (but long single lines still avoided).

I thought about this a bit more.  I think there are three classes of
scripts in Spectrum in regards to this, each with different
considerations:

• Bash code embedded into Nix files.  Being in Nix files they'll always
  be run in a consistent environment, so no problems with long options
  here.

• execline code that's installed into the Spectrum system.  As above,
  but it's worth noting that these scripts mostly run execline/s6
  executables, which do not provide any long options.  We could still
  use long options for programs that have them, but might feel
  inconsistent (although it's also inconsistent when long options need
  to be passed to some program today).  I think it probably makes sense
  to make the change here.

• Scripts that are part of Spectrum's build system.  These have always
  been written with the intention of being portable.  In some cases we
  might publish code as part of Spectrum that others might want to build
  on or for some other systems.  To facilitate reuse (and in the case of
  Make especially, also to try to avoid the pitfalls and complexity that
  come with the GNU extensions), I've discouraged use of non-standard
  features of utilities that might be part of an OS, like coreutils (or
  equivalent), or awk or Make.  POSIX only standardizes short options,
  so for this category, I think it makes sense to stick to those for the
  portability advantages.  We could further break this down into scripts
  that we expect to be reused and those we don't, but I think that would
  be a difficult distinction for people to make.

Just my thoughts. :)