[arexxbifs]

Completely agree. One of the problems is of course the freedom of choice a Unix system gives you. Instead of a single shell with a single set of commands, people can pick and mix. For beginners it's a nightmare but for power users it's, in general, very empowering.

Getting help on Unix commands, particularly in Linux, has always been a mess. On most Linux distros, typing "help" will give you help about the shell built-ins. Then, discovering "man", you soon find that the bundled GNU utils of course would rather you use their "info" system, which in turn may refer to a web page(!) for info.

I remember coming from the Amiga to Linux: I would not have gotten far without word-of-mouth help (and helpful computer magazine articles explaining a lot of the particularities of Unix). The Amiga, on the other hand, was a cheap home computer with an exceptionally thick manual detailing every single command clearly and succinctly.

The Open Group has the POSIX util spec published online[0] and also allow free downloads of it for personal use. Since I discovered it, I find myself using it much more often than man pages. I've made a little alias in bash that launches Dillo with the appropriate command page.

[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...

[einpoklum]

> For beginners it's a nightmare

I've taught undergraduate students some basic shell use for being able to compile their C programs. It's not really that bad. You have them use bash and you teach them some basic syntax and a few shell-usable programs, including man. You tell them that there is a lot of things the shell can do that we won't be discussing, so they have to be careful not use arbitrary symbols and to double-quote names. And I also tell them that bash is just one kind of shell, and that some systems have other shells by default, but we are working on a system which defaults to bash. I then tell them to check with "echo $SHELL" if they're on another system than the one we are working on, and if they don't see "/bin/bash" or "/usr/bin/bash" then they should ask someone for help.

That's enough to satisfy newbies in my experience.

[SAI_Peregrinus]

> I then tell them to check with "echo $SHELL" if they're on another system than the one we are working on, and if they don't see "/bin/bash" or "/usr/bin/bash" then they should ask someone for help.

Some systems will be weird. EG my default shell is bash, but my interactive shell for all my terminal emulators is fish. So "echo $SHELL" returns "/bin/bash", even from fish.

Of course I know this, I set it up this way deliberately so that only actual interactive shells (or correctly shebanged scripts) would be fish and everything else could be bash. But it would definitely confuse a beginner!

[einpoklum]

Hmm... interesting. But - echo $SHELL should tell you what the current shell is, not what the default shell is.

[arexxbifs]

$SHELL should typically be set to reflect the configured login shell, I.E. the shell specified in /etc/passwd. Or, as POSIX[0] puts it: "This variable shall represent a pathname of the user's preferred command language interpreter." The currently running shell is not necessarily the "preferred" shell, for example if you're doing "xterm -e zsh" or running a specific ksh script when you normally prefer (log in to) bash.

Being vaguely defined, it is of course open to interpretation and might vary from system to system, thus being a prime example of the kind of frustrating Unix gotchas that spawned the original article.

[0] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

Edit: To tie in to my earlier comment - where should I look for info on this variable in Linux? I know it exists, but how do I find out more about the behavior? 'apropos "\$SHELL"' gives me nothing. 'apropos SHELL' gives me a list of commands which doesn't include much of interest. Digging deeper, there's login(1), which briefly touches the subject, and environ(7), which gives a good description of it but of course dives in head-first and starts off by describing an array of pointers. Not overly helpful for the novice.

[JdeBP]

No, It tells you what program image file is going to be used when a program "shells out" or spawns a shell to run a shell command (e.g. via the ! command in mail or the :shell command in nvi).

It is a way for applications to know where the shell to invoke is, not a way for a user to find out what program xe is using to run commands. echo $0 is more informative on that score.

[jstimpfle]

I didn't find it that hard. Just realize the different backgrounds and cultures that all these projects originate from. They all have their own ways of doing it.

man pages work pretty well for a lot of stuff that is POSIX. C interfaces and basic CLI programs you'll all find documented in man (with documentation beyond what is specified in POSIX).

The GNU folks have tried to push their info system, so maybe you'll find more details there for their commands. I guess most people use man because it's quick to access and a single page is easy to grep through. If that doesn't help, I'll just do a web search.

[IggleSniggle]

Been using “man” for years, understand it’s section system and have made a few man pages for various utility programs I’ve made.

The man page for built-ins is never the quick reference I want, so I generally end up falling back to google for that stuff rather than try and figure out where it’s documented.

Anyway, TIL “help” is a command I can try.

I haven’t used it in awhile, but “cht.sh” is basically what I expect “man” to give me, but comprehensively, for everything, and by the program author(s).

Public repos with easily searchable source and a good README are even better tho, of course.

[arexxbifs]

I think the availability of "help" depends on what shell you're using. It's a builtin in bash.

[Symmetry]

In fish it launches a help web page if you're in a graphical session (but still has a fallback without).

[throw0101a]

> Completely agree. One of the problems is of course the freedom of choice a Unix system gives you.

This is because Unix (or large parts of the environment) evolved over time rather than being designed at the beginning.

We started with the Bourne shell, then got the C shell, with the Korn shell splitting the difference between the two. Bash then came along taking lessons from each of those three, and then Z shell.

That's a few decades' worth of changes.