> I want to agree, but I can't.
> I've seen too many differences across too many platforms and too
many Unix (like) OSs.
> Getting consistent behavior can become very tricky and you quickly
end up away from the purity that -- I think -- that you are talking about.
You understand what I am talking about.
I didn't mean to imply that all vendors ("distributors" in the Linux
case) get this stuff right.
EXPECT IT, where "expect" means "to require" not "to presume upon". Hold
their feet to the fire when the break shit.
It's not difficult, but it does count for "eternal vigilance".
Speaking of breaking shit, I've been more pleased than disappointed by
one particular distributor.
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.)
Then:
(talking about login versus child shells and "profile" versus "resource
config")
> The water starts to get murky when you start using the same shell
> for both interactive (ostensibly with a TTY) and non-interactive
> (ostensibly without a TTY) use. E.g. the former is your login shell
> and the latter is a script using the same shell. Sometimes you want
> different configurations of that shell based on it's use case.
(other stuff cut for brevity)
Yes, murky indeed.
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.
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?
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.
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.
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.
> #needMoreCoffee
mee too!
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.
-- R; <><
On 8/18/23 10:27, Grant Taylor wrote:
On 8/18/23 8:33 AM, Rick Troth wrote:
About profiling, I regularly setPS1='\$ ' which for BASH renders a
prompt as "$" for normal users but as "#" for superuser. It's
convenient.
ZSH shows that as "\$" and does not change it when I change UID.
Zsh has similar behavior.
Zsh uses different escape sequences for the prompt PS1 et al. than
Bash does.
Check out the PROMPT EXPANSION of the zshmis (or zshall) manual pages.
Look into %# in the Zsh prompt as it will give you # for root and %
for non-root.
This is *not* a slam on ZSH, just an observation.
There are many differences between Zsh and Bash. Prompt (PS1 et al.)
is just one that surprises a lot of people.
In search of better profiling, /etc/zprofile should source
/etc/profile and then override as needed. (PS1 being a prime example,
eh?)
Or ~.zprofile sourcing ~.profile, same logic and rationale.
I want to agree, but I can't. I've seen too many differences across
too many platforms and too many Unix (like) OSs. Getting consistent
behavior can become very tricky and you quickly end up away from the
purity that -- I think -- that you are talking about.
There are two levels: profiling which should happen when you sign on
(once) and "resource config" which gets invoked every time a program
starts.
Eh....
The water starts to get murky when you start using the same shell for
both interactive (ostensibly with a TTY) and non-interactive
(ostensibly without a TTY) use. E.g. the former is your login shell
and the latter is a script using the same shell. Sometimes you want
different configurations of that shell based on it's use case.
Then you get into even more esoteric things like is your interactive
shell a login shell or a non-login shell (possibly started from inside
your login shell).
Aside: Some people start additional interactive non-login shells from
their interactive login shell as a way to divide command history or
have different features for a task at hand. E.g. in the long process
of working on something that takes many hours and need a shell briefly
to fix something / unclog a printer, then start an interactive
non-login shell, do the maintenance work therein, then exit back to
the original shell without significantly altering your outer shell's
command history. Think something along the lines of an "interrupt"
button on copiers.
What ""profile to use when can be complicated.
RC scripts for shells should look for a sacred "I have been profiled"
environment variable and source appropriate profiles if it is not set.
That's why there are ~/.bash_profile exists and is separate from
~/.bash_login exists and is separate from ~/.profile exists and is
separate from ~/.bashrc.
The shell maintainers intention for the different files often gets
corrupted by distributors who have one file include another file.
I've not had enough coffee to remember which is for what purpose. But
I am confident that they are separated on purpose.
But RC scripts should not completely re-profile because they (the RC
scripts) get sourced every time a shell starts.
Hence ~/.bash_login vs ~/.bashrc.
RC scripts of interest in this context would be ~.zshrc and ~.bashrc
(or /etc/zshrc and /etc/bashrc if you're the sysadmin).
Zsh has similar separation of files like Bash does. But mostly* with
different names.
Many shells in the Bourn shell family; Bourn, Bash, Zsh, will also
read ~/.profile and /etc/profile as a way of being backwards
compatible and cross shell compatible (for a given value of compatible).
#needMoreCoffee
Does this make sense?
I started the Chicory collection when I worked in academia because I
didn't want to be on [name your platform] and not have various tools.
BASH was one. (I didn't know about ZSH in those days.)
It has grown and gotten honed. Most open source packages build really
easily. (Not as easy on USS, but that's a whole nutha story.) The
collection includes *five* shells, currently ...
* bash-5.2.15
* zsh-5.9
* pdksh-5.2.14
* dash-0.5.12
* tcsh-6.24.10
So that's BASH, ZSH, KSH, DASH, and a C-shell variant. (Long story
about C-shell. Let's just say, you don't wanna.)
I assume that you're using Public Domain Korn Shell because Korn Shell
proper source code / license wasn't available when you started that
list. I learned a few years ago that Korn Shell proper is now available.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
