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.