On 8/18/23 11:57 AM, Rick Troth wrote:
EXPECT IT, where "expect" means "to require" not "to presume upon". Hold their feet to the fire when the break shit.
ACK
It's not difficult, but it does count for "eternal vigilance".
Yep, making sure that someone / something constantly does things properly is an eternal task.
SUSE have worked hard to make stuff work, even in the fact of contrary popular trends. (I won't enumerate now for sake of brevity.)
I've not had the pleasure of using SuSE. But I know many that highly regard it.
Aside, I'd be curious to read your enumeration, either privately or here.
Stephen Bourne recognized the overlap between interactive commands and scripted commands and *intentionally* made his shell a language interpreter. Bill Joy criticized it as unfriendly for interactive work, and Bourne conceeded. If one must use a different shell for keyboard input than for scripting, there is the C shell.
There are MANY scripting et al. interpreters that I would loath to use interactively. Perl, Python, and PHP come to mind.
But BASH has absorbed many of the conveniences of C shell. I expect KSH has too (but I don't know it as well as you do). With KSH and BASH, who needs CSH?
I have always encouraged fellow administrators to understand, if not be fluent in the native shell. As in whatever /bin/sh is (sym-linked to). Or similarly, whatever root's shell is.
I similarly encouraged fellow administrators to not change their shell in the account definition system. Instead, have the default shell check to see if the preferred shell is accessible and exec it if it is. That way their account is still somewhat functional in the event that their preferred shell is inaccessible for any reason. E.g. file system containing the preferred shell isn't mounted, network problems breaking NFS, etc.
The problem is, when people use the C shell (Joy's brainchild) and then think to script a sequence of commands they had entered interactively ... train wreck.
ACK
While C shell may be better for interactive work (than olde Bourne), it is widely criticized as poor on the scripting front. And people use what they know.
ACK
I've chosen to "know" and teach Bourne-ish shells in both modes. When I cobble-up a nifty sequence, I can immediately copy-n-paste that into a file for re-use later. This is good practice.
I routinely wend up recording (part of) my shell history and using that as the basis for automation and refinement.
Meanwhile, ALL Bourne-compatible shells are supposed to source /etc/profile when invoked in "login" mode. I know that BASH, ZSH, PDKSH, and DASH all do. It's when the per-shell custom variant exists that /etc/profile gets skipped.
Yep. I've seen some complex matrices of what files are read when both from upstream shell maintainer and downstream distro maintainer.
-- Grant. . . . ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
