Re: [PATCH v2 5/8] builtins/source: parse the -i option

[Phi Debian]

On Sun, May 19, 2024 at 10:58 AM Matheus Afonso Martins Moreira <
matheus@matheusmoreira.com> wrote:

>
> This is not a problem that's introduced by this patch.
> People can already do that today. Anyone could write
> `alias source='rm -rf --no-preserve-root /*'` right now,
> nothing stops them. So I don't see why this would be
> a reason against inclusion of this feature.
>

I was not talking about breakage of a script, anybody knows you can stick
an rm -rf anywhere in your script (BTW protection/containers,... mitigate
the damages). I was talking of two incompatible package manager, where one
can break the other, yours can break mine, mine can't break yours, I was
asking for a way to secure the old (current) way for mine.

So far I saw typeset -r BASH_SOURCE_PATH='' in my init path, but not even
sure it will be enough, beside I don't control my users who may miss the
init update but still can mix'n'match the package managers.

Here, we are not talking adding one more feature into bash, we are talking
about one feature predate (intentionally or not) another one, it is normal
that some head's up occurs.


> I understand your concern though. Perhaps we can find
> ways to work around it or fully address it.
>
Not too sure about that.


>
> > Another things that bugs me, why not implementing your invention in a
> > dynamically loaded builtin, advertise it on github, and let the one who
> > really needs this great thing be their choice download it, and use it.
>
> I don't really want to maintain such a thing. I'm struggling to find time
> to work on my personal projects as it is. We are lucky to have someone
> who maintains bash and who is considering this feature for addition.
>

Strange argument, you want to forward the hot potatoes to someone else
regarding maintenance.

First of all you claim the feature is tiny, almost bug free in its
inception, secondly it is vastly needed.

If those assertion are true, then your maintenance workload is almost nil
for your feature you can always access on top of bash with dynload.

If there is a vast need for it, and if unfortunately a bug shows up, then
in this vast population, there will be a good soul providing a pull request
for it, your load would be minimal.

That's the magic of open software :-)

So I think a dynloadable builtin of yours would be a perfect use case of
dynload, and a good way to challenge your invention, i.e measure the vast
population, bug rate, etc... I think it is a good 'preview' way, before
eventually move from dyn load to static load one day. Dynloadable builtins
exist, use it.



> I don't want to fork bash. I want to be able to download the latest version
> with my package manager and get access to this.


It is perfectly doable, clone, configure, build, stick you patch and
provide it to you (or your users) not a big deal of effort.
You can have that today, all that hidden in... bingo a library :-)



> If I had to fork bash to
> get this, I would simply give up and continue working on my own
> programming language instead.
>

I think this is a great valuable idea!

PS : On the citations side, I remember one, a software is bug free when you
trash it :-)