this feels like a silly thing to say but even though i’ve been using linux since 2004 I feel like i’m learning recently that the impact of the GNU project’s software (and its design decisions) on me is even bigger than I thought

like even just the fact that (afaik) many of them used Emacs has an impact on me today

(please no “it’s GNU/Linux”)

for example I thought the “vim vs emacs” flamewars were silly (who cares? use what you want!)

but actually I feel like some of the GNU software design decisions are really influenced by emacs (readline, info pages) and that does actually have an effect

(please don’t tell me that readline has a vi mode)

(2/?)

also this guidance on command line arguments is great, I didn’t realize these things came from the GNU project and I really appreciate them https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces

(via @zwol)

(3/?)

Command-Line Interfaces (GNU Coding Standards)

Command-Line Interfaces (GNU Coding Standards)

also I didn’t realize that standardizing “—help” came from the GNU project, it makes me wonder if folks have proposed adding —help to programs that predated GNU (or are from a BSD project etc) and if so what that conversation looked like

I imagine it’s not always possible to do without breaking backwards compatibility

(4/?)

anyway i’ve been thinking about how to understand the way “the terminal” works it feels really important to understand the cultural impact of specific programs or projects (like xterm, the GNU project, etc)

i think it’s something a lot of people are intuitively aware of just from using the terminal and noticing patterns

(5/?)

@b0rk I couldn't agree more.

The more history I've learned about these things the more the way they work makes sense.

@b0rk sometimes i like to imagine the teletype printer that it emulates

@b0rk in '94 I used (sun's) db (dbg?, does anyone remember?) and a friend asked me why I didn't use gdb. It was such an amazingly different experience, the gdb ui seemed to be designed with care---dare I say love?---for an actual human (me!) using it.

I went to read all of gnu.org, the philosophy (empowering the user instead of keeping them ignorant), the coding standards (info instead of elitist manual pages, no arbitrary limits, etc ...) and decided I wanted to be part of this.

The reason some of us prefer to say GNU/Linux is rooted in the idea that even people that have been using "Linux" for decades, may not have heard about GNU.

@janneke oh interesting what do you mean when you say man pages are elitist?

@b0rk

https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals

"GNU Manuals
The preferred document format for the GNU system is the Texinfo formatting language. Every GNU package should (ideally) have documentation in Texinfo both for reference and for learners."

Info manuals usually have a philosophy section, an introduction, a tutorial and describe the relationship of the software with other softwares. Some manual pages nowadays also give examples, but in the 90s the main feature of a man page, as I experienced it as a newbie, was terseness with no regard for (dare I say a elitist disregard?) for learners like myself.

GNU Manuals (GNU Coding Standards)

GNU Manuals (GNU Coding Standards)

@b0rk Just imagine how amazing it would have been if there would have been an info manual for Linux and for git?
@janneke @b0rk I think bork is asking a different question: why would info have been better? it’s been a loooooong time since I was a power user of either, but I remember finding info very frustrating. And I was a regular emacs user at the time so I should have known most of the shortcuts! So I’m not clear why it would have been amazing if there were info for git.
@janneke @b0rk (not saying man is particularly good, mind you, I just don’t recall why info was even theoretically any better)
@luis_in_brief @b0rk because info tells a story, has an introduction, and explicitly includes learners as their audience. Whereas man pages (at least in the 90s) attempted to not spend a single character too many?
@janneke I mean I spent 20 years using Linux every day without even realizing that info pages existed (beyond maybe once when I tried to use the `info` viewer and gave up instantly) so it's hard for me to personally relate to the idea that more info pages would have been helpful

@b0rk yeah, the info experience outside of emacs is pretty terrible. I believe there was a short period where GNOME/Yelp would seamlessly present info pages.

Info manuals tell a story, for power users and learners alike. Link between different concepts. Usually have a tutorial. All of that is missing, for example--not wanting to single out one non-gnu project-- in an avalanche of manual pages.

If you want to learn about Linux (the kernel), wouldn't it be amazing if there was a manual for that? There is one for the Hurd.

@janneke I'm glad to hear that info pages were helpful to you! I think you're the one of the first people I've heard say that and it's interesting to hear what your experience has been like
@janneke it reminds me of how someone told me they went to a free software conference and they were really surprised that almost everyone there was an emacs user, feels like there's a bit of a cultural divide between "free software" culture and the "tech industry" (even though of course a lot of folks in the "tech industry" rely on and care about free software)

@b0rk we have been living in mostly different bubbles.

When I read "We will use Emacs as our editor" and I realized that was the single one statement that I had a problem with (being a happy VI user for some years), it occurred to me that this was probably caused by a problem with my perspective.

I then spent three summers to try to learn Emacs. That's some 25y ago. I can't say whether it was having context aware info pages with just a keystroke away next to your program text, being able to copy stuff without even having to glance at your mouse. Or whether it was the automagical (re-)indentation of code. Or something like the debian-changelog-mode when creating a Debian package.

Together with a friend I went to create GNU LilyPond which was often praised because of its documentation. I now hear similar praise about our Guix manual.

@janneke that's awesome, the LilyPond website looks really clear!

@b0rk thank you! It's all generated from [tex]info and is thus (mostly) also browsable offline as info pages.

If only the #GNU project would have taken this up, have improved and standardized it. Twenty years ago.

@b0rk of course, especially at the time, the (projected) LilyPond user base included musicians rather than programmers.
@janneke I've been appreciating the fish shell's approach to documentation recently, where `help THING` opens an HTML manual page (stored locally) in a browser.

@b0rk that seems useful (unless maybe when you're running a shell inside de Emacs, you prolly don't want a GUI browser to spawn, bt that's details).

Which reminds me, I believe there was a proposal to add up, previous, next semantics to html and it got rejected.

One of the amazing things about info (esp in emacs) is that you can read the whole document just by hitting the space bar. For, next screen and next section alike. No such thing exists in web browsers today. Similarly you isearch or regexp-search, go to node, jump to index entries. Once you're used to it, using HTML documentation becomes terribly cumbersome in comparison.

@b0rk @janneke I failed to read Info manual although I consider myself comfortable with Emacs and tried several times over the years. Well, local manuals in HTML format missed me… a lot! Then one day, reading yet another message by some Guix wizard advocating for Info, I decided tp try again, so to force myself to only rely on Info for two weeks… Today, I don’t look back. 😀

Even, today, I “regret” that Info isn’t the standard for locally browsing any documentation. 😁

@zimoun @b0rk @janneke In comparison, freebsd man and manual are really great for newcomers.
@b0rk @janneke I find them really useful for browsing documentation offline, especially when I'm trying to work on something without an internet connection. But I'm also an Emacs user, and the info reader there is definitely much better than the default terminal one
@b0rk I found that I had to implement a simple, #bootstrappable C library for my GNU Mes project. The glibc info pages would explain things about libc functions, provide example client code, and even give hints, for example when better to use another function, where the man page would just list the return values and the parameters.

@b0rk @janneke

My take is that man pages are written for those who already know. No effort is made to bring us along. There is even a culture that asserts that folks need to learn how to read man pages, implying that their lack of understanding is their own fault for not being Unix literate.

@b0rk somewhat aside, a lot of old unix tools would balk at "cmd file -opt" but gnu tools had no issue handling options coming after arguments

i had a friend who used to complain of "gnu bloatware" until he was forced to use (fairly old) solaris at work and he installed the gnu userland tools within minutes of trying to get the older tools to behave in ways he was used to

@tef huh I didn’t know that thanks!
@b0rk @tef Yes, when I started out in EDA (electronic design automation) Solaris was the standard and we all immediately installed the GNU core tools because the Solaris ones sucked.
@b0rk I just wish more projects could agree on whether help is short-form -h only, long-form --help, both, or something weird like -?.
@xgranade yeah i’m really curious about what makes it so difficult, feels like a cultural thing I don’t understand

@b0rk definitely a cultural thing - GNU wants to make everything clear for noobs but old school Unix hacks just want everything to be as abbreviated as possible.

Some commands have too many options to just use short form flags - but that means they are badly designed and should be broken up.

See also: https://harmful.cat-v.org/cat-v/

@xgranade

UNIX Style, or cat -v Considered Harmful

@xgranade
`-?` is the standard in Powershell, but I don't think I've seen it anywhere else?
@b0rk
@tarmil @xgranade @b0rk /? and -? are common on Windows in general (many Windows command-line utilities can also use either / or - as parameter prefix).
@xgranade @b0rk Using -? as an option is a bad idea, because ? is used for matching a single character in a file name. If you have a file -a (unlikely, but possible) the option would become -a, too.

@b0rk zsh even calls it "gnu_generic" (try something like compdef _gnu_generic opusenc to auto-populate tab completing the arguments for opusenc based on its --help).

I try to ensure all of my scripts can be parsed by that. As a POSIX shell scripter, that means using my hack to support long options with getopts: https://stackoverflow.com/a/28466267/519360

Using getopts to process long and short command line options

I would like to have the long and short forms of command line options invoked using my shell script. I know that getopts can be used, like in Perl, but I have not been able to implement the same us...

Stack Overflow
@b0rk iirc, --long-options were entirely a GNU invention. Before that, almost everything used just single char flags
@gray17 @b0rk Yes, I remember reading this somewhere as well (getopt docs?)
@gray17 @b0rk And many used long options with a single leading dash, which could be confusing (and still is).
@juergen @gray17 @b0rk the various Java command line tools trip me up because of that.
@b0rk that reminded me that the alternative proposal for `--help` (and long options in general) was `-=help`. I'm glad the better version won :)

@b0rk from my recollection using various Unixes from around that time period (mostly Solaris but some flavors of BSD) most command line arguments were one dash followed by all of the arguments. Gnu/Linux introduced --option style arguments

I spent my first few years of college doing -zxvf and the like, and viewed double dash arguments with suspicion when introduced to them in the late 90s. Those things might work on my home Linux machine but I could never depend on them in the computer lab

@b0rk yeah. OTOH we had DOS with standardised /? , which I found missing in Unix. GNU tried but “to late”, so with too many exceptions (and so you understand why some old programs still use -? (which use a shell wildcard character). For me the best design decisions: at least 32 bits cpu (which simplify code), try not to put limits (e.g. on sizes): today smart decision is tomorrow nightmare. And working on full stack (gcc, gmake, instead of system cc/make/etc) helps
@b0rk Didn't they also have a `--usage` flag ? Seem to remember iit on some old GNU commands, but I might be wrong.

@b0rk --help and --version (and "long options" in general). When using automake to create (source) releases there is make distcheck which depending on "strictness" checks for various of these conventions.

https://www.gnu.org/software/automake/manual/html_node/Strictness.html

In general automake make distcheck enforced a lot of things for (source) releases that we now take for granted.

https://www.gnu.org/software/automake/manual/html_node/Checking-the-Distribution.html

Strictness (automake)

Strictness (automake)

@b0rk Sun started adding --help and other --long-options for new commands being written during Solaris 10 development, and during the OpenSolaris/Solaris 11 development period started adding them to existing commands to improve Linux compatibility and make it easier to port scripts/Makefiles/etc from Linux to Solaris.
@b0rk and even though the X11 commands adopted the long options with a single dash style (like -display) in the 1980's, before GNU adopted the double-dash style, I've slowly been adding --help & --version support to many of them over the past decade or so.

@b0rk @zwol

Yea; back in "the bad old days" it was common to roll our own command line parameter parsing.

Didn't have the memory for reusable libraries in a 64K byte address machine.

"getopt", with the "--" long option names was a significant improvement. And "--" by itself to *STOP* option processing at that point, forcing all other "words" to be file names.

@b0rk @zwol I’ve been using my own parsing for years and there’s been a getopt this whole time!?!??

@b0rk @zwol If I thought they'd take it seriously, I'd open a bug against MacOS that the built-in CLI tools use the BSD-ish options and ignore the GNU improvements.

Also, the Java people need to read that, too. I've done java --version too many times and it never works.

@static @b0rk I'm still annoyed with Apple's legal department for being so skittish of GPLv3 that they completely quit contributing to GNU projects

@b0rk @zwol

I remember they sent out and RFC for conventions on long options. One proposal was to use + as the prefix for long options instead of two hyphens --
I'm really glad they went with two hyphens

@b0rk have you seen CLI Guidelines before? It was a more recent effort (maybe 2022?) to reexamine guidelines and norms from a modern perspective. Seems very related/relevant to what you’ve been doing.

https://clig.dev/

Command Line Interface Guidelines

An open-source guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day.