Re: interactive shell detection in shrc

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Tue, Sep 24, 2024 at 05:01:18 +0700, Robert Elz wrote:

>   | sh .shrc allows you to check that .shrc has no failures, but you cannot
>   | test how it affected the shell (as opposed to sourcing it).
> 
> That's the point, to test what would happen if it were sourced,
> to prevent undesired actions from affecting a real shell, before
> a new version actually gets installed.
> 
>   | sh .shrc is a _non_ interactive shell
> 
> Yes, but sh -i .shrc isn't.
> 
>   | and return in the non-interacive branch is ingored,
> 
> In most shells, yes, but not all, relying on that is not portable,
> and there really isn't a good reason to supply non-portable code
> fragments like that.
> 
>   | so shell falls through to the interactive-only part.
> 
> which means a test intended to see what happens for non-interactive
> shells doesn't show that at all, which your average user might not
> understand - spending time trying to understand a "problem" which
> doesn't actually exist.
> 
> Note that it is not necessarily the case that what is in that file
> is only desired to effect interactive shells, I use it precisely to
> add things to non-interactive shells, even more than interactive ones.
> 
>   | I would say win-win :)
> 
> I wouldn't go that far, but note I didn't actually object to making
> the change, just pointing out why the code is written as it was.

I understand why it was written that way.  I thought that being a bit
more readable if less robust is better than being prissy.  I retract
my proposal.  Thank you for your input.

I also wanted to drop the ${1+"$@"} workaroud for the v7 shell bug
which I'm pretty sure we are not going to hit in this day and age on a
NetBSD system, but I won't to get down that rabbit hole.

-uwe