> the library (the top one may be) decide that source -i
> is the general way to go a decide a despotic alias
> source='source -i' this could be a general setup of
> this package manager.

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 understand your concern though. Perhaps we can find
ways to work around it or fully address it.

Bash has the command builtin which can be used to
ensure a real utility is executed instead of an alias or
function. It also works for builtins such as source.
I could also propose a new flag for it that restricts
its operation to builtins only, eliminating the PATH
search and ensuring that builtins cannot be replaced
by a program on the file system either.

I'm not sure what the maintainer would think about it
but I could also propose a shopt that prohibits the
aliasing of builtins and other reserved words.

These should completely solve that problem
for new scripts but not for the code you have
already deployed and can't change or update.
I'm not sure what to do about them.
However, the fact is there's any number of things
that other people can do to break them already.

> 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.

> I personally have my own bash and own ksh for our internal needs, we
> maintain them, and we have our own set of internally crafted builtins, I
> would not dare push them to shell maintainers, fearing breaking all who
> depend on bash/ksh/dash whatever for their OS startup, init script,
> configure script etc...

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. If I had to fork bash to
get this, I would simply give up and continue working on my own
programming language instead.

  -- Matheus

Reply via email to