> the real work of the source ('.' really) utility
> is to read the file
That's the work of read.
> parse it, and execute it.
That's the work of eval.
> None of the proposed solutions here do that.
Of course not. I read the proposals.
The point is they probably could.
So why not do it?
A builtin is far more convenient, isn't it?
Much more ergonomic.
> What file names work for this purpose
> is an irrelevant consideration.
Not at all. If one solution is capable of
accepting more inputs than another
without sacrificing any functionality,
then it's the better solution.
> And a better solution to that would be to remove that restriction,
Is removing things from bash and breaking users a valid choice here?
> which has no purpose that I can imagine.
I didn't even know this restricted shell thing existed
until about a week ago. The fact remains that it's in
bash and that someone out there is probably using it.
Therefore integrating new features with it is desirable.
If the builtin works with the restricted shells
while the pure shell function does not,
the builtin is the better solution.
> The commands run by the source builtin would be restricted
That seems to be the whole point of restricted shells.
> and whatever they are, could simply be typed as input to the same effect
> so stopping a rbash user from accessing stuff in some common (full path
> named) file seems pointless to me.
Restricted shells do not allow command names with slashes.
> Just remove that restriction and this point goes away
That would be a breaking change.
> Unless it proves useful
There is absolutely no doubt that this is useful.
Not long after I sent the patches, a list of about
a dozen projects implementing module loading
and management in bash was posted.
Clearly this is something people want.
> and unable to be done some other way
It cannot be done some other way.
Not without running into limitations.
The limitations might not matter to you,
but they still exist and still should to be
properly worked around and integrated.
Frankly I couldn't care less about those
limitations either but I still put in effort
needed to understand them and make
the patches work with them instead of
just dismissing them out of hand as
irrelevant.
> That one is simple ... when it ('.' in sh, "source" in csh) was added
> there were no functions, while read & eval might have been enough for
> simple one line scripts, they wouldn't work for more complex ones, to
> invent your own '.' command that way you'd need to do it in a moderately
> complex function, which didn't exist at the time.
Well all those components exist now.
Why not use them instead of source?
> I wouldn't, as I don't care about restricted shells (never have, not
> even when I was running a system used by many hundreds of (*evil*)
> students). And that's the only real restriction, which should be
> removed anyway.
If I just started deleting things I couldn't care less about,
there wouldn't be much of bash left by the end of it.
I'm not even against it. In fact I've actually done it before.
The HTML templating language which currently powers
my website is a fork of an existing one and I literally
deleted everything I didn't care about. Literally.
Works great for me.
The point is bash would stop being bash if I did that.
It wouldn't be bash anymore, it'd be some new shell language.
I'm trying to improve bash, not replace it.
> I agree that modifying PATH isn't a great solution
Discussing this matter always seems to end like this.
I can't figure out if people actually agree with me or not.
Apparently I'm right but the feature _still_ shouldn't be
added because of reasons I can't seem to understand.
> though for any use I'd have of '.' that wouldn't bother me either
Well it absolutely bothers _me_ and that's why I suggested this
feature and developed and sent these patches in the first place.
If it doesn't bother you, doesn't break anything, doesn't really get
in anyone's way and generally only improves the status quo,
what exactly is the problem? I sincerely don't understand
what the problem seems to be and it's really frustrating.
> both because I've never used a '.' command that actually searches PATH,
> and because I don't put anything which would require a PATH search
> in files I use via '.'
Just because you don't generally do that
doesn't mean that others aren't doing it l
or that they don't want to do it.
I want to do exactly that.
> '.' is used when the current shell environment needs to be modified,
> so is useful for defining functions, and assigning values to variables
That's not under question. This is to allow better organization of the files.
