Date: Sun, 19 May 2024 10:31:30 +0000
From: Matheus Afonso Martins Moreira <math...@matheusmoreira.com>
Message-ID:
<5LZgqrwhk0KEXRJqJIfPJzZvaJA8FVWbs_hnJHSPrPnzAzkjo7oA926voEMtU_3FGuZdylouhgpNXciyEJZPFdsScZ4pK0i4GLqv7ttR0nI=@matheusmoreira.com>
| > 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.
It could be.
| The point is they probably could.
| So why not do it?
Because there's no need, '.' exists, and is never going away,
so rather than doing lots of work, just use it. If functions
had been implemented initially, and '.' not, then perhaps it
might be done that way, and we wouldn't need a '.' command, and
any suggestion to add one could be defeated by an argument
like that. But that's all in the past, and can no longer be changed.
| A builtin is far more convenient, isn't it?
| Much more ergonomic.
Only when it is really needed.
| Not at all. If one solution is capable of
| accepting more inputs than another
| without sacrificing any functionality,
| then it's the better solution.
That's not true at all. My memory is hopeless, and I'm sure someone
on the list can supply the correct attribution, but one of the big name
CS people once said something along the lines of "perfection isn't
when there's nothing left to add, but when there's nothing left to
remove". And that's right - but it works only during initial design,
once something has been made available, people use it, and it is never
possible after that to remove it. (Unless you're python, and don't care
about breaking people's code.) But it does apply when adding
anything new (or considering that) - new stuff should be added only
when absolutely essential, not just because it is convenient for someone
(even many someones).
| > And a better solution to that would be to remove that restriction,
| Is removing things from bash and breaking users a valid choice here?
No, of course not, but removing that restriction wouldn't break
anything I can see.
| > 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.
Of course. Oh, I see, you think I was suggesting removing the
restricted shell. No, I wouldn't suggest that, no matter how
stupid the whole idea is. All I suggested removing (for the
purposes relevant here anyway) was the restriction that the '.'
command cannot read files with a '/' in their names. That
restriction seems pointless. Removing the restriction cannot
break any existing rbash setups (they can't be using '.' with
a name containing a '/') unless it created a vulnerability,
which I don't see as happening here.
| If the builtin works with the restricted shells
| while the pure shell function does not,
| the builtin is the better solution.
"If" yes, perhaps (though restricted shells work now without your
proposed changes) - which is why I suggested removing the restriction,
then the pure shell function would work with restricted shells too,
and no bash modifications would be needed (except to remove what seems
to be a pointless restriction.)
| Restricted shells do not allow command names with slashes.
That's fine, but they don't prohibit args to (most) commands
containing slashes, and in any case, using shell rules to provide
access control is silly, we have file and directory permissions,
and sometimes ACLs as well, to do that.
| > Just remove that restriction and this point goes away
| That would be a breaking change.
Breaking what?
| 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.
I don't see the connection. All you're proposing is a different
way to convert a relative pathname in a '.' command into a
full one (in effect - that is, to locate it precisely in the
filesystem). Since that can be done with a function, which
can then operate according to whatever rules the writer of that
function wants (things relative to the script location, relative
to $PWD relative to $PWD when the script started running, relative
to $HOME, relative to some other fixed point in the filesystem, or ...)
and applying whatever other name transformations it desires.
Much more flexible, and better suited to varying desires.
| Well all those components exist now.
| Why not use them instead of source?
Because that would be stupid - one uses the best tools that
are available, but every new job does not require the invention
of a new tool just to handle that job. If you start doing that
you end up with so many tools, that no-one knows what exists
any more.
| 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.
While it's not going to happen, because of the "once added it is
there forever" rule, there's a huge amount of bash that I would
not include were I creating it today. Lots and lots and lots.
I know that most of it isn't needed, as I don't write bash scripts,
I use a much more limited shell, with far fewer fancy features, and
yet I can do everything I've ever needed to do using it (I used to
write pure 7th edition Bourne shell scripts, and aside from a few
sh implementation oddities (bugs perhaps) those could also do just
about anything any script would need, with none of the later
additions).
| I'm trying to improve bash, not replace it.
Adding things is rarely improving, just making it bigger, messier,
and harder to maintain - even harder to use.
| > 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.
We don't.
| Apparently I'm right
You're not. Just the technique of doing:
PATH=/foo:/bar '.' file
isn't always the best method. On the other hand, transforming "file"
into /path/to/file and then doing
. /path/to/file
works fine (except for the restriction in rbash, which could be removed
I think.)
| but the feature _still_ shouldn't be
| added because of reasons I can't seem to understand.
It is more stuff for everyone to learn about, makes the doc even bigger,
and would need to be maintained forever even if no-one ends up using it
(because we can never actually know that.)
| doesn't really get in anyone's way
That's the issue here - everything new gets in people's way. That's
why just adding new stuff is generally a very poor idea, unless it
solves a problem that cannot be solved some other way. And I really
mean *cannot* not just "my way is easier".
| > '.' 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.
But if you agree that is what '.' should be used for, then the
PATH=/foo:/bar . file
solution works instead, as none of defining functions, setting variables,
(or changing shell options) uses PATH, only running file system commands.
kre
ps: I have had enough of this discussion, this will be my last message
on the topic.
