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
